Kubelet 证书自动续签
K8s证书一般分为两套：K8s组件（apiserver）和Etcd，假如按角色来分，证书分为管理节点和工作节点。
• 管理节点：如果是kubeadm部署则自动生成，如果是二进制部署一般由cfssl或者openssl生成。
• 工作节点：工作节点主要是指kubelet连接apiserver所需的客户端证书，这个证书由controller-manager组件自动颁发，默认是一年，如果到期，kubelet将无法使用过期的证书连接apiserver，从而导致无法正常工作，日志会给出证书过期错误（x509: certificate has expired or is not yet valid）（工作节点容易忽略掉证书有效期）
二进制，这个是k8s apiserver的一套证书
[root@k8s-master ~]# ls /opt/kubernetes/ssl/
ca-key.pem kubelet-client-2020-09-30-11-12-16.pem kubelet.crt server-key.pem
ca.pem kubelet-client-current.pem kubelet.key server.pem
这个是apiserver连接etcd所需要的证书
[root@k8s-master ~]# ls /opt/etcd/ssl/
ca-key.pem ca.pem server-key.pem server.pem
kubeadm部署的两套证书都放在这里
[root@k8s-master ~]# ls /etc/kubernetes/pki/
apiserver.crt etcd
apiserver-etcd-client.crt front-proxy-ca.crt
apiserver-etcd-client.key front-proxy-ca.key
apiserver.key front-proxy-client.crt
apiserver-kubelet-client.crt front-proxy-client.key
apiserver-kubelet-client.key sa.key
ca.crt sa.pub
ca.key
不管你是kubeadm安装的还是二进制安装的，管理节点不管证书有效期有多长5年，10年，工作节点证书有效期限都是1年， 就会出现证书过期的情况。
红线：K8s自建证书颁发机构（CA），需携带由它生成的客户端证书访问apiserver
蓝色：Etcd自建证书颁发机构（CA），需携带由它生成的客户端证书访问etcd
自签证书和机构证书不同：加密强度不同和浏览器显示的不一样
证书是要配置在组件上面，这三个组件是管理节点部署的
Kube-apiserver controller-manager scheduler
如果Kube-apiserver controller-manager scheduler这三个组件部署在一块，那么都是使用非安全端口去访问，也就是apiserver提供了两个端口（对本地127.0.0.1:8080,对外的就是ip:6443）
Kubelet 证书自动续签
Kubeadm没有提供设置证书时间的参数，有效期是一年，获取集群证书过期时间
容易过期的是ca证书派发出来的证书文件，这里的过期时间是客户端的证书。（因为ca证书有效期是10年，足够用了，主要过期的是ca派发出来的证书）
一年之后要更新集群的版本或者更新证书
kubeadm alpha certs renew对证书升级重新续约证书或者升级k8s版本kubeadm upgrade，在升级版本的时候会续签一年，最好一年升级一次
二进制部署方式
如果你采用的二进制方式部署，已经配置了默认是5年，所以在5年之前不会出现证书过期的问题。找一台节点查看∶
[root@k8s-master ssl]# ls
ca-key.pem kubelet-client-2022-03-25-21-23-51.pem kubelet.crt server-key.pem
ca.pem kubelet-client-current.pem kubelet.key server.pem
[root@k8s-master ssl]# openssl x509 -in kubelet-client-current.pem -noout -datesnotBefore=Mar 25 13:18:51 2022 GMT
notAfter=Mar 24 11:58:00 2027 GMT
[root@k8s-master ssl]# pwd
/opt/kubernetes/ssl
#查看kubelet.crt 查看
#默认一年
openssl x509 -in kubelet-client-current.pem -noout -text | grep "Not"
openssl x509 -in server.crt -text
openssl x509 -in /etc/kubernetes/ssl/kubelet.crt -noout -text | grep -A2 "Validity"
启用 TLS Bootstrapping 机制
TLS Bootstraping：Master apiserver启用TLS认证后，Node节点kubelet和kube-proxy要与kube-apiserver进行通信，必须使用CA签发的有效证书才可以，当Node节点很多时，这种客户端证书颁发需要大量工作，同样也会增加集群扩展复杂度。为了简化流程，Kubernetes引入了TLS bootstraping机制来自动颁发客户端证书，kubelet会以一个低权限用户自动向apiserver申请证书，kubelet的证书由apiserver动态签署。所以强烈建议在Node上使用这种方式，目前主要用于kubelet，kube-proxy还是由我们统一颁发一个证书。
TLS bootstraping 工作流程：