Kubeadm: apiserver证书过期后如何更新证书？

https://github.com/kubernetes/kubeadm/issues/206 的副本

@zalmanzhao您是否设法解决了这个问题？

一年多前，我创建了一个 kubeadm v1.9.3集群，并且一直运行良好。 我今天去更新一个部署并意识到我被锁定在 API 之外，因为证书过期了。 我什kubeadm alpha phase certs apiserver不能failure loading apiserver certificate: the certificate has expired （kubeadm 版本目前是1.10.6因为我想升级）。

将insecure-skip-tls-verify: true到~/.kube/config → clusters[0].cluser也无济于事 - 我在尝试kubectl get pods时看到You must be logged in to the server (Unauthorized) kubectl get pods (https://github.com)。 com/kubernetes/kubernetes/issues/39767）。

集群正在工作，但它会一直过着自己的生活，直到它自我毁灭或直到事情得到解决为止我能挖掘出的唯一相关材料是一篇名为 _'如何更改 kubernetes 集群中过期的证书'_的/etc/kubernetes/ssl/文件夹（只有/etc/kubernetes/pki/ ）——要么我有不同的 k8s 版本，要么我只是在没有注意到的情况下删除了该文件夹。

@errordeveloper你能推荐一些东西吗？ 我很想在没有kubeadm reset和有效载荷娱乐的情况下解决问题。

@kachkaev在不重置 kubeadm 的情况下更新证书是否有运气？
如果是这样，请分享，我在这里遇到了与 k8s 1.7.4 相同的问题。 而且我似乎无法升级（$ kubeadm upgrade plan），因为错误再次弹出，告诉我证书已过期并且无法列出集群中的主节点：

[ERROR APIServerHealth]: the API Server is unhealthy; /healthz didn't return "ok"
[ERROR MasterNodesReady]: couldn't list masters in cluster: Get https://172.31.18.88:6443/api/v1/nodes?labelSelector=node-role.kubernetes.io%2Fmaster%3D: x509: certificate has expired or is not yet valid

不幸的是，我最终放弃了。 解决方案是创建一个新集群，恢复其上的所有负载，切换 DNS 记录，最后删除原始集群 😭 至少没有停机时间，因为我很幸运在过渡期间在旧的 k8s 上拥有健康的 pod。

感谢@kachkaev的回应。 尽管如此，我还是会再试一次。
如果我找到了一些东西，我一定会在这里发布......

如果您使用的是 1.8 之前的 kubeadm 版本，我了解证书轮换 #206 已到位（作为测试版功能）或您的证书已经过期，那么您将需要手动更新您的证书（或重新创建您的集群似乎有些人（不仅仅是@kachkaev）最终求助于）。

您需要通过 SSH 连接到您的主节点。 如果您使用 kubeadm >= 1.8，请跳至 2。

1. 如果需要，更新 Kubeadm。 我以前在 1.7 上。

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. 备份旧的 apiserver、apiserver-kubelet-client 和 front-proxy-client 证书和密钥。

$ 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

1. 生成新的 apiserver、apiserver-kubelet-client 和 front-proxy-client 证书和密钥。

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. 备份旧的配置文件

$ 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

1. 生成新的配置文件。

这里有一个重要的注意事项。 如果您在 AWS 上，则需要在此请求中明确传递--node-name参数。 否则，您将在日志中收到类似Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal的错误sudo journalctl -u kubelet --all | tail并且主节点会在您运行kubectl get nodes时报告它是Not Ready kubectl get nodes 。

请务必将--apiserver-advertise-address和--node-name传递的值替换为适合您环境的正确值。

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. 确保您的kubectl正在为您的配置文件寻找正确的位置。

$ mv .kube/config .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=.kube/config

1. 重启你的主节点

$ sudo /sbin/shutdown -r now

1. 重新连接到您的主节点并获取您的令牌，并验证您的主节点是否“就绪”。 将令牌复制到剪贴板。 您将在下一步中需要它。

$ kubectl get nodes
$ kubeadm token list

如果您没有有效的令牌。 您可以创建一个：

$ kubeadm token create

令牌应该类似于 6dihyb.d09sbgae8ph2atjw

1. SSH 连接到每个从节点并将它们重新连接到主节点

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. 对每个连接节点重复步骤 9。 从主节点，您可以验证所有从节点是否已连接并准备好：

$ kubectl get nodes

希望这能让您到达需要成为@davidcomeyne 的地方。

谢谢一堆@danroliver ！
我一定会尝试并在此处发布我的发现。

@danroliver谢谢！ 刚刚在旧的单节点集群上尝试了它，步骤高达 7。它奏效了。

@danroliver为我工作。 谢谢你。

对我不起作用，不得不建立一个新集群。 但很高兴它帮助了别人！

谢谢@danroliver 。 这个对我有用
我的 kubeadm 版本是 1.8.5

感谢@danroliver整理这些步骤。 我不得不对你的步骤做一些小的补充。 我的集群运行的是 v1.9.3，它位于 Internet 之外的私有数据中心。

在大师上

1. 准备一个 kubeadm config.yml 。

apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
  advertiseAddress: <master-ip>
kubernetesVersion: 1.9.3

1. 备份证书和 conf 文件

mkdir ~/conf-archive/
for f in `ls *.conf`;do mv $f ~/conf-archive/$f.old;done

mkdir ~/pki-archive
for f in `ls apiserver* front-*client*`;do mv $f ~/pki-archive/$f.old;done

1. master 上的 kubeadm 命令有--config config.yml像这样：

kubeadm alpha phase certs apiserver --config ./config.yml 
kubeadm alpha phase certs apiserver-kubelet-client --config ./config.yml 
kubeadm alpha phase certs front-proxy-client --config ./config.yml
kubeadm alpha phase kubeconfig all --config ./config.yml --node-name <master-node>
reboot

1. 创建令牌

在奴才上

我不得不搬家

mv /etc/kubernetes/pki/ca.crt ~/archive/
mv /etc/kubernetes/kubelet.conf ~/archive/
systemctl stop kubelet
kubeadm join --token=eeefff.55550009999b3333 --discovery-token-unsafe-skip-ca-verification <master-ip>:6443

谢谢@danroliver！ 仅我的单节点集群就足以执行步骤 1-6（无需重启），然后将SIGHUP发送到kube-apiserver 。 刚刚发现与容器的id docker ps ，并设置与信号docker kill -s HUP <container id> 。

非常感谢@danroliver！ 在我们的单主/多工集群上，执行从 1 到 7 的步骤就足够了，我们不必将每个工作节点重新连接到主节点（这是最痛苦的部分）。

感谢@danroliver 的精彩一步一步！ 我想知道如何将此过程应用于多主集群（裸机，当前运行 1.11.1），并且最好不停机。 我的证书尚未过期，但我正在尝试在此之前学习如何重新生成/更新它们。

@克罗宁
请看一下这个新文件：
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
希望有帮助。

@danroliver ：非常感谢，它正在工作。

没有必要重新启动服务器。
通过这两个命令重新创建 kube-system pods（apiserver，schduler，...）就足够了：

systemctl 重启 kubelet
对于我在 $(docker ps | egrep 'admin|controller|scheduler|api|fron|proxy' | rev | awk '{print $1}' | rev);
做 docker stop $i; 完毕

我也不得不在 1.13 集群上处理这个问题，在我的情况下，证书即将到期，所以略有不同
还处理本地的单个主\控制实例，因此不必担心 HA 设置或 AWS 细节
没有像上面其他人那样包括后面的步骤

由于证书没有过期，集群已经有我想继续工作的工作负载
此时也不必处理 etcd 证书，因此省略了

所以在高层次上我不得不

• 在主
  
  
  
  • 在 master 上生成新证书
  
  
  • 使用嵌入式证书生成新的 kubeconfigs
  
  
  • 生成新的 kubelet 证书 - 客户端和服务器
  
  
  • 为工作节点 kubelets 生成新令牌
  
  
• 对于每个工人
  
  
  
  • 先在 master 上排空 worker
  
  
  • ssh 到 worker，停止 kubelet，删除文件并重新启动 kubelet
  
  
  • 解除工人对主人的封锁
  
  
• 最后在主人身上
  
  
  
  • 删除令牌
  
  

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

让我们为重新加入集群的节点创建一个新令牌（在 kubelet 重启后）

# On master
sudo kubeadm token create

现在每个工人 - 一次一个

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh 到工作节点

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

回到主人并解除工人的封锁

kubectl uncordon WORKER-NODE-NAME

在所有工作人员都更新后 - 删除令牌 - 将在 24 小时后过期，但让我们摆脱它

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

@pmcgrath感谢您发布这些步骤。 我设法遵循他们并更新了我的证书，并获得了一个工作集群。

如果您使用的是 1.8 之前的 kubeadm 版本，我了解证书轮换 #206 已到位（作为测试版功能）或您的证书已经过期，那么您将需要手动更新您的证书（或重新创建您的集群似乎有些人（不仅仅是@kachkaev）最终求助于）。

您需要通过 SSH 连接到您的主节点。 如果您使用 kubeadm >= 1.8，请跳至 2。

1. Update Kubeadm, if needed. I was on 1.7 previously.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Backup old apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ 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

1. Generate new apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Backup old configuration files

$ 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

1. Generate new configuration files.

这里有一个重要的注意事项。 如果您在 AWS 上，则需要在此请求中明确传递--node-name参数。 否则，您将在日志sudo journalctl -u kubelet --all | tail收到类似Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal的错误，并且主节点会在您运行kubectl get nodes时报告它是Not Ready kubectl get nodes 。

请务必将--apiserver-advertise-address和--node-name传递的值替换为适合您环境的正确值。

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Ensure that your `kubectl` is looking in the right place for your config files.

$ mv .kube/config .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=.kube/config

1. Reboot your master node

$ sudo /sbin/shutdown -r now

1. Reconnect to your master node and grab your token, and verify that your Master Node is "Ready". Copy the token to your clipboard. You will need it in the next step.

$ kubectl get nodes
$ kubeadm token list

如果您没有有效的令牌。 您可以创建一个：

$ kubeadm token create

令牌应该类似于 6dihyb.d09sbgae8ph2atjw

1. SSH into each of the slave nodes and reconnect them to the master

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Repeat Step 9 for each connecting node. From the master node, you can verify that all slave nodes have connected and are ready with:

$ kubectl get nodes

希望这能让您到达需要成为@davidcomeyne 的地方。

这是我只需要 1.14.2 .. 关于如何的任何提示

我也不得不在 1.13 集群上处理这个问题，在我的情况下，证书即将到期，所以略有不同
还处理本地的单个主\控制实例，因此不必担心 HA 设置或 AWS 细节
没有像上面其他人那样包括后面的步骤

由于证书没有过期，集群已经有我想继续工作的工作负载
此时也不必处理 etcd 证书，因此省略了

所以在高层次上我不得不

* On the master

  * Generate new certificates on the master
  * Generate new kubeconfigs with embedded certificates
  * Generate new kubelet certicates - client and server
  * Generate a new token for the worker node kubelets

* For each worker

  * Drain the worker first on the master
  * ssh to the worker, stop the kubelet, remove files and restart the kubelet
  * Uncordon the worker on the master

* On master at the end

  * Delete token

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

让我们为重新加入集群的节点创建一个新令牌（在 kubelet 重启后）

# On master
sudo kubeadm token create

现在每个工人 - 一次一个

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh 到工作节点

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

回到主人并解除工人的封锁

kubectl uncordon WORKER-NODE-NAME

在所有工作人员都更新后 - 删除令牌 - 将在 24 小时后过期，但让我们摆脱它

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

我知道这个问题已经关闭，但我在 1.14.2 上遇到了同样的问题，并且指南没有给出错误，但我无法连接到集群并重新发出令牌（我的身份验证失败）

一个K8S集群中使用创建kubeadm v1.9.x经历了同样的问题（ apiserver-kubelet-client.crt享年7月2日到期） v1.14.1笑

我不得不参考 4 个不同的来源来更新证书、重新生成配置文件并恢复简单的 3 节点集群。

@danroliver提供了非常好的结构化说明，非常接近 IBM 的以下指南。
[更新 Kubernetes 集群证书] 来自 IBM WoW！ （https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html）

注意：IBM Financial Crimes Insight with Watson private 由 k8s 提供支持，从不知道这一点。

步骤 3 和步骤 5 的问题

第 3 步不应在命令中包含阶段

$ sudo kubeadm alpha certs renew apiserver
$ sudo kubeadm alpha certs renew apiserver-kubelet-client
$ sudo kubeadm alpha certs renew front-proxy-client

第 5 步应该在下面使用， kubeadm alpha没有 kubeconfig all，而是一个 kubeadm init 阶段

# kubeadm init phase kubeconfig all
I0705 12:42:24.056152   32618 version.go:240] remote version is much newer: v1.15.0; falling back to: stable-1.14
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file

