Anthos clusters on VMware (GKE On-Prem) 使用证书和私钥来对用户集群中系统组件之间的连接进行身份验证和加密。管理员集群会为每个用户集群创建一组新的证书授权机构 (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 轮替功能的影响。
限制
- Anthos clusters on VMware 1.8 及更高版本的集群支持使用用户集群 CA 轮替功能。
- 用户集群 CA 轮替功能仅限于概览中提到的 etcd、集群和前端代理 CA。此功能不会轮替您的组织 CA。此外，用户集群 CA 轮替功能还仅限于 Anthos clusters on VMware 自动颁发的证书。此功能不会更新管理员手动颁发的证书，即使这些证书是由系统 CA 签名的。
- CA 轮替期间必须多次重启 API 服务器、其他控制层面进程以及集群中的每个节点。CA 轮替的每个阶段都与集群升级类似。虽然用户集群在 CA 轮替期间仍可正常工作，但系统会重启和重新调度工作负载。未使用高可用性配置时，控制层面还会出现短暂停机。
- CA 轮替完成后，必须手动更新和重新分发用于连接到用户集群的用户集群 kubeconfig 文件和身份验证配置文件。这是因为 CA 轮替必然会撤消旧 CA，因此系统不会再针对这些凭据进行身份验证。
- CA 轮替启动后，将无法暂停或回滚。
- CA 轮替可能需要相当长的时间才能完成，具体取决于用户集群的大小。
如何执行 CA 轮替
您可以通过运行以下 gkectl 命令来启动 CA 轮替并查看轮替的当前状态。
轮替 CA 证书
如需触发 CA 轮替，请执行以下命令。
gkectl update credentials certificate-authorities rotate \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
其中：
- USER_CONFIG_FILE 是要为其轮替 CA 的用户集群的用户集群配置文件的路径。
- ADMIN_KUBECONFIG_FILE 是用于连接到管理用户集群的管理员集群的 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
查看 CA 轮替状态
如需查看 CA 轮替的状态，请执行以下命令。此命令会报告 CAVersion，这是一个整数，系统会自动递增该数字，以区分每次 CA 轮替前后使用的 CA；此外，此命令还会报告一个指示 CA 轮替是否完成的状态（True 或 False）以及一条描述每个系统组件当前正在使用的 CAVersion 的消息。
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
如果 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 文件，以替换之前用于连接用户集群的旧 kubeconfig。这是因为 CA 轮替会撤消旧 kubeconfig 文件所基于的旧 CA。在 CA 轮替完成后运行以下命令，以下载新的 kubeconfig 文件：
kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
如果有额外的 kubeconfig 文件已手动颁发给集群的其他用户，则也必须对这些文件进行更新。
更新身份验证配置文件
CA 轮替完成后，必须更新并重新分发身份验证配置文件。按照链接中的说明，在 CA 轮替完成后更新并重新分发以下文件：
排查 CA 轮替问题
gkectl diagnose 命令支持针对用户集群检查已完成的 CA 轮替的预期状态。如需了解如何在用户集群上运行 gkectl 诊断，请参阅诊断集群问题。如果您遇到 CA 轮替问题，请与 Google 支持团队联系并提供 gkectl diagnose 输出。