咨询下 k8 大佬一些问题

[jackgoudan]

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

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

[kindom]

cert-manager?

[jackgoudan]

@kindom 没用过这个，主要问题是更新了证书后各种组件重建对现有的服务可能影响很大，同事也没搞过这个，不好评估影响范围。

[jingkong]

把业务迁移到一个 新集群上去。。。。。。。。

[defunct9]

续订就完事了

[asilin]

根证书默认是 10 年有效期，我猜你大概率是 CA 签发的服务证书到期了，这个是默认 1 年有效期

如何更新 CA 签发的服务证书？在每个 master 节点执行下面的命令即可自动续期并生效：
——————————————————————————————————————————
kubeadm certs renew all
kubectl -n kube-system delete pod -l 'component=kube-apiserver'
kubectl -n kube-system delete pod -l 'component=kube-controller-manager'
kubectl -n kube-system delete pod -l 'component=kube-scheduler'
kubectl -n kube-system delete pod -l 'component=etcd'
——————————————————————————————————————————

[DAPTX4869]

ca 不是 10 年有效期吗?

[jackgoudan]

@asilin 不是这个，是的你没看错就是根 ca 到期了，一批相当老的集群初建是根 ca 设置了 5 年

[hzfyjgw]

https://jaegerw2016.github.io/posts/2022/09/21/Kubernetes-Certificate-manual-renewal-operation.html

[jackgoudan]

@DAPTX4869 好老的集群了，而且初建集群时同事设置了 5 年，这会都要到了。

[dancercl]

@kindom 我觉得他说的是 k8s server 和 agent API TLS 的证书，不是里边运行的服务的证书。

[jackgoudan]

和大家澄清下，不是 apiserver.crt 等这种二级证书，是 ca.crt 这个根证书。

[asilin]

@jackgoudan 那就和 kubernetes 没关系了，相当于业务服务的跨主机迁移，让运维同学来操作后续事宜吧。

[jackgoudan]

看了下文档更新 ca 的流程： https://kubernetes.io/docs/tasks/tls/manual-rotation-of-ca-certificates/ 内容也不少

[Judoon]

你确定是根 ca 过期？
各种集群初始化创建工具自签证书时，ca 都是 100 年起步的。倒是通过根 ca 签给 etcd 或者 kubelet 等组件的时候大概率会只有一年。看你怎么创建的集群，kubeadm 的话，一般可以通过 kubeadm certs renew 去更新

其他的话，自己逐个替换证书，挺烦的，容易出错

[NeroKamin]

@defunct9 老哥，你咋不让他开 SSH 你上去看看了

[jackgoudan]

@Judoon 是呀，耳机证书过期了 renew 下就完了，没必要上论坛了。hh

[ysicing]

@NeroKamin 估计 ssh 哥嫌麻烦哈哈哈

[feedcode]

证书签名是公钥签的，所以你只需要更新 ca.crt 就可以了，不需要更新二级根证书和各个服务的证书

# 更新 ca.crt
openssl x509 -x509toreq -in ca.crt -signkey ca.key -out new-server.csr
openssl x509 -req -days 3650 -in new-server.csr -signkey ca.key -out new-cacert.pem

# 验证，老的 ca.crt 和新的 new-cacert.pem 都是可以通过的
openssl verify -CAfile new-cacert.pem -verbose server.crt
openssl verify -CAfile ca.crt -verbose server.crt

只需要把 new-cacert.pem 替换成 ca.crt ， 然后每个 node 都重启下就 ok 了

[defunct9]

最烦换证书，就不登了 @NeroKamin

[DAPTX4869]

@feedcode #18 等 OP 测试结果

[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 供大家参考