在 1.15 中，我们添加了更好的证书更新文档：
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

此外，在 1.15 之后kubeadm upgrade自动为您续订证书！

使用 kubeadm v1.9.x 创建的 k8s 集群在 v1.14.1 时代遇到了同样的问题（apiserver-kubelet-client.crt 于 7 月 2 日过期），哈哈

早于 1.13 的版本已经不受支持。
我们强烈鼓励用户跟上这个快速发展的项目。

目前 LongTermSupport工作组正在进行讨论，希望在更长的时间内支持 kubernetes 的版本，但建立这个过程可能需要一段时间。

谢谢@pmorie 。
适用于 kube 版本 1.13.6

只是一个评论和功能请求：这个证书到期今天早上在我们的 Kubernetes 1.11.x 集群上影响了我们的生产。 我们尝试了上面的所有内容（以及链接），但遇到了许多错误，在几个小时后完全被大型软管集群卡住后放弃了。 幸运的是，我们距离升级到 Kubernetes 1.15（并构建一个新集群）还有大约 2 周的时间，所以我们最终只是从头开始创建了一个新的 1.15 集群并复制了我们所有的用户数据。

我非常希望在这件事发生之前有一些警告。 我们刚刚从“令人难以置信的稳定集群”变成了“完全破碎的地狱噩梦”，没有任何警告，并且可能经历了有史以来最糟糕的停机时间。 幸运的是，周五下午是西海岸，因此影响相对较小。

