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。此外，该命令还会报告一个指示 CA 轮替是否完成的状态（True或False）以及一条描述每个系统组件当前正在使用的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 和控制平面证书将在集群创建之日起 5 年后过期。用户集群的控制平面证书会在每个用户集群升级后的 10 小时内自动轮替，但 CA 不会自动进行轮替。这意味着，除了常规版本升级之外，CA 轮替必须至少每 5 年执行一次。
为了防止用户集群不可用，控制平面证书会在用户集群升级后 10 小时内轮替。当这种情况发生时，用户集群的 CA 轮替状态中会显示一条消息。
如需查看用户集群在控制平面证书轮替时升级到的最后一个版本，请执行以下操作：
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
此信息会在升级后的 10 小时内显示在 message 字段的末尾。例如：
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
排查 CA 轮替问题
gkectl diagnose 命令支持针对用户集群检查已完成的 CA 轮替的预期状态。如需了解如何在用户集群上运行 gkectl diagnose，请参阅诊断集群问题。如果您遇到 CA 轮替问题，请与 Google 支持团队联系并提供 gkectl diagnose 输出。