由于安全性的考虑，k8s 默认生成的 https 证书，默认有效期为1年。在运维集群的过程中，这个因素一定要有所考虑。
解决这个问题的办法，有如下几个办法：
- 定期更新证书
- 定期升级集群，因为每次升级过程中都会更新证书
- 改代码把生成的证书的有效期设置为10年或更长时间
下文就依次探讨这些方式。
手动触发更新证书的方式
注意： 手动更新证书的时候，需要每台 master 都要更新
# #检查证书有效期
# kubeadm alpha certs check-expiration
CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
admin.conf Sep 25, 2020 11:32 UTC 184d no
apiserver Sep 25, 2020 11:32 UTC 184d no
apiserver-etcd-client Sep 25, 2020 11:20 UTC 184d no
apiserver-kubelet-client Sep 25, 2020 11:32 UTC 184d no
controller-manager.conf Sep 25, 2020 11:32 UTC 184d no
etcd-healthcheck-client Sep 25, 2020 11:20 UTC 184d no
etcd-peer Sep 25, 2020 11:20 UTC 184d no
etcd-server Sep 25, 2020 11:19 UTC 184d no
front-proxy-client Sep 25, 2020 11:32 UTC 184d no
scheduler.conf Sep 25, 2020 11:32 UTC 184d no
# # 在一台 master 上执行更新证书的操作
#kubeadm alpha certs renew all
certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
certificate for serving the Kubernetes API renewed
certificate the apiserver uses to access etcd renewed
certificate for the API server to connect to kubelet renewed
certificate embedded in the kubeconfig file for the controller manager to use renewed
certificate for liveness probes to healthcheck etcd renewed
certificate for etcd nodes to communicate with each other renewed
certificate for serving etcd renewed
certificate for the front proxy client renewed
certificate embedded in the kubeconfig file for the scheduler manager to use renewed
# #再次检查证书有效期
# kubeadm alpha certs check-expiration
CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
admin.conf Mar 25, 2021 03:07 UTC 364d no
apiserver Mar 25, 2021 03:07 UTC 364d no
apiserver-etcd-client Mar 25, 2021 03:07 UTC 364d no
apiserver-kubelet-client Mar 25, 2021 03:07 UTC 364d no
controller-manager.conf Mar 25, 2021 03:07 UTC 364d no
etcd-healthcheck-client Mar 25, 2021 03:07 UTC 364d no
etcd-peer Mar 25, 2021 03:07 UTC 364d no
etcd-server Mar 25, 2021 03:07 UTC 364d no
front-proxy-client Mar 25, 2021 03:07 UTC 364d no
scheduler.conf Mar 25, 2021 03:07 UTC 364d no
# 在每台 master 集群都操作，或将生成的证书同步到其他 master 机器上
rsync -Pav -e "ssh -p 22" /etc/kubernetes/pki/ root@<master-ip>:/etc/kubernetes/pki/
参考：
https://kubernetes.cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
升级集群的时候，会自动更新证书
每次升级，只允许 1.y.z ==> 1.y.n 或者 1.y ==> 1.y+1
不允许跨多个版本的升级，比如不允许 1.14 升级到 1.16
注意：升级节点经常会遇到配置不兼容、起不来等问题，需要先在非线上环境进行验证，再操作。
kubeadm upgrade apply 在任意一台master机器操作即可。
# 先在非主节点安装新版本的包，并确认节点状态为 READY
apt install -y kubeadm kubectl kubelet
kubectl get nodes
# 在主节点安装新版本的包
# 驱逐该主 master 节点
kubectl drain <cp-node-name> --ignore-daemonsets
# 检查升级的版本
kubeadm upgrade plan
# 升级集群的配置文件
kubeadm upgrade apply v1.17.4
参考：
https://kubernetes.cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
修改代码，将证书时间改为 30 年
此处以 1.17 代码为例，
文件 cmd/kubeadm/app/constants/constants.go ：
再 CertificateValidity 变量下一行，再重新赋值一遍
CertificateValidity = time.Hour * 24 * 365
CertificateValidity = time.Hour * 24 * 365 * 30
总结
以上三种方法，各有优缺点。
通过修改代码的方式，需要在集群部署时，编译 kubeadm，初始化的时候繁琐。
通过升级集群的方式，意味着基本上每隔大半年需要把所有管理的集群都升级一遍。管理的工作量略大，不一定每个团队都能接受。
通过手动触发更新证书的方式，可以结合 crontab ，似乎比较简单的达到想要的效果。当然， kubernetes 的升级机制决定了，我们必须要紧跟上游，至少每个小版本都要升级上来，不然积重难返，造成无法升级。