在上面讨论的所有内容以及所有链接的门票中，有一件事会产生巨大的影响
没有提到我们的区别：当证书即将到期时开始显示警告。 （例如，如果您使用 kubectl，并且证书将在几周内到期，请告诉我！）。

很抱歉给您带来麻烦。 通常是运营商的责任
监视磁盘上的证书是否过期。 但我确实同意缺乏
容易监控可能会导致麻烦。 这就是我们添加一个的原因之一
在 kubeadm 中检查证书过期的命令。 看
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

另请注意，在 1.15 之后 kubeadm 将自动更新证书
升级。 这也鼓励用户更频繁地升级。
2019 年 7 月 20 日 03:49，“William Stein”通知@ github.com 写道：

只是评论和功能请求：此证书到期使我们陷入困境
今天早上在我们的 Kubernetes 1.11.x 集群上进行生产。 我们尝试了
上面的所有内容（和链接），但遇到了很多错误，在一个
几个小时完全被一个大型软管集群卡住了。 幸运的是，
我们距离升级到 Kubernetes 1.15（并构建
一个新的集群）所以我们最终只是从头开始创建一个新的 1.15 集群
并复制我们所有的用户数据。

我非常希望在这件事发生之前有一些警告。 我们刚刚
从“非常稳定的集群”变成了“完全崩溃的地狱
噩梦”没有任何警告，并且可能是我们有史以来最糟糕的停机时间。
幸运的是，星期五下午是西海岸，所以相对最少
有影响力。

