Google Distributed Cloud 使用证书和私钥对用户集群中系统组件之间的连接进行身份验证和加密。管理员集群为每个用户集群创建了一组新的证书授权机构 (CA)，并使用 CA 证书为系统组件颁发额外的叶证书。管理员集群负责管理将公共 CA 证书和叶证书密钥对分发到系统组件，以建立其安全通信。
通过用户集群 CA 轮替功能，您可以触发用户集群中核心系统证书的轮替。在轮替期间，管理员集群会将用户集群的核心系统 CA 替换为新生成的 CA，并将新的公共 CA 证书和叶证书密钥对分发给用户集群的系统组件。轮替是渐进式进行的，因此系统组件可以在轮替期间继续正常通信。但请注意，工作负载和节点会在轮替期间重启。
每个用户集群有三个由管理员集群管理的系统 CA：
- etcd CA 可保护从 API 服务器到 etcd 副本之间的通信，以及 etcd 副本之间的流量。此 CA 是自签名的。
- 集群 CA 可保护 API 服务器与所有内部 Kubernete API 客户端（kubelet、控制器、调度程序）之间的通信。 此 CA 是自签名的。
- 前端代理 CA 可保护与聚合 API 之间的通信。此 CA 是自签名的。
此外，您可能正在使用组织 CA 对 authentication.sni 选项配置的证书进行签名。此 CA 和 SNI 证书一起用于向集群外部的客户端提供 Kubernetes API。您负责管理此 CA 并手动生成 SNI 证书。此 CA 和 SNI 证书均不受用户集群 CA 轮替功能的影响。
限制
CA 证书轮替仅限于前面提到的 etcd、集群和前端代理 CA。
CA 证书轮替仅限于 Google Distributed Cloud 自动颁发的证书。它不会更新管理员手动颁发的证书，即使这些证书是由系统 CA 签名的。
CA 轮替会多次重启 API 服务器、其他控制平面进程和集群中的每个节点。CA 轮替的每个阶段都与集群升级类似。虽然用户集群在 CA 轮替期间确实会保持运行，但您应该知道工作负载会重启并重新安排。如果用户集群没有高可用性控制平面，也应该会出现控制平面停机的现象。
您必须在 CA 轮替后更新用户集群 kubeconfig 文件和身份验证配置文件。这是因为旧集群证书已被撤消，并且 kubeconfig 文件中的凭据不再有效。
CA 轮替一旦启动，便无法暂停或回滚。
CA 轮替可能需要很长时间才能完成，具体取决于用户集群的大小。
执行 CA 轮替
启动轮替：
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG请替换以下内容：
USER_CLUSTER_CONFIGE：用户集群配置文件的路径
ADMIN_CLUSTER_KUBECONFIG：管理员集群 kubeconfig 文件的路径
如果 CA 轮替成功启动，您会看到类似于以下内容的消息：
successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
如果 CA 轮替已在进行中，您会看到类似于以下内容的错误消息：
Exit with error: admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads
查看轮替状态：
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG上述命令报告
CAVersion，这是一个整数，系统会自动递增以区分轮替前后使用的 CA。该命令还会报告一个状态（True或False），指示 CA 轮替是否已完成，并提供一条消息，说明系统的每个组件当前正在使用哪个CAVersion。如果 CA 轮替已完成，您会看到类似于以下内容的消息：
State of CARotation with CAVersion 2 is - status: True, reason: CARotationCompleted, message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.
如果 CA 轮替仍在进行中，您会看到如下所示的消息：
State of CARotation with CAVersion 2 is - status: False, reason: CARotationProgressed, message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.
更新用户集群凭据
CA 轮替完成后，您必须从管理员集群获取新用户集群 kubeconfig 文件。这是因为 CA 轮替撤消了旧 kubeconfig 文件所基于的 CA。
获取新的 kubeconfig 文件：
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
将新的 kubeconfig 文件分发给使用 kubeconfig 文件与集群交互的所有用户。
更新身份验证配置文件
CA 轮替完成后，必须更新并重新分发身份验证配置文件。按照链接中的说明，在 CA 轮替完成后更新并重新分发以下文件：
控制平面证书轮替
如果不轮替，用户集群 CA 和控制平面证书都会从集群创建之日起五年后过期。用户集群的控制平面证书会在每个用户集群升级后的 10 小时内自动轮替，但 CA 不会自动轮替。这意味着除了常规版本升级之外，必须至少每五年执行一次 CA 轮替。
为防止用户集群不可用，控制平面证书会在用户集群升级后的十小时内轮替。发生这种情况时，用户集群的 CA 轮替状态中会显示一条消息。
如需查看轮替控制平面证书时用户集群升级到的最后一个版本，请执行以下操作：
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
这些信息会在升级后的十小时内显示在 message 字段的末尾。例如：
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
排查 CA 轮替问题
gkectl diagnose 命令支持针对用户集群检查已完成的 CA 轮替的预期状态。如需了解如何在用户集群上运行 gkectl diagnose，请参阅诊断集群问题。如果您遇到 CA 轮替问题，请与 Google 支持团队联系并提供 gkectl diagnose 输出。