咨询下 k8 大佬一些问题

[jackgoudan]

k8s 老集群的根 ca 证书即将到期，但是上面重要业务还不少，如何处理证书到期问题？

1. 手动更新各种证书，看 k8s 文档手动更新所有证书的工作量属实也不少，在我看来和业务重建没啥区别了？
2. 停机更新维护，可能部好推动，涉及的人可能有些多，但是是相对稳妥。

[jackgoudan]

@feedcode 大佬实操过吗？ 看着文档流程属实不少，感觉很容易出错

[defunct9]

实在不行，可以找我，这种容易干翻服务器的事我基本天天干。 @jackgoudan

[feedcode]

@jackgoudan 你看的文档是连私钥一起换的，只换公钥其实很简单，上面的 openssl verify 都有验证的

[idblife]

kubeadm 一条命令不就搞定了吗

[jackgoudan]

@idblife adm 只更新 ca.crt 签发的二级证书，我们现在的情况是 根 ca 都要过期了。

[w469789747]

@asilin 你是懂换证书的

[lixiang2017]

一键更新。用过好多次，很好用，老版本也支持
https://github.com/yuyicai/update-kube-cert

[plko345]

私钥不换继续用，openssl 用私钥生生成新的 ca.crt ，再签其它证书，重启 control plane 的组件，麻烦是挺麻烦的

[jackgoudan]

@lixiang2017 这个也 kubeadm renew 效果差不多？ 只能续签二级证书的吧 我今天看下下

[jackgoudan]

@feedcode @plko345 两位大佬，请教下 ca.crt 被重建，那旧的 secret 如何处理呢？ 旧 secret 内 ca.crt 字段还是老 ca ，难道要重建所有的 secret 吗？

[feedcode]

是的，所有引用 ca 的都要更新，包括 kubeconfig

[jackgoudan]

@feedcode 那这个方法和文档相比有点在哪呢？ 我认为优点就是少了二级证书的签发，可以重新走 renew 的流程，其他的 secret 重建，kubeconfig 的重建，coredns 、kubeproxy 等系统组件等重启工作也是少不来的。

[feedcode]

性质不一样的，你私钥没泄露只更新 ca.crt 就行了，如果私钥泄露了那只能一起换了，而且你要更新 2 遍才行。
第一遍用 old ca +new ca 合并的 ca.crt, 否则会失败，第二遍是去掉 old ca 只保留新的。

[jackgoudan]

@feedcode 了解，大佬说的不错，你说的就是文档的流程，维持了一个新老 ca 的中间态。你说的这个方法确实可行，不过完整的验证我我还要搭一个生产集群的再来测一遍。谢谢大佬，救了燃眉之急。

[jackgoudan]

看帖子的动态，不少老哥收藏了帖子，@DAPTX4869 还期待后续，经过我的实验以后，@feedcode 的方案是可行，我简单说下步骤:
1. 用 ca.crt 生成 csr 再生成新的 ca, 这一步 openssl 需要制定证书生成 v3 证书，v1 的证书 kubeadm 会认为不是 ca
2. openssl 生成 csr 不包含扩展内容，需要加上选项 -x509toreq -copy_extensions copy all ，这个似乎需要 openssl v3 ，运维同事打包好的 debian 是 openssl 1.1.1n ，前面选项不可用。
3. 在主 master 生成 ca,并且用 kubeadm renew 所有二级证书，然后将 ca 复制到其他 master 节点，重启 master 节点的 kubelet ，确保 kubelet 的状态是 running 以后 再进行其他操作。
4. 重启集群的关键组件,etcd,apiserver,kube-scheduler,controller-manager ，更新 admin.conf ，此时确认下 这些组件的状态都是 ok
5. 更新 worker 节点的 kubelet.conf,这里需要在 master 为 worker 节点生成一份 kubelet.conf ，我不太清楚 worker 节点的 kbuelet 是否会自动拉取最新 ca ，至少从我实验来看是不会的。这部分参考[文档]( https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert)。**注意**，生成的 kubelet.conf 确保它的 apisever 地址是正确的
6. 更新 calico ,coredns,kube-proxy ，最后确认下所有组件的状态。整个过程中，业务影响较小，我用 nginx 模拟的，证书业务没测试，替换 ca 前后 nginx 都可以正常工作。

**Note**: 只是大概描述下，如果大家有需要我后续写一篇 blog 贴出来

[DAPTX4869]

@jackgoudan #35 期待 blog, 学习下操作~

[HFX3389]

@jackgoudan #35 期待 blog😊

[Shawns]

根据 @jackgoudan@feedcode 两位大佬的回复，最近对公司生产环境做了 ca 更新，https://www.yuque.com/noteol/kpyoe2/pc6svhqmca9rvp5g 供大家参考