背景：

之前在阿里云主機(jī)上使用kubeadm安裝的kubernates（版本號(hào)為：1.8.3）,使用了一年以后，突然出現(xiàn)問題。
問題狀態(tài)為不管使用kubectl 的什么指令，都報(bào)出以下的異常：

Unable to connect to the server: x509: certificate has expired or is not yet valid

通過異常關(guān)鍵字查詢，最后定位是默認(rèn)安裝中，kubenates的apiserver與kubelet的訪問授信證書是一年，官方的說法是通過這種方式，讓用戶不斷的升級(jí)版本?，F(xiàn)在這套環(huán)境上跑著用戶的生產(chǎn)環(huán)境，不可能去做升級(jí)或是重裝的事情，這個(gè)影響太大了，所以需要在不重裝kubernates的前提上，把這個(gè)問題解決掉。

思路

方案1

源碼去掉證書判定邏輯，重新編譯
這個(gè)方式?jīng)]有驗(yàn)證，但需要下載對(duì)應(yīng)版本的源碼，重新編譯相應(yīng)組件。這個(gè)方式如果是與原作者的k8s版本一致可以試一下，或是對(duì)go語言熟悉的用戶可以找對(duì)應(yīng)的處理邏輯代碼進(jìn)行修改。

方案2

重新生成證書
其中有位大胡子說：

topic1.png

topic2.png

解決

有了上面的方案做參照，就有了自己的思路?；诒救说膶?shí)際情況。還是考慮使用方案2的方式來解決，只是根據(jù)自己的情況對(duì)步驟進(jìn)行裁減，最后問題得到了解決。下面將環(huán)境，處理步驟以操作過程中出現(xiàn)的問題敘述如下：

環(huán)境

在阿里云的云主機(jī)上使用kubeadm安裝的1.8.3版本的單結(jié)點(diǎn)的kubernates。

topic3.png

處理步驟

備份證書

sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

產(chǎn)生新的證書

sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address 127.0.0.1
sudo kubeadm alpha phase certs apiserver-kubelet-client
sudo kubeadm alpha phase certs front-proxy-client

備份老的配置文件

sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

產(chǎn)生新的配置文件

 sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 127.0.0.1

確認(rèn)kubectl正在查找正確的配置文件路徑

 mv $HOME/.kube/config $HOME/.kube/config.old
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
 sudo chmod 777 $HOME/.kube/config
 export KUBECONFIG=$HOME/.kube/config

重啟kube-apiserver，kube-controller-manager, kube-scheduler

通過docker ps找到kube-apiserver，kube-controller-manager, kube-scheduler容器，然后指令殺掉容器，讓他重新加載。
下面以kube-apiserver為例：

docker ps | grep ${keyword}

topic4.png

docker kill -s HUP ${容器ID}

及

topic5.png

備注：

在生成證書時(shí)會(huì)莫名的訪問google的網(wǎng)址，因?yàn)間oogle已經(jīng)被封了，所以會(huì)報(bào)超時(shí)。第一次出現(xiàn)這個(gè)異常的時(shí)候都快絕望了。

topic6.png

這是因?yàn)樵趉ubeadm命令升級(jí)master證書時(shí)，它也會(huì)默認(rèn)從網(wǎng)上讀取一個(gè)stable.txt的文件。解決這個(gè)問題的辦法，就是生成一個(gè)集群配置的yaml文件，然后，在運(yùn)行命令時(shí)指定這個(gè)Yaml文件即可。

kubeadm config view > cluster.yaml

注：如果已經(jīng)無法使用該指令生成cluster.yaml文件的情況下，應(yīng)該可以隨便找個(gè)文件也是可以的，應(yīng)該是kubeadm需要一個(gè)salt來生成證書信息，這個(gè)salt就是這個(gè)文件信息。
我的cluster.yaml文件如下：

api:
  advertiseAddress: 172.19.197.5
  bindPort: 6443
authorizationModes:
- Node
- RBAC
certificatesDir: /etc/kubernetes/pki
cloudProvider: ""
etcd:
  caFile: ""
  certFile: ""
  dataDir: /var/lib/etcd
  endpoints: null
  image: ""
  keyFile: ""
imageRepository: gcr.io/google_containers
kubernetesVersion: v1.8.3
networking:
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
nodeName: kubernetes.localdomain
token: ""
tokenTTL: 24h0m0s
unifiedControlPlaneImage: ""

然后在上面的kubeadm alpha phase指令中，都添加config參數(shù)，指定生成證書的鹽值。如：

sudo kubeadm alpha phase certs apiserver --config /root/cluster.yaml
sudo kubeadm alpha phase certs apiserver-kubelet-client --config /root/cluster.yaml
sudo kubeadm alpha phase certs front-proxy-client --config /root/cluster.yaml

sudo kubeadm alpha phase kubeconfig all  --config /root/cluster.yaml