参考github：https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client

1.使用helm安装nfs-client，注意填写nfs服务器的地址和暴露路径

$ helm install stable/nfs-client-provisioner --set nfs.server=x.x.x.x --set nfs.path=/exported/path

2.编写storageclass.yaml并使其生效

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: fuseim.pri/ifs

3.设置这个storageclass为默认storageclass

kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

4.注意这边下载quay.azk8s.cn/external_storage/nfs-client-provisioner:v3.1.0-k8s1.11这个镜像可能很慢，可以调整成国内源下载，再重命名。例如下面的命令

docker pull quay.azk8s.cn/external_storage/nfs-client-provisioner:v3.1.0-k8s1.11
docker tag quay.azk8s.cn/external_storage/nfs-client-provisioner:v3.1.0-k8s1.11 quay.io/external_storage/nfs-client-provisioner:v3.1.0-k8s1.11

我们有时候会有删除，再重新加入master节点的需求，比如master机器改名。这里注意重新加入时，经常会出现etcd报错，如下

[check-etcd] Checking that the etcd cluster is healthy
error execution phase check-etcd: etcd cluster is not healthy: failed to dial endpoint https://192.168.0.92:2379 with maintenance client: context deadline exceeded

这个时候，就需要去还没有停止的master节点里的etcd的pod里去，删除该老master节点对应的etcd信息。

kubernetes节点信息

master03是我们将要删除重新加入的节点

# root@master01:~# kubectl get nodes
NAME       STATUS   ROLES    AGE   VERSION
master01   Ready    master   64d   v1.17.1
master02   Ready    master   95s   v1.17.1
master03   Ready    master   18h   v1.17.1
slaver01   Ready    <none>   64d   v1.17.1
slaver04   Ready    <none>   13d   v1.17.1
slaver05   Ready    <none>   13d   v1.17.1

删除master

在master01机器上执行

kubectl drain master03
kubectl delete node master03

在master03机器上执行

kubeadm reset
rm -rf /etc/kubernetes/manifests/

删除etcd信息

在master01节点上执行命令，进入etcd的容器里

kubectl exec -it etcd-master01 sh

输入命令

etcdctl --endpoints 127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member list

检查返回值

7d39fc3ab8790afc, started, master03, https://192.168.0.93:2380, https://192.168.0.93:2379, false
b54177b91845ab93, started, master01, https://192.168.0.91:2380, https://192.168.0.91:2379, false
bc771924f2f5445f, started, master02, https://192.168.0.92:2380, https://192.168.0.92:2379, false

因为我们的master03机器对应的hash是7d39fc3ab8790afc。我们下一步就是根据hash删除etcd信息，执行如下命令

etcdctl --endpoints 127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 12637f5ec2bd02b8

获取添加master的命令

在master01上输入命令

kubeadm init phase upload-certs --upload-certs

返回34f76df3029230ca3136f5ff689ed54b1af6501a59fb0ea728ff8fed31ad52b4
再在master01上输入命令

kubeadm token create --print-join-command

返回 kubeadm join cluster.kube.com:16443 –token f4amr0.c2nc87swc7jbybut –discovery-token-ca-cert-hash sha256:2c45bcc43dad9cf43c3b7e610c0cdb7d588213d4258fc060e7384276e664922e
通过组合上面的“蓝色字体部分“+“–control-plane –certificate-key“ +“红色字体部分”，获得加入master的完整命令
kubeadm join cluster.kube.com:16443 –token uerys4.h8z3lfo2j3zf8g2u –discovery-token-ca-cert-hash sha256:2c45bcc43dad9cf43c3b7e610c0cdb7d588213d4258fc060e7384276e664922e –control-plane –certificate-key 34f76df3029230ca3136f5ff689ed54b1af6501a59fb0ea728ff8fed31ad52b4

添加Master节点

执行命令

kubeadm join cluster.kube.com:16443 --token uerys4.h8z3lfo2j3zf8g2u --discovery-token-ca-cert-hash sha256:2c45bcc43dad9cf43c3b7e610c0cdb7d588213d4258fc060e7384276e664922e --control-plane --certificate-key 34f76df3029230ca3136f5ff689ed54b1af6501a59fb0ea728ff8fed31ad52b4

安装ceph的osd时.运行清空磁盘命令

ceph-deploy disk zap node3-ceph /dev/sdb

有时候会遇到这样的报错。

[node3-ceph][WARNIN]  stderr: wipefs: error: /dev/sdb: probing initialization failed: Device or resource busy
[node3-ceph][WARNIN] --> failed to wipefs device, will try again to workaround probable race condition

遇到这种报错时，只能上这台机器，手动进行dd命令清空磁盘并重启

dd if=/dev/zero of=/dev/sdb bs=512K count=1
reboot

重启完成后，再进入ceph-admin的主机进行ceph-deploy disk zap node3-ceph /dev/sdb 就能够清理磁盘成功了

需求分析

1.我们使用helm来实现应用程序的更新。
2.应用程序更新的关键就是镜像。每次我们的代码合入develop分支之后，都会产生一个新的docker镜像。
3.我们需要让helm知道我们使用了最新的docker镜像。这样部署的应用才是最新的。
4.helm包是通过nexus上传的，从设计上来说，不适合每一次cd流程就产生一个helm包并上传，helm本身也没有提供上传接口。helm包的设计是希望一个helm包能一直通用于某一类程序。
5.综上所述，我们的cd流程的关键是，在helm包不更新的情况下，让helm包能每次cd流程后，通过developmengt.yaml使用最新的docker镜像在K8S上进行部署

使用误区

误以为developmengt.yaml里配置container.image的tag为latest,imagePullPolicy为always，就能每次部署的时候拉取最新的镜像。
接下来，我们看看默认配置

我们经常会错误的配置Chart.Appversion为latest，如下图

helm upgrade [RELEASE] [CHART] [flags]
例如： helm upgrade lizhenwei nginx-chart

原因是：对于helm来说，参数没有任何变化，chart版本也没有变化，所以是不会去更新的

正确用法

我们的chart不会去不停的更新，所以我们要做的是参数的更新。
所以我们要让docker的镜像tag动起来。
1.每次的CICD流程除了上传latest镜像以外，还要再上传一个带tag号的镜像，tag号可以用git的commitHash值来区分，一般来说，有个8位的hash值就够了
2.helm的development.yaml里的镜像tag要进行对应的修改，如下

image: "{{ .Values.image.repository }}:{{ .Values.commitHash }}"

Values.commitHash是来自values.yaml文件中的commitHash参数

3.helm的upgrade命令增加comitHash参数。升级命令里增加set参数

helm upgrade -i dev-ui sfere/cloudview-ui --set commitHash=$commitHash