GKE on VMware 使用证书和私钥对用户集群中系统组件之间的连接进行身份验证和加密。管理员集群会为每个用户集群创建一组新的证书授权机构 (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 证书轮替仅限于 GKE on VMware 自动颁发的证书。它不会更新管理员手动颁发的证书，即使这些证书是由系统 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 和控制平面证书都将在集群创建之日起五年后过期。用户集群的控制平面证书会在每次用户集群升级后的 10 小时内自动轮替，但 CA 不会自动轮替。这意味着，除了常规版本升级之外，还必须每五年至少执行一次 CA 轮替。
为了防止用户集群不可用，控制平面证书会在用户集群升级后的 10 小时内轮替。发生这种情况时，用户集群的 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 输出。