本文档介绍了如何为 Google Distributed Cloud 手动续订过期的证书。Google Distributed Cloud 的控制平面组件使用传输层安全协议 (TLS) 证书。这些证书过期后，您将无法管理工作负载，并且集群生命周期会被阻止，直到证书可以续订为止。如需详细了解过期证书的影响，请参阅证书过期。
默认情况下，TLS 证书的有效期为 1 年。Google Distributed Cloud 会在集群升级期间和轮替证书授权机构时自动续订这些证书。我们建议您定期升级集群，以确保其安全且受支持，并防止 TLS 证书过期。
如果您需要其他帮助，请与 Cloud Customer Care 联系。证书过期导致的错误
如果集群上的 TLS 证书过期，则核心控制器无法与 Kubernetes API 服务器建立 TLS 连接。缺少连接会导致以下错误：
无法连接到服务器：x509
当您使用
kubectl获取集群节点时，响应会包含证书已过期的错误，类似于以下示例输出：Unable to connect to the server: x509: certificate has expired or is not yet valid无法连接：x509 或连接遭拒
过期的证书会阻止对 etcd 集群的访问，因为对等方无法相互通信。etcd 日志可能包含如下所示的错误条目：
W | rafthttp: health check for peer 6221a1d241bb2d0a could not connect: x509: certificate has expired or is not yet valid I | embed: rejected connection from "10.200.0.4:46108" (error "remote error: tls: bad certificate", ServerName "")
检查证书过期时间
如需检查证书到期时间，请在每个控制平面节点上执行以下步骤：
登录其中一个控制平面节点机器，然后运行以下命令：
sudo kubeadm certs check-expiration命令输出列出了
kubeadm为控制平面组件创建的证书及其过期时间，如以下示例输出所示：CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Nov 28, 2021 19:09 UTC 53m no apiserver Nov 28, 2021 19:09 UTC 53m ca no apiserver-etcd-client Nov 28, 2021 19:09 UTC 53m etcd-ca no apiserver-kubelet-client Nov 28, 2021 19:09 UTC 53m ca no controller-manager.conf Nov 28, 2021 19:09 UTC 53m no etcd-healthcheck-client Nov 28, 2021 19:09 UTC 53m etcd-ca no etcd-peer Nov 28, 2021 19:09 UTC 53m etcd-ca no etcd-server Nov 28, 2021 19:09 UTC 53m etcd-ca no front-proxy-client Nov 28, 2021 19:09 UTC 53m front-proxy-ca no scheduler.conf Nov 28, 2021 19:09 UTC 53m no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Nov 26, 2031 18:06 UTC 9y no etcd-ca Nov 26, 2031 18:06 UTC 9y no front-proxy-ca Nov 26, 2031 18:06 UTC 9y no运行以下命令以检查
kubelet证书的过期时间：sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2 sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2每个命令的响应类似于以下示例输出：
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT如果同时引导了所有控制平面节点，则证书过期时间彼此之间的间隔不超过几分钟。此时间关系适用于所有控制平面节点。您可以通过在每个控制平面节点上运行上述命令来验证过期时间。
在管理员工作站上运行以下命令，以检查集群 kubeconfig 文件中的客户端证书的过期时间：
grep 'client-certificate-data' KUBECONFIG_PATH | \ awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2响应如以下示例输出所示：
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT运行以下命令以查找管理员集群中的集群 kubeconfig 的证书过期时间：
kubectl get secret/CLUSTER_NAME-kubeconfig -n CLUSTER_NAMESPACE -o --kubeconfig=ADMIN_KUBECONFIG jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2响应如以下示例输出所示：
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT管理员集群中的 kubeconfig 证书和管理员工作站上 kubeconfig 文件中的证书相同。因此，此命令的输出与上一步中命令的输出必须匹配。
手动续订证书
如需手动为集群续订 TLS 证书，请按照以下部分中的说明操作。
在每个控制平面节点上续订证书
请在受影响的集群的每个控制平面节点上执行以下步骤：
备份
/etc/kubernetes文件夹。运行以下
kubeadm命令以续订所有证书。该命令使用机器上现有的证书授权机构 (CA) 续订证书：sudo kubeadm 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通过运行以下命令来验证证书是否有新的过期时间：
sudo kubeadm certs check-expiration并非所有控制平面组件都支持动态证书重新加载。要获取续期的证书，请执行以下步骤重启以下容器：
kube-apiserver、kube-scheduler、kube-controller-manager和etcd。对四个容器中的每个容器重复以下步骤：
找到每个容器的 ID：
sudo crictl ps | grep CONTAINER_NAME将
CONTAINER_NAME替换为容器kube-apiserver、kube-scheduler、kube-controller-manager或etcd（不是etcd-defrag）的名称。响应如以下输出所示：
c331ade490cb6 28df10594cd92 26 hours ago Running kube-apiserver ...容器 ID 是第一列中的值。
停止每个容器：
sudo crictl stop CONTAINER_ID将 CONTAINER_ID 替换为上一步中的容器 ID。
当已停止的容器退出时，kubelet 会在其位置创建一个新容器，然后删除已停止的容器。如果遇到错误，例如
context deadline exceeded（错误代码DeadlineExceeded），请重新运行该命令。
验证连接已恢复
现在，所有控制平面节点上的 kubeadm 证书应该都会续订。如果您要续订过期的证书，请执行以下步骤：
如需验证与 Kubernetes API 服务器的连接，请在任何控制平面节点上运行以下
kubectl命令：kubectl get nodes --kubeconfig=/etc/kubernetes/admin.conf
响应应返回集群的节点列表。如果您的证书已正确续订，则系统不会返回 TLS 或证书错误。
替换集群 kubeconfig 文件
如需将集群的 kubeconfig 文件替换为包含已续订证书的 kubeconfig 文件，请按照以下步骤操作：
如需创建新的 kubeconfig 文件，请在管理员工作站上运行以下
kubectl命令：kubectl --kubeconfig="ADMIN_KUBECONFIG" get secret/CLUSTER_NAME-kubeconfig \ -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}' | base64 --decode > new_kubeconfig.conf请替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
CLUSTER_NAME：您要为其续订证书的集群的名称。
CLUSTER_NAMESPACE：您要为其续订证书的集群的命名空间。
new_kubeconfig.conf文件包含更新后的证书数据。使用新凭据，通过运行任何
kubectl命令来验证新 kubeconfig 是否有效：kubectl get nodes --kubeconfig new_kubeconfig.conf将管理员工作站上集群目录中保存的旧 kubeconfig 文件的内容替换为新 kubeconfig 文件
new-kubeconfig.conf的内容。默认情况下，集群配置文件的路径为
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig。
验证 kubelet 证书并重启 etcd-defrag
如需完成手动续订集群证书的过程，请对每个控制平面节点执行以下步骤：
登录控制平面节点，并通过运行以下命令验证 kubelet 客户端和服务证书的过期时间：
只要控制平面可访问，Kubelet 证书就会自动轮替。kubelet 证书的自动续订期比控制平面组件证书的有效期短。因此，kubelet 证书的续期可能如下：
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2 sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2任一命令的输出如以下示例所示：
Validity Not Before: Nov 28 18:04:57 2022 GMT Not After : Nov 28 19:04:57 2023 GMT使用以下命令重启
etcd-defrag容器：etcd-defrag容器使用apiserver-etcd客户端证书与 etcd 通信，并且必须重启才能获取更新后的证书。kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
完成这些手动步骤以续订集群证书后，请验证所有 Pod 是否正常运行，并且没有针对控制平面容器报告任何 TLS 错误。