在上面讨论的所有内容以及所有链接的门票中，有一件事
那将是一个巨大的
没有提到我们的区别：当证书出现时开始显示警告即将到期。 （例如，如果您使用 kubectl，并且证书是
将在几周内到期，请告诉我！）。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJLOTDN250000000000000000000000000000000001
或静音线程
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@neolit123谢谢； 我们将在我们自己的监控基础设施中添加一些内容，以定期检查即将出现的证书问题，如您的评论中所述。

@danroliver Thx 非常感谢您的回复。 它为我节省了很多时间。
值得一提的是与“etcd”相关的证书，应该以同样的方式更新。 不需要重新加载配置，因为它在元数据 YAML 文件中用作参考。

对于 Kubernetes v1.14，我发现@desdic提出的这个过程最有帮助：

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • 备份并重新生成所有证书：
  
  

$ cd /etc/kubernetes/pki/
$ mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} ~/
$ kubeadm init phase certs all --apiserver-advertise-address <IP>

• 备份并重新生成所有 kubeconfig 文件：

$ cd /etc/kubernetes/
$ mv {admin.conf,controller-manager.conf,mv kubelet.conf,scheduler.conf} ~/
$ kubeadm init phase kubeconfig all
$ reboot

• 复制新的admin.conf ：

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

对于 Kubernetes v1.14，我发现这个过程最有帮助：

* https://stackoverflow.com/a/56334732/1147487

一旦我修复了自己的集群，我就创建了修复程序..希望其他人可以使用它

@danroliver提供了非常好的结构化说明，非常接近 IBM 的以下指南。
[更新 Kubernetes 集群证书] 来自 IBM WoW！ （https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html）

好的！ 我想知道这是什么时候出版的。 当我经历这个时，我当然会发现这很有帮助。

注意 K8s 1.13.x令牌（可能是其他 K8s 版本）
如果您最终重新生成了您的 CA 证书 ( /etc/kubernetes/pki/ca.crt )，您的令牌（请参阅kubectl -n kube-system get secret | grep token ）可能具有旧 CA，并且必须重新生成。 有问题的令牌包括kube-proxy-token 、 coredns-token在我的情况下（和其他人），这导致集群关键服务无法使用 K8s API 进行身份验证。
要重新生成令牌，请删除旧令牌，它们将被重新创建。
任何与 K8s API 通信的服务也是如此，例如 PV Provisioner、Ingress Controllers、 cert-manager等。

感谢@danroliver 的精彩一步一步！ 我想知道如何将此过程应用于多主集群（裸机，当前运行 1.11.1），并且最好不停机。 我的证书尚未过期，但我正在尝试在此之前学习如何重新生成/更新它们。

嗨@kcronin ，你是如何解决多主配置的？ 我不知道如何处理 --apiserver-advertise-address因为我有 3 个 IP，而不仅仅是一个。

谢谢

@pmcgrath如果我有 3 个主人，我应该在每个主人上重复这些步骤吗？ 或者是什么。 案件

@SuleimanWA ，如果 CA 重新生成，您可以复制admin.conf以及 CA 文件。
对于其他一切，您应该重复步骤以在每个主服务器上重新生成证书（用于 etcd、kubelet、调度程序等）

@anapsix
我正在运行一个 1.13.x 集群，在我通过运行kubeadm alpha certs renew all更新证书后，apiserver 报告Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] kubeadm alpha certs renew all 。

要重新生成令牌，请删除旧令牌，它们将被重新创建。

在这种情况下，您指的是哪个令牌？ 是由 kubeadm 生成的还是如何删除令牌？

- - -更新 - - -
我发现这是秘密本身。 在我的情况下，kube-controller 没有启动，所以秘密不是自动生成的。

高版本使用：

kubeadm alpha 证书更新所有

当第一个master节点的kubelet down（systemctl stop kubelet）时，其他master节点无法联系第一个master节点上的CA。 这会导致以下消息，直到原始主节点上的 kubelet 重新上线：

kubectl 获取节点
来自服务器的错误（内部错误）：服务器上的错误（“”）阻止了请求成功（获取节点）

有没有办法在原始 CA 节点上的 kublet 关闭时将 CA 角色转移到其他主节点？

@anapsix
我正在运行一个 1.13.x 集群，在我通过运行kubeadm alpha certs renew all更新证书后，apiserver 报告Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] kubeadm alpha certs renew all 。

要重新生成令牌，请删除旧令牌，它们将被重新创建。

在这种情况下，您指的是哪个令牌？ 是由 kubeadm 生成的还是如何删除令牌？

- - -更新 - - -
我发现这是秘密本身。 在我的情况下，kube-controller 没有启动，所以秘密不是自动生成的。

嗨，我已经完成了这个任务，但不是 1.13 版本。 如果你已经这样做了，我可以问几件事吗？
所以基本上我会做：
kubeadm alpha certs 更新所有（更新 Masters 上的控制平面 cert uber pki/ 文件夹）。
kubeadm init phase kubeconfig 更新 kube 配置文件。 （关于主人和工人）。
在所有节点上重启 kubelet。

我还需要创建令牌并在工作节点上运行 join 吗？ 如果可能，您能否分享您执行的步骤？