云原生 | Kubernetes集群快速升级及延长证书过期时间至10年

欢迎关注「全栈工程师修炼指南」

专注 企业运维实践、网络安全、系统运维、应用开发、物联网实战、全栈文章 等知识分享

设为「星标⭐」每天带你 基础入门 到 进阶实践 再到 放弃学习！

作者主页：[ https://www.weiyigeek.top ]  

博客：[ https://blog.weiyigeek.top ]

关注回复【学习交流群】加入【安全开发运维】答疑交流群

---

目录:

0x01 针对K8S的v1.23.x版本集群快速升级处理实践

0x02 针对部署的K8S集群证书过期时间延长实践操作

---

0x01 针对K8S的v1.23.x版本集群快速升级处理实践

描述: 本小节将主要为各位看友演示，V1.23.x版本的Kubernetes高可用集群版本升级实践，在做此操作前作者本想直通过v1.23.7升级到v1.26.x的，但是实践的过程中使用kubeadm upgrade plan命令后只建议升级到V1.23.17版本，由于此集群是用于开发测试的环境，想着只要稳定即可（不想折腾了），遂升级到V1.23.17希望能多用两年吧（PS: k8s 发展太快了短短几年就从v1.16搞得现在的v1.27），不过大多数生产环境中可能还是在v1.19~v1.23之间，因为这期间云原生比较火，一些传统企业也不断的引入了K8S到内部，为开发测试赋能，咳咳，话说得有点多了，回归正题。

环境说明:

# 系统发行版
Ubuntu 20.04 TLS

# Master
devtest-master-212 v1.23.7 主
devtest-master-213 v1.23.7 从
devtest-master-214 v1.23.7 从

# Work
devtest-work-215 v1.23.7

实践操作:

• 1.【Master-212】节点验证升级计划检查当前集群是否可被升级执行kubeadm upgrade plan命令，执行最高可以升级到 v1.23.17版本，此处需升级 kubeadm 、kubulet、kubectl，PS: 只要可允许升级的最高版本高于你的目标版本就可以升级。

apt-cache madison kubeadm
apt-get install -y kubeadm=1.23.17-00 kubelet=1.23.17-00 kubectl=1.23.17-00

• 2.【Master-212】节点确定集群升级目标版本，并且查看升级计划符合条件后，就可以在 master1 节点上执行升级集群的命令了，此过程大约3-5分钟或者更长，建议大家提前下载所需镜像，节约安装时间。

# K8S集群更新依赖的镜像
for i in $(kubeadm config images list --kubernetes-version=1.23.17 --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers -v 5);do
  ctr -n k8s.io images pull ${i}
done

# 将 Master节点-212 升级到目标版本，若显示 susccessful 字样则表明升级成功。
kubeadm upgrade apply v1.23.17

温馨提示: kubeadm upgrade命令也会自动对kubeadm在节点上所管理的证书执行续约操作。如果需要略过证书续约操作，可以使用标志--certificate-renewal=false。

• 3.升级【master-213 & master-214】节点，此处升级Master从节点是使用kubeadm upgrade node命令而不是kubeadm upgrade apply命令，此处需十分注意。

apt-get install -y kubeadm=1.23.17-00

• 4.升级【Master】节点上的kubectl和kubelet, 三台 master 节点操作顺序：master1 —> master2 —> master3 , 分别依次在三台master节点上执行如下操作，在生产环境中一定要依次升级防止对业务产生影响，通常做法是处理一台等待更新后无问题后，再操作下一台。

# 1.将当前节点标记为不可调度，并驱逐节点上的Pod
kubectl drain [节点名称] --ignore-daemonsets
#说明: --ignore-daemonsets 无视DaemonSet管理下的Pod。即--ignore-daemonsets往往需要指定的,这是
#因为deamonset会忽略unschedulable标签(使用kubectl drain时会自动给节点打上不可调度标签),
#由于deamonset控制器控制的pod被删除后可能马上又在此节点上启动起来,这样就会成为死循环，因此这里忽略daemonset。

# 2.升级kubelet和kubectl组件
apt-get install -y kubelet=1.23.17-00 kubectl=1.23.17-00

# 3.重启kubelet
systemctl daemon-reload && systemctl restart kubelet

# 4.恢复当前节点上的Pod调度，使其上线
kubectl uncordon [节点名称]

• 5.升级【Work】节点，工作节点上的升级过程应该一次执行一个节点，或者一次执行几个节点，以不影响运行工作负载所需的最小容量，此处由于我的集群中只有一个worker节点，所以这里只在一台机器上操作。

# 升级 kubeadm/kubelet/kubectl
apt-get install -y kubeadm=1.23.17-00 kubelet=1.23.17-00 kubectl=1.23.17-00

# 查看版本
kubeadm version

# 升级 node 节点
kubeadm upgrade node

# 设置节点不可调度并排空节点,只有1个worker节点时忽略此步，因为可能会报错
kubectl drain  devtest-work-215 --ignore-daemonsets

# 重启kubelet
systemctl daemon-reload && systemctl restart kubelet

# 恢复当前节点上的Pod调度, 只有1个worker节点时忽略此步
kubectl uncordon devtest-work-215  #  devtest-work-215为worker节点名称

• 6.执行如下命令来验证升级后的集群是否正常.

# 1.节点状态，可以看到都升级到了 v1.23.17
$ kubectl get node
NAME                 STATUS   ROLES                  AGE    VERSION
devtest-master-212   Ready    control-plane,master   401d   v1.23.17
devtest-master-213   Ready    control-plane,master   401d   v1.23.17
devtest-master-214   Ready    control-plane,master   401d   v1.23.17
devtest-work-215     Ready    work                   401d   v1.23.17

# 2.验证集群证书到期时间，可以看到已经续期一年了。
$ kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Jul 19, 2024 09:26 UTC   364d            ca                      no
apiserver                  Jul 19, 2024 09:25 UTC   364d            ca                      no
...........
scheduler.conf             Jul 19, 2024 09:26 UTC   364d            ca                      no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Jun 12, 2032 04:54 UTC   8y              no
etcd-ca                 Jun 12, 2032 04:54 UTC   8y              no
front-proxy-ca          Jun 12, 2032 04:54 UTC   8y              no

至此，集群升级完操作完毕!

---

0x02 针对部署的K8S集群证书过期时间延长实践操作

描述: 默认的在K8S集群安装好之后每一年需要进行续签证书，这是由于K8S社区想各用户们养成一个好的习惯，就是建议每年针对k8s集群进行补丁更新（升级K8S）保证其安全性更多扩展性功能。虽然说这个想法确实很不错，但是在企业的线上中往往不需要如此频繁的更新操作，而且每当集群的有效期过后我们部署的在K8S上的应用会面临宕机的风险，所以我们通常会这样做，在安装集群时通过修改编译kubeadm的源码来达到指定的证书过期时间，然而针对已安装部署的K8S有木有办法也可以进行证书过期时间的延长呢。

既然作者都这样说，那肯定是有的呀，此处使用yuyicai作者开发的update-kube-cert的脚本进行更新延迟集群的证书的到期时间，Github 地址: https://github.com/yuyicai/update-kube-cert

该脚本用于处理已过期或者即将过期的 kubernetes 集群证书, 请注意此脚本只适用于所有使用 kubeadm 安装集群的证书更新。前面我们说到 kubeadm 生成的证书有效期为 1 年，该脚本可将 kubeadm 生成的证书有效期更新为 10 年，此外该脚本只处理 master 节点上的证书，worker node 节点的 kubelet 证书默认自动轮换更新，无需关心过期问题。

操作流程:

# 1.拉取项目代码
git clone https://github.com/yuyicai/update-kube-cert.git
cd update-kube-cert
chmod 755 update-kubeadm-cert.sh

# 2.验证当集群CA证书及其他组件的有效期
# - 方式1
openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -text  | grep Not
  # Not Before: Jun 15 04:54:45 2022 GMT
  # Not After : Jun 12 04:54:45 2032 GMT
# - 方式2（推荐）
kubeadm certs check-expiration

# 3.此处K8S环境中是使用 containerd 作为 CRI 运行时所以使用 update-kubeadm-cert-crictl.sh 代替 update-kubeadm-cert.sh （当运行时为dockershim时选择此脚本），非常注意
./update-kubeadm-cert-crictl.sh all

温馨提示：完成上述操作后，我们需手动重启控制平面 Pods（必须） 。

因为动态证书重载目前还不被所有组件和证书支持，所有这项操作是必须的。静态 Pods 是被本地 kubelet 而不是 API Server 管理， 所以 kubectl 不能用来删除或重启他们。要重启静态 Pod 你可以临时将清单文件从 /etc/kubernetes/manifests/ 移除并等待 20 秒 （参考 KubeletConfiguration 结构 中的 fileCheckFrequency 值）。如果 Pod 不在清单目录里，kubelet 将会终止它。在另一个 fileCheckFrequency 周期之后你可以将文件移回去，为了组件可以完成 kubelet 将重新创建 Pod 和证书更新。
https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#manual-certificate-renewal

验证集群: 使用kubeadm certs check-expiration命令再次验证集群状态。

亲，文章就要看完了，不关注一下【全栈工程师修炼指南】吗？

扩展知识: 使用openssl签发CA证书的操作流程

# 1.通过ca.key生成ca.csr
openssl x509 -x509toreq -in ca.crt-back -signkey ca.key -out ca.csr

# 2.通过ca.csr重新签发公钥ca.crt
openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt

# 3.校验ca.crt是否OK（任意签发的公钥认证）
openssl verify -CAfile  ca.crt healthcheck-client.crt

# 4.查看更新后的证书时间
openssl x509 -in ca.crt  -noout -dates

本文至此完毕，更多技术文章，尽情等待下篇好文！

原文地址: https://blog.weiyigeek.top/2022/10-18-763.html

如果此篇文章对你有帮助，请你将它分享给更多的人! 

 学习书籍推荐 往期发布文章 

回复【0014】获取【Nginx学习之路汇总】

回复【0015】获取【Jenkins学习之路汇总】

回复【10005】获取【adb工具刷抖音赚米】

回复【0011】获取【k8S二进制安装部署教程】

回复【10001】获取【WinServer安全加固脚本】

回复【0008】获取【Ubuntu22.04安装与加固脚本】

回复【10002】获取【KylinOS银河麒麟安全加固脚本】

 热文推荐  

• 还不会部署高可用的kubernetes集群?企业DevOps实践之使用kubeadm方式安装高可用k8s集群v1.23.7

• 容灾恢复 | 记一次K8S集群中etcd数据快照的备份恢复实践

• 运维案例之记一次Kubernetes集群证书过期或延期操作处理实践指南（干货分享）

• 安全运维-如何在Kubernetes中使用注释对ingress-nginx及后端应用进行安全加固配置实践

• 【转载】使用 RBAC 模型限制对 Kubernetes 资源的访问原理浅析

欢迎长按（扫描）二维码 ，获取更多渠道哟!

欢迎关注 【全栈工程师修炼指南】(＾Ｕ＾)ノ~ＹＯ

添加作者微信【weiyigeeker】，一起入坑吧!

关注回复【学习交流群】即可加入【安全开发运维沟通交流群】

      各位亲爱的读者，现在公众号更改了推送规则，如果您需要第一时间看到我们推送的好内容。

一定要记得给公众号星标，经常点赞、在看、转发、分享和留下您的评论 

真心感谢您一直以来的支持 

点击【"阅读原文"】获取更多有趣的知识

若有帮助请点个【在看 + 赞  】