VMware 上的 Anthos 集群

选择 Anthos Clusters on VMware 版本：

选择问题类别：

或者，搜索您的问题：

类别 已识别的版本 问题和解决方法
操作 1.8、1.9、1.10

etcd 维护 pod 的内存使用量增加问题

使用 etcddefrag:gke_master_etcddefrag_20210211.00_p0 映像的 etcd 维护 pod 会受到影响。“etcddefrag”容器会在每个碎片周期内打开与 etcd 服务器的新连接，并且旧连接不会被清理。


临时解决方法：

方法 1：升级到最新的 1.8 到 1.11 补丁版本，其中包含修复代码。

方法 2：如果您使用的是早于 1.9.6 和 1.10.3 的补丁版本，则需要缩减管理员集群和用户集群的 etcd 维护 Pod：


kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
操作 1.9、1.10、1.11、1.12、1.13

错过用户集群控制平面 Pod 的健康检查

集群健康控制器和 gkectl diagnose cluster 命令都会执行一组健康检查，包括跨命名空间的 pod 健康检查。但是，它们会开始错误地跳过用户控制平面 Pod。如果您使用控制平面 v2 模式，则不会影响集群。


临时解决方法：

这不会影响任何工作负载或集群管理。如果要检查控制平面 pod 的运行状况，您可以运行以下命令：


kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
升级和更新 1.6+、1.7+

1.6 和 1.7 管理员集群升级可能会受到 k8s.gcr.io -> registry.k8s.io 重定向的影响

Kubernetes 在 2023 年 3 月 20 日将流量从 k8s.gcr.io 重定向到 registry.k8s.io。在 Anthos Clusters on VMware 1.6.x 和 1.7.x 中，管理员集群升级使用容器映像 k8s.gcr.io/pause:3.2。如果您为管理员工作站使用代理，该代理不允许 registry.k8s.io，并且容器映像 k8s.gcr.io/pause:3.2 未在本地缓存，则在拉取容器映像时管理员集群升级将失败。


临时解决方法：

将 registry.k8s.io 添加到管理员工作站的代理许可名单。
网络 1.10、1.11、1.12.0-1.12.6、1.13.0-1.13.6、1.14.0-1.14.2

负载均衡器创建时 Seesaw 验证失败

gkectl create loadbalancer 失败，并显示以下错误消息：


- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

这是因为 Seesaw 群组文件已存在。预检检查会尝试验证不存在的 Seesaw 负载均衡器。

临时解决方法：

移除此集群的现有 Seesaw 群组文件。对于管理员集群，该文件名为 seesaw-for-gke-admin.yaml；对于用户集群，该文件名为 seesaw-for-{CLUSTER_NAME}.yaml。
网络 1.14

conntrack 表插入失败导致应用超时

使用 Ubuntu 或 COS 操作系统映像时，Anthos Clusters on VMware 1.14 版容易发生 netfilter 连接跟踪 (conntrack) 表插入失败。插入失败会导致随机应用超时，即使 conntrack 表有空间可用于添加新条目，也可能会发生这种情况。失败是由内核 5.15 及更高版本中的更改引起的，这些更改根据链长度限制表插入。

如需查看您是否受到此问题的影响，您可以使用以下命令检查每个节点上的内核内连接跟踪系统统计信息：


sudo conntrack -S

响应如下所示：


cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

如果响应中的 chaintoolong 值为非零数字，则表示您受到此问题的影响。

临时解决方法

短期缓解措施是增加 netfiler 哈希表 (nf_conntrack_buckets) 和 netfilter 连接跟踪表 (nf_conntrack_max) 的大小。在每个集群节点上使用以下命令来增加表的大小：


sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

将 TABLE_SIZE 替换为新的大小（以字节为单位）。默认表大小值为 262144。我们建议您设置一个等于节点核心数 65,536 倍的值。例如，如果您的节点有 8 个核心，请将表大小设置为 524288。
网络 1.13.0-1.13.2

使用 Controlplane v2 的 Windows 节点上的 calico-typha 或 anetd-operator 陷入崩溃循环

使用 Controlplane v2 或新的安装模型时，calico-typha 或 anetd-operator 可能会被调度到 Windows 节点并陷入崩溃循环。

这是因为这两个部署可以容忍所有污点，包括 Windows 节点污点。


临时解决方法：

升级到 1.13.3+，或运行以下命令以修改“calico-typha”或“anetd-operator”部署：


    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

移除以下 spec.template.spec.tolerations：


    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

并添加以下容忍设置：


    - key: node-role.kubernetes.io/master
      operator: Exists
配置 1.14.0-1.14.2

无法加载用户集群私有注册表凭据文件

如果您使用凭据 fileRef 指定 privateRegistry 部分，则可能无法创建用户集群。 预检可能会失败，并显示以下消息： 


[FAILURE] Docker registry access: Failed to login.


临时解决方法：

  • 如果您不打算指定此字段，或者想要使用与管理员集群相同的私有注册表凭据，则只需移除或注释掉用户集群配置文件中的 privateRegistry 部分即可。
  • 如果您想要为用户集群使用特定的私有注册表凭据，则可以通过以下方式暂时指定 privateRegistry 部分：
    
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
    （注意：这只是暂时性的修复方法并且这些字段已被弃用，请考虑在升级到 1.14.3+ 时使用凭据文件。）
运维 1.10+

Anthos Service Mesh 和其他服务网格与 Dataplane v2 不兼容

Dataplane V2 接管负载均衡，并创建内核套接字，而不是基于数据包的 DNAT。这意味着 Anthos Service Mesh 无法执行数据包检查，因为 Pod 被绕过并且从不使用 IPTable。

此问题会在 kube-proxy 免费模式下出现，表现为 Anthos Service Mesh 服务连接中断或流量路由不正确，因为边车代理无法执行数据包检查。

所有版本的 Anthos Clusters on Bare Metal 1.10 都存在此问题，但某些较新的 1.10 版本 (1.10.2+) 提供了临时解决方法。


临时解决方法：

升级到 1.11 以实现完全兼容；如果运行 1.10.2 或更高版本，请运行以下命令：


    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

将 bpf-lb-sock-hostns-only: true 添加到 configmap，然后重启 anetd daemonset：


      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

存储 1.12+、1.13.3

kube-controller-manager 可能会在 6 分钟后强制分离永久性卷

在分离 PV/PVC 时，kube-controller-manager 可能会在 6 分钟后超时，并强制分离 PV/PVC。来自 kube-controller-manager 的详细日志会显示类似于以下内容的事件：


$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

如需验证问题，请登录节点并运行以下命令：


# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

kubelet 日志中会显示如下错误：


Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

临时解决方法：

使用 SSH 连接到受影响的节点，然后重新启动该节点。
升级和更新 1.12+、1.13+、1.14+

如果使用第三方 CSI 驱动程序，集群升级会卡住

如果您使用第三方 CSI 驱动程序，则可能无法升级集群。gkectl cluster diagnose 命令可能会返回以下错误：


"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


临时解决方法：

使用 --skip-validation-all 选项执行升级。
操作 1.10+、1.11+、1.12+、1.13+、1.14+

gkectl repair admin-master 创建管理员主虚拟机而不升级其虚拟机硬件版本

通过 gkectl repair admin-master 创建的管理员主节点可能使用低于预期的虚拟机硬件版本。发生此问题时，您会在 gkectl diagnose cluster 报告中看到错误。 


CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


临时解决方法：

关停管理员主节点，遵循 https://kb.vmware.com/s/article/1003746 将节点升级到错误消息中所述的预期版本，然后启动节点。
操作系统 1.10+、1.11+、1.12+、1.13+、1.14+

虚拟机在意外关停/重新启动时释放 DHCP 租约，这可能会导致 IP 地址更改

在 systemd v244 中，systemd-networkd 会对 KeepConfiguration 配置进行默认行为更改。在此更改之前，虚拟机不会在关停或重新启动时向 DHCP 服务器发送 DHCP 租约释放消息。在此更改之后，虚拟机会向 DHCP 服务器发送此消息并返回 IP 地址。因此，系统可能会将释放的 IP 地址重新分配给其他虚拟机，并且/或者可能为虚拟机分配其他 IP 地址，从而导致虚拟机 IP 地址冲突（在 Kubernetes 级层而不是 vSphere 级层）和/或 IP 地址更改，这可能会以各种方式破坏集群。

例如，您可能会看到以下症状。

  • vCenter 界面显示没有虚拟机使用相同的 IP 地址，但 kubectl get nodes -o wide 返回具有重复 IP 地址的节点。
    
NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
  • 由于 calico-node 错误，新节点无法启动 
    
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


临时解决方法：

在集群上部署以下 DaemonSet 以还原 systemd-networkd 默认行为更改。运行此 DaemonSet 的虚拟机在关停/重新启动时不会向 DHCP 服务器释放 IP 地址。租约到期时，DHCP 服务器会自动释放 IP 地址。 


      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

运营、升级和更新 1.12.0+、1.13.0+、1.14.0+

管理员集群从 1.11.x 版升级后，组件访问服务帐号密钥被擦除

此问题仅会影响从 1.11.x 版升级的管理员集群，不会影响 1.12 版之后新创建的管理员集群。

将 1.11.x 版集群升级到 1.12.x 版后，admin-cluster-creds Secret 中的 component-access-sa-key 字段会被擦除为空。您可以通过运行以下命令进行检查： 


kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
如果您发现输出为空，则表示密钥已被擦除。

在组件访问服务帐号密钥被删除后，安装新用户集群或升级现有用户集群将失败。下面列出了您可能会遇到的一些错误消息：

  • 缓慢验证预检失败，并显示错误消息："Failed to create the test VMs: failed to get service account key: service account is not configured."
  • gkectl prepare 准备失败，并显示错误消息："Failed to prepare OS images: dialing: unexpected end of JSON input"
  • 如果您在使用 Google Cloud 控制台或 gcloud CLI 升级 1.13 版用户集群，则在运行 gkectl update admin --enable-preview-user-cluster-central-upgrade 以部署升级平台控制器时，该命令会失败并显示以下消息："failed to download bundle to disk: dialing: unexpected end of JSON input"（您可以在 kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml 输出的 status 字段中看到此消息）。


解决方法：

通过运行以下命令，手动将组件访问服务帐号密钥添加回 Secret： 


kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
操作 1.13.0+、1.14.0+

启用 Controlplane V2 后，集群自动扩缩器不起作用

对于使用 Controlplane V2 或新的安装模型创建的用户集群，启用了自动扩缩功能的节点池始终使用其在 user-cluster.yaml 中的 autoscaling.minReplicas。集群自动扩缩器 pod 的日志还会显示其健康状况不佳。 


  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
您可以通过运行以下命令找到集群自动扩缩器 pod。 

  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


解决方法：

使用“gkectl update cluster”停用所有节点池中的自动扩缩功能，直到升级到包含修复的版本
安装 1.12.0-1.12.4、1.13.0-1.13.3、1.14.0

IP 地址块文件中不允许使用 CIDR

当用户在 IP 地址块文件中使用 CIDR 时，配置验证将失败，并显示以下错误：


- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


解决方法：

将各个 IP 添加到 IP 地址块文件中，直到升级到包含以下修补程序的版本：1.12.5、1.13.4、1.14.1+。
升级和更新 1.14.0-1.14.1

admin-cluster.yaml 中的操作系统映像类型更新不会等待重新创建用户控制平面机器

在 admin-cluster.yaml 中更新控制平面操作系统映像类型时，如果其相应的用户集群是通过 Controlplane V2 创建的，则用户控制平面机器在 gkectl 命令完成时可能无法完成其重新创建。


解决方法：

更新完成后，使用 kubectl --kubeconfig USER_KUBECONFIG get nodes -owide 监控节点操作系统映像类型，从而继续等待用户控制平面机器也完成其重新创建。例如，如果从 Ubuntu 更新为 COS，则即使在更新命令完成后，也应该等待所有控制平面机器从 Ubuntu 完全更改为 COS。
操作 1.14.0

Calico CNI 服务帐号身份验证令牌问题导致 Pod 创建或删除错误

Anthos Clusters on VMware 1.14.0 中的 Calico 问题导致 Pod 创建和删除失败，并在 kubectl describe pods 的输出中显示以下错误消息：


  error getting ClusterInformation: connection is unauthorized: Unauthorized

此问题仅在使用 Calico 创建集群或升级到 1.14 后的 24 小时内才会观察到。

管理员集群始终使用 Calico，而对于用户集群，user-cluster.yaml 中有一个配置字段“enableDataPlaneV2”，如果该字段设置为“false”，或未指定该字段，则表示您在用户集群中使用 Calico。

节点的 install-cni 容器使用有效期为 24 小时的令牌创建 kubeconfig。此令牌需要定期由 calico-node Pod 进行续订。calico-node Pod 无法续订此令牌，因为它无权访问节点上包含 kubeconfig 文件的目录。


临时解决方法：

为了缓解此问题，请在管理员集群和用户集群中对 calico-node DaemonSet 应用以下补丁：


  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
请替换以下内容：
  • ADMIN_CLUSTER_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
  • USER_CLUSTER_CONFIG_FILE：用户集群配置文件的路径。
安装 1.12.0-1.12.4、1.13.0-1.13.3、1.14.0

使用 CIDR 时 IP 地址块验证失败

尽管用户配置正确，集群创建仍然失败。用户看到由于集群没有足够的 IP 地址导致创建失败。


解决方法：

将 CIDR 拆分为几个较小的 CIDR 地址块，例如将 10.0.0.0/30 变为 10.0.0.0/31, 10.0.0.2/31。只要有 N+1 个 CIDR（其中 N 是集群中的节点数），就足以满足需求。
运营、升级和更新 1.11.0 - 1.11.1、1.10.0 - 1.10.4 和 1.9.0 - 1.9.6

管理员集群备份不包含始终开启的 Secret 加密密钥和配置

启用始终开启的 Secret 加密功能并进行集群备份后，管理员集群备份将无法包含始终开启的 Secret 加密功能所需的加密密钥和配置。因此，使用 gkectl repair admin-master --restore-from-backup 通过此备份修复管理员主节点会导致以下错误：


Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

运营、升级和更新 1.10+

如果使用“gkectl update”命令启用了始终开启的 Secret 加密功能，则使用新的启动磁盘重新创建管理员主节点虚拟机（例如 gkectl repair admin-master）将失败。

如果在创建集群时未启用始终开启的 Secret 加密功能，但之后使用 gkectl update 操作启用，则 gkectl repair admin-master 无法修复管理员集群控制平面节点。建议在创建集群时启用始终开启的 Secret 加密功能。当前没有缓解措施。
升级和更新 1.10

将第一个用户集群从 1.9 升级到 1.10 会在其他用户集群中重新创建节点

将第一个用户集群从 1.9 升级到 1.10 可能会在同一管理员集群下的其他用户集群中重新创建节点。重新创建是以滚动方式执行的。

disk_label 已从 MachineTemplate.spec.template.spec.providerSpec.machineVariables 中移除，这意外触发了所有 MachineDeployment 的更新。


临时解决方法：
升级和更新 1.10.0

Docker 在集群升级后频繁重启

将用户集群升级到 1.10.0 可能会导致 Docker 频繁重启。

您可以通过运行 kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG 来检测此问题

节点条件会显示 Docker 是否频繁重启。以下是示例输出：


Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

如需了解根本原因，您需要通过 SSH 连接到存在该症状的节点，并运行 sudo journalctl --utc -u docker 或 sudo journalctl -x 等命令


临时解决方法：
升级和更新 1.11、1.12

升级到 1.12 版后未保留自行部署的 GMP 组件

如果您使用的是低于 1.12 的 Anthos Clusters on VMware 版本，并且在集群的 gmp-system 命名空间中手动设置了 Google 管理的 Prometheus (GMP) 组件，则在升级到 1.12.x 版时不会保留这些组件。

从 1.12 版开始，gmp-system 命名空间中的 GMP 组件和 CRD 由 stackdriver 对象管理，并且 enableGMPForApplications 标志默认设置为 false。在升级到 1.12 之前，如果您在命名空间中手动部署了 GMP 组件，则 stackdriver 将删除这些资源。


临时解决方法：
操作 1.11、1.12、1.13.0 - 1.13.1

集群快照 system 场景中缺少 ClusterAPI 对象

在 system 场景中，集群快照不包括 default 命名空间下的任何资源。

但是，此命名空间下的某些 Kubernetes 资源（如 Cluster API 对象）包含有用的调试信息。集群快照应包含这些信息。


临时解决方法：

您可以手动运行以下命令来收集调试信息。


export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
其中：

USER_CLUSTER_KUBECONFIG 是用户集群的 kubeconfig 文件。
升级和更新 1.11.0-1.11.4、1.12.0-1.12.3、1.13.0-1.13.1

vSAN 设置的用户集群删除操作在节点排空时停滞

删除、更新或升级用户集群时，在以下情况下节点排空可能会停滞：

  • 从 1.12.x 版开始，管理员集群已在 vSAN 上使用 vSphere CSI 驱动程序，并且
  • 未在管理员集群和用户集群中通过树内 vSphere 插件创建 PVC/PV 对象。

如需找出此症状，请运行以下命令：


kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

以下是来自上述命令的示例错误消息：


E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

kubevols 是 vSphere 树内驱动程序的默认目录。如果未创建 PVC/PV 对象，您可能会遇到 bug，即节点排空在查找 kubevols 时停滞，因为当前实现假定 kubevols 始终存在。


临时解决方法：

在创建节点的数据存储区中创建 kubevols 目录。此操作在 user-cluster.yaml 或 admin-cluster.yaml 文件的 vCenter.datastore 字段中定义。
配置 1.7、1.8、1.9、1.10、1.11、1.12、1.13

删除用户集群后，管理员集群 cluster-health-controller 和 vsphere-metrics-exporter 无法正常工作

删除用户集群时，相应的 clusterrole 也会被删除，从而导致自动修复和 vSphere 指标导出器无法正常工作

症状如下：

  • cluster-health-controller 日志
    • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
    其中，ADMIN_CLUSTER_KUBECONFIG 是管理员集群的 kubeconfig 文件。以下是您可能会看到的错误消息示例：
    
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
  • vsphere-metrics-exporter 日志
    • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
    其中，ADMIN_CLUSTER_KUBECONFIG 是管理员集群的 kubeconfig 文件。以下是您可能会看到的错误消息示例：
    
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

临时解决方法：

配置 1.12.1-1.12.3、1.13.0-1.13.2

gkectl check-config 在操作系统映像验证时失败

一个可能会在不运行 gkectl prepare 的情况下使 gkectl check-config 失败的已知问题。这会造成混淆，因为我们建议在运行 gkectl prepare 之前运行该命令。

症状是 gkectl check-config 命令将失败，并显示以下错误消息：


Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

临时解决方法：

方法 1：运行 gkectl prepare 以上传缺少的操作系统映像。

方法 2：使用 gkectl check-config --skip-validation-os-images 跳过操作系统映像验证。
升级和更新 1.11、1.12、1.13

gkectl update admin/cluster 在更新反亲和性组时失败

一个可能会在更新 anti affinity groups 时使 gkectl update admin/cluster 失败的已知问题。

症状是 gkectl update 命令将失败，并显示以下错误消息：


Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

临时解决方法：
安装、升级和更新 1.13.0

配置的主机名包含英文句点时节点注册失败

在集群创建、升级、更新和节点自动修复期间，如果 ipMode.type 为 static 且 IP 地址块文件中配置的主机名包含一个或多个英文句点，则节点注册会失败。在这种情况下，节点的证书签名请求 (CSR) 不会自动获得批准。

如需查看节点的待处理 CSR，请运行以下命令：


kubectl get csr -A -o wide

查看以下日志以获取错误消息：

  • 在管理员集群中查看 clusterapi-controllers Pod 中 clusterapi-controller-manager 容器的日志：
    
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • 如需在用户集群中查看相同的日志，请运行以下命令：
    
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    其中：
    • ADMIN_CLUSTER_KUBECONFIG 是管理员集群的 kubeconfig 文件。
    • USER_CLUSTER_NAME 是用户集群的名称。
    以下是您可能会看到的错误消息示例："msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
  • 查看有问题的节点上的 kubelet 日志：
    
journalctl --u kubelet
    以下是您可能会看到的错误消息示例："Error getting node" err="node \"node-worker-vm-1\" not found"

如果您在 IP 地址块文件的主机名字段中指定域名，则第一个英文句点后面的任何字符都将被忽略。例如，如果您将主机名指定为 bob-vm-1.bank.plc，则虚拟机主机名和节点名称将设置为 bob-vm-1。

启用节点 ID 验证后，CSR 审批人会将节点名称与机器规范中的主机名进行比较，并且无法协调名称。审批人拒绝 CSR，节点引导失败。


临时解决方法：

用户集群

通过完成以下步骤停用节点 ID 验证：

  1. 在用户集群配置文件中添加以下字段：
    
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
  2. 保存文件，然后运行以下命令来更新用户集群：
    
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
    请替换以下内容：
    • ADMIN_CLUSTER_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
    • USER_CLUSTER_CONFIG_FILE：用户集群配置文件的路径。

管理员集群

  1. 打开 OnPremAdminCluster 自定义资源进行修改：
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
  2. 将以下注解添加到自定义资源：
    
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
  3. 修改管理员集群控制平面中的 kube-controller-manager 清单：
    1. 通过 SSH 连接到管理员集群控制平面节点。
    2. 打开 kube-controller-manager 清单进行修改：
      
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
    3. 找到 controllers 的列表：
      
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
    4. 按如下所示更新此部分：
      
--controllers=*,bootstrapsigner,tokencleaner
  4. 打开 Deployment Cluster API 控制器进行修改：
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
  5. 将 node-id-verification-enabled 和 node-id-verification-csr-signing-enabled 的值更改为 false：
    
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
安装、升级和更新 1.11.0-1.11.4

私有注册表证书软件包导致管理员控制平面机器启动失败

管理员集群创建/升级操作永远卡在以下日志，并最终超时：


Waiting for Machine gke-admin-master-xxxx to become ready...

外部集群快照中的 Cluster API 控制器日志包含以下日志：


Invalid value 'XXXX' specified for property startup-data

以下是 Cluster API 控制器日志的示例文件路径：


kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.

    
Workaround:

    
Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.

    
Or upgrade to a version with the fix when available.
网络 1.10、1.11.0-1.11.3、1.12.0-1.12.2、1.13.0

由于并发状态更新冲突，NetworkGatewayNodes 被标记为健康状况不佳

在 networkgatewaygroups.status.nodes 中，某些节点会在 NotHealthy 和 Up 之间切换。

在相应节点上运行的 ang-daemon Pod 的日志会显示重复的错误：


2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

NotHealthy 状态会阻止控制器为该节点分配额外的浮动 IP。这可能会导致其他节点上的负担更重，或者缺乏实现高可用性的冗余。

数据平面活动不受影响。

networkgatewaygroup 对象的争用导致某些状态更新由于重试处理故障而失败。如果过多的状态更新失败，ang-controller-manager 会将节点视为超过其检测信号时间限制，并将节点标记为 NotHealthy。

重试处理故障在更高版本中已得到修复。


临时解决方法：

升级到固定版本（如有）。
升级和更新 1.12.0-1.12.2、1.13.0

竞态条件阻止在更新或升级期间删除机器对象

一个可能会导致集群升级或更新在等待旧机器对象删除时停滞的已知问题。这是因为终结器无法从该机器对象中移除。这会影响节点池的任何滚动更新操作。

症状是 gkectl 命令超时，并显示以下错误消息：


E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

在 clusterapi-controller Pod 日志中，错误如下所示：


$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

即使没有此 bug，对于成功运行的同一台机器，错误也会重复几分钟，在大多数情况下它可以快速通过，但在极少数情况下，它可能会在这种竞态条件下卡住几个小时。

问题是 vCenter 中已经删除了底层虚拟机，但无法移除相应的机器对象，由于其他控制器的更新非常频繁，因此操作在移除终结器时卡住了。这可能会导致 gkectl 命令超时，但控制器会继续协调集群，因此升级或更新过程最终会完成。


临时解决方法：

我们为此问题准备了几种不同的缓解方法，具体取决于您的环境和要求。

  • 方法 1：等待升级最终自行完成。

    根据环境中的分析和重现，升级最终可以自行完成，无需任何人工干预。请注意，此方法无法确定每个机器对象完成终结器移除需要多长时间。如果足够幸运，移除操作可以立即完成，或者如果机器集控制器协调太快并且机器控制器永远无法在协调之间移除终结器，该操作可能会持续几个小时。

    此方法的优点是，您不需要执行任何操作，而且工作负载不会中断。它只需要较长时间来完成升级而已。
  • 方法 2：将自动修复注解应用于所有旧机器对象。

    机器集控制器将过滤掉包含自动修复注解和删除时间戳非零的机器，并且不会继续在这些机器上发出删除调用，这有助于避免出现竞态条件。

    其缺点是机器上的 pod 会直接被删除而不是被逐出，意味着它不会遵循 PDB 配置，这可能会导致工作负载停机。

    用于获取所有机器名称的命令：
    
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
    用于为每个机器应用自动修复注解的命令： 
    
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

如果您遇到此问题，并且升级或更新在一段较长的时间后仍然无法完成，请与我们的支持团队联系以获取缓解措施。
安装、升级和更新 1.10.2、1.11、1.12、1.13

gkectl prepare 操作系统映像验证预检失败

gkectl prepare 命令失败，并显示以下内容：


- Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

gkectl prepare 的预检检查包含不正确的验证。


临时解决方法：

运行相同的命令，并附加 --skip-validation-os-images 标志。
安装 1.7、1.8、1.9、1.10、1.11、1.12、1.13

带有 https:// 或 http:// 前缀的 vCenter 网址可能会导致集群启动失败

管理员集群创建失败，并显示以下内容：


Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

该网址用作 Secret 密钥的一部分，不支持“/”或“:”。


临时解决方法：

从管理员集群或用户集群配置 yaml 的 vCenter.Address 字段中移除 https:// 或 http:// 前缀。
安装、升级和更新 1.10、1.11、1.12、1.13

gkectl prepare 在系统执行 util.CheckFileExists 时崩溃

gkectl prepare 可能会崩溃，相应的堆栈跟踪记录如下：


panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

问题是 gkectl prepare 使用错误的权限创建了专用注册表证书目录。


临时解决方法：

如需解决此问题，请在管理员工作站上运行以下命令：


sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
升级和更新 1.10、1.11、1.12、1.13

gkectl repair admin-master 和可恢复的管理员升级不能一起运行

管理员集群升级失败后，请不要运行 gkectl repair admin-master。这样做可能会导致后续管理员集群升级尝试失败，并出现管理员集群主节点开启失败或虚拟机无法访问等问题。


临时解决方法：

如果您已经遇到此失败场景，请与支持团队联系。
升级和更新 1.10、1.11

恢复管理员集群升级可能会导致缺少管理员控制平面虚拟机模板

如果在尝试恢复管理员集群升级后未重新创建管理员控制平面机器，管理员控制平面虚拟机模板会被删除。管理员控制平面虚拟机模板是管理员主节点的模板，用于通过 gkectl repair admin-master 恢复控制平面机器。


临时解决方法：

管理员控制平面虚拟机模板将在下一次管理员集群升级期间重新生成。
操作系统 1.12、1.13

cgroup v2 可能会影响工作负载

在 1.12.0 版中，系统默认会为 Container-Optimized OS (COS) 节点启用 cgroup v2（统一）。这可能会导致 COS 集群中的工作负载不稳定。


临时解决方法：

我们在 1.12.1 版中切换回 cgroup v1 (Hybrid)。如果您使用的是 COS 节点，我们建议您在 1.12.1 版发布后尽快升级到该版本。
身份 1.10、1.11、1.12、1.13

ClientConfig 自定义资源

gkectl update 会还原您对 ClientConfig 自定义资源所做的所有手动更改。


临时解决方法：

我们强烈建议您在每次手动更改后备份 ClientConfig 资源。
安装 1.10、1.11、1.12、1.13

gkectl check-config 验证失败：找不到 F5 BIG-IP 分区

验证失败，因为找不到 F5 BIG-IP 分区（即使该分区存在）。

F5 BIG-IP API 的问题可能会导致验证失败。


临时解决方法：

尝试再次运行 gkectl check-config。
安装 1.12

因 cert-manager/ca-injector 的主节点选举问题，用户集群安装失败

如果 apiserver/etcd 速度缓慢，您可能会看到由于 cert-manager-cainjector 出现崩溃循环而导致安装失败：


# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

临时解决方法：
安全、升级和更新 1.10、1.11、1.12、1.13

在升级管理员集群之前，可能需要续订证书

在开始管理员集群升级过程之前，您应确保管理员集群证书目前有效，如果这些证书无效，请进行续订。

如果您已开始升级过程，并发现证书过期错误，请与 Google 支持团队联系以获取帮助。

本指南专用于管理员集群证书续订。

临时解决方法：
VMware 1.10、1.11、1.12、1.13

针对低于 7.0U2 的版本重启或升级 vCenter

如果版本低于 7.0U2 的 vCenter 在升级之后或其他情况下重启，则 vCenter 的虚拟机信息中的网络名称将变得不正确，导致机器处于 Unavailable 状态。这最终会使节点自动修复以创建新节点。

相关的 govmomi bug。


临时解决方法：

此解决方法由 VMware 支持团队提供：

  1. 此问题已在 vCenter 7.0U2 及更高版本中得到修复。
  2. 对于较低版本，请右键点击主机，然后选择连接 > 断开连接。接下来，重新连接，这会强制更新虚拟机的端口组。
操作系统 1.10、1.11、1.12、1.13

远程主机关闭 SSH 连接

对于 Anthos Clusters on VMware 1.7.2 及更高版本，Ubuntu 操作系统映像通过 CIS L1 Server Benchmark 进行了安全强化。

为满足 CIS 规则“5.2.16 确保已配置 SSH 空闲超时间隔”，/etc/ssh/sshd_config 具有以下设置：


ClientAliveInterval 300
ClientAliveCountMax 0

这些设置的目的是在空闲 5 分钟后终止客户端会话。但是，ClientAliveCountMax 0 值会导致意外行为。在管理员工作站或集群节点上使用 SSH 会话时，即使 SSH 客户端不处于空闲状态（例如在运行耗时的命令时），SSH 连接也可能会断开，命令可能会终止并显示以下消息：


Connection to [IP] closed by remote host.
Connection to [IP] closed.

临时解决方法：

您可以执行以下任一项操作：

  • 使用 nohup 防止命令在 SSH 断开连接时终止，
    
nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
  • 更新 sshd_config 以使用非零 ClientAliveCountMax 值。CIS 规则建议使用小于 3 的值：
    
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

请确保重新连接 SSH 会话。
安装 1.10、1.11、1.12、1.13

cert-manager 安装冲突

在 1.13 版本中，monitoring-operator 会在 cert-manager 命名空间中安装 cert-manager。如果由于某些原因您需要安装自己的 cert-manager，请按照以下说明操作以避免冲突：

您只需要对每个集群应用一次这个解决方法，并且更改在集群升级后会保留。

注意：安装您自己的 cert-manager 的一个常见症状是 cert-manager 版本或映像（例如 v1.7.2）可能会还原为旧版本。这是由于 monitoring-operator 尝试协调 cert-manager 并在此过程中还原版本引起的。

临时解决方法：

避免升级期间发生冲突

  1. 卸载您的 cert-manager 版本。如果您定义了自己的资源，建议您备份这些资源。
  2. 执行升级。
  3. 按照以下说明恢复您自己的 cert-manager。

在用户集群中恢复您自己的 cert-manager

  • 将 monitoring-operator 部署调节为 0：
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
  • 将 monitoring-operator 管理的 cert-manager 部署调节为 0：
    
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
  • 重新安装您的 cert-manager 版本。 恢复自定义资源（如果有）。
  • 如果您使用的是上游默认 cert-manager 安装，或者确定 cert-manager 已安装在 cert-manager 命名空间中，则可以跳过此步骤。否则，将 metrics-ca cert-manager.io/v1 证书和 metrics-pki.cluster.local 颁发者资源从 cert-manager 复制到已安装的 cert-manager 的集群资源命名空间。
    
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

在管理员集群中恢复您自己的 cert-manager

通常，您无需在管理员集群中重新安装 cert-manager，因为管理员集群仅运行 Anthos Clusters on VMware 控制平面工作负载。在极少数情况下，您还需要在管理员集群中安装自己的 cert-manager，请按照以下说明操作以避免冲突。请注意，如果您是 Apigee 客户，并且只需要在 Apigee 中使用 cert-manager，则无需运行管理员集群命令。

  • 将 monitoring-operator 部署调节为 0。
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
  • 将 monitoring-operator 管理的 cert-manager 部署调节为 0。
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
  • 重新安装您的 cert-manager 版本。 恢复自定义资源（如果有）。
  • 如果您使用的是上游默认 cert-manager 安装，或者确定 cert-manager 已安装在 cert-manager 命名空间中，则可以跳过此步骤。否则，将 metrics-ca cert-manager.io/v1 证书和 metrics-pki.cluster.local 颁发者资源从 cert-manager 复制到已安装的 cert-manager 的集群资源命名空间。
    
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
操作系统 1.10、1.11、1.12、1.13

docker、containerd 和 runc 漏洞扫描中的误报

Anthos Clusters on VMware 附带的 Ubuntu 操作系统映像中的 Docker、containerd 和 runc 使用 Ubuntu PPA 固定到特殊版本。这可确保 Anthos Clusters on VMware 在每个版本之前限定所有容器运行时更改。

但是，Ubuntu CVE Tracker（用作各种 CVE 扫描工具的漏洞 Feed）并不知道特殊版本。因此，您将在 Docker、containerd 和 runc 漏洞扫描结果中看到误报。

例如，您可能会在 CVE 扫描结果中看到以下误报。这些 CVE 已在 Anthos Clusters on VMware 的最新补丁版本中得到修复。

如需了解任何 CVE 修复，请参阅版本说明。


临时解决方法：

Canonical 已注意到该问题，并且在 https://github.com/canonical/sec-cvescan/issues/73 对修复进行了跟踪。
升级和更新 1.10、1.11、1.12、1.13

非 HA 集群升级期间管理员集群与用户集群之间的网络连接可能短时间内不可用

如果要将非 HA 集群从 1.9 升级到 1.10，您可能会注意到针对用户集群的 kubectl exec、kubectl log 和 webhook 可能短时间内不可用。此停机时间可能长达一分钟。这是因为传入请求（kubectl exec、kubectl log 和 webhook）由用户集群的 kube-apiserver 处理。用户 kube-apiserver 是一个 Statefulset。在非 HA 集群中，Statefulset 只有一个副本。因此在升级期间，可能会出现旧的 kube-apiserver 不可用，而新的 kube-apiserver 尚未就绪的情况。


临时解决方法：

此停机仅在升级过程中发生。如果您希望缩短升级期间的停机时间，我们建议您切换回 HA 集群。
安装、升级和更新 1.10、1.11、1.12、1.13

集群创建或升级后，HA 集群诊断中的 konnectivity 就绪性检查失败

如果您要创建或升级 HA 集群，并发现集群诊断中的 konnectivity 就绪性检查失败，在大多数情况下，这不会影响 Anthos Clusters on VMware 的功能（kubectl exec、kubectl log 和 webhook）。发生这种情况的原因是，由于网络不稳定或其他问题，有时一个或两个 konnectivity 副本可能在一段时间内无法就绪。


临时解决方法：

konnectivity 会自行恢复。等待 30 分钟到 1 小时，并重新运行集群诊断。
操作系统 1.7、1.8、1.9、1.10、1.11

/etc/cron.daily/aide CPU 和内存用量激增问题

从 Anthos Clusters on VMware 1.7.2 版开始，Ubuntu 操作系统映像通过 CIS L1 Server Benchmark 进行了安全强化。

因此，安装了 cron 脚本 /etc/cron.daily/aide，以便安排 aide 检查，从而确保遵循 CIS L1 服务器规则“1.4.2 确保定期检查文件系统完整性”。

Cron 作业每天的运行时间为世界协调时间 (UTC) 上午 6:25。根据文件系统上的文件数，您可能会在该时间前后遇到由此 aide 进程引起的 CPU 和内存用量激增。


临时解决方法：

如果激增影响了您的工作负载，您可以停用每日 Cron 作业：


sudo chmod -x /etc/cron.daily/aide
网络 1.10、1.11、1.12、1.13

负载均衡器和 NSX-T 有状态分布式防火墙规则以不可预测的方式进行交互

部署 Anthos Clusters on VMware 1.9 版或更高版本时，如果部署在使用 NSX-T 有状态分布式防火墙规则的环境中具有 Seesaw 捆绑负载均衡器，则 stackdriver-operator 可能无法创建 gke-metrics-agent-conf ConfigMap 并会导致 gke-connect-agent Pod 进入崩溃循环。

潜在的问题是，有状态的 NSX-T 分布式防火墙规则通过 Seesaw 负载均衡器终止从客户端到用户集群 API 服务器的连接，因为 Seesaw 使用非对称连接流。NSX-T 分布式防火墙规则的集成问题会影响所有使用 Seesaw 的 Anthos Clusters on VMware 版本。当您自己的应用创建大小超过 32K 的大型 Kubernetes 对象时，您可能会在该应用中看到类似的连接问题。


临时解决方法：

按照相关说明停用 NSX-T 分布式防火墙规则，或者将无状态分布式防火墙规则用于 Seesaw 虚拟机。

如果您的集群使用手动负载均衡器，请按照相关说明配置负载均衡器，使其在检测到后端节点故障时重置客户端连接。如果没有此配置，Kubernetes API 服务器的客户端可能会在服务器实例发生故障时停止响应几分钟。
日志记录和监控 1.10、1.11、1.12、1.13、1.14

监控费用异常

对于 Anthos Clusters on VMware 1.10 版到最新版本，一些客户在结算页面上发现 Metrics volume 的结算费用异常高。只有在同时满足以下所有条件时，此问题才会对您产生影响：

  • 已启用应用监控功能 (enableStackdriverForApplications=true)
  • 未启用 Managed Service for Prometheus (enableGMPForApplications)
  • 应用 Pod 具有 prometheus.io/scrap=true 注解

如需确认您是否受此问题影响，请列出您的用户定义的指标。如果您看到针对不需要的指标的计费，则表示此问题适用于您。


临时解决方法

如果您受到此问题的影响，我们建议您将集群升级到 1.12 版，并切换到解决此问题的新应用监控解决方案 managed-service-for-prometheus：

  • 使用单独的标志来控制应用日志与应用指标的收集
  • 已捆绑 Google Cloud Managed Service for Prometheus

    • 如果您无法升级到 1.12 版，请按以下步骤操作：

    1. 找到具有不需要的计费 的来源 Pod 和 Service
      
kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. 从 Pod 或 Service 中移除 prometheus.io/scrap=true 注解。
    安装 1.11、1.12、1.13

    创建 vSphere 数据磁盘时安装程序失败

    如果在错误的权限级层绑定了自定义角色，Anthos Clusters on VMware 安装程序可能会失败。

    如果角色绑定不正确，使用 govc 创建 vSphere 数据磁盘会挂起并且创建的磁盘的大小为 0。如需解决此问题，您应在 vSphere vCenter 级层（根）绑定自定义角色。


    临时解决方法：

    如果您要在 DC 级层（或低于根的级层）绑定自定义角色，还需要在 vCenter 根级层将只读角色绑定到用户。

    如需详细了解角色创建，请参阅 vCenter 用户帐号权限。
    日志记录和监控 1.9.0-1.9.4、1.10.0-1.10.1

    流向 monitoring.googleapis.com 的网络流量很高

    您可能会看到流向 monitoring.googleapis.com 的网络流量很高，即使在没有用户工作负载的新集群中也是如此。

    此问题会影响 1.10.0-1.10.1 和 1.9.0-1.9.4 版。此问题已在 1.10.2 和 1.9.5 版中得到解决。


    临时解决方法：
    日志记录和监控 1.10、1.11

    gke-metrics-agent 经常出现 CrashLoopBackOff 错误

    对于 Anthos Clusters on VMware 1.10 版及更高版本，如果“stackdriver”对象中的“enableStackdriverForApplications”设置为“true”，“gke-metrics-agent”DaemonSet 会经常出现 CrashLoopBackOff 错误。


    临时解决方法：

    为了缓解此问题，请运行以下命令来停用应用指标收集。这些命令不会停用应用日志收集。

    1. 为防止后续更改还原，请缩容 stackdriver-operator：
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。
    2. 打开 gke-metrics-agent-conf ConfigMap 进行修改： 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. 在 services.pipelines 下，注释掉整个 metrics/app-metrics 部分：
      
services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. 关闭修改会话。
    5. 重启 gke-metrics-agent DaemonSet： 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    日志记录和监控 1.11、1.12、1.13

    替换信息中心内已弃用的指标

    如果 OOTB 信息中心内使用了已弃用的指标，您将看到一些空图表。如需在 Monitoring 信息中心内查找已弃用的指标，请运行以下命令：

    
gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    以下已弃用的指标应迁移到其对应的替代指标。

    已弃用替换
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    临时解决方法：

    替换已弃用的指标

    1. 删除 Google Cloud Monitoring 信息中心内的“GKE On-Prem 节点状态”。请按照相关说明重新安装“GKE On-Prem 节点状态”。
    2. 删除 Google Cloud Monitoring 信息中心内的“GKE On-Prem 节点利用率”。请按照相关说明重新安装“GKE On-Prem 节点利用率”。
    3. 删除 Google Cloud Monitoring 信息中心内的“GKE On-Prem vSphere 虚拟机健康状况”。请按照相关说明重新安装“GKE On-Prem vSphere 虚拟机健康状况”。

      4. 此弃用行为是由于 kube-state-metrics 代理从 v1.9 升级到 v2.4（Kubernetes 1.22 要求进行此升级）引起的。您可以替换自定义信息中心或提醒政策中所有已弃用的 kube-state-metrics 指标（具有 kube_ 前缀）。
    日志记录和监控 1.10、1.11、1.12、1.13

    Cloud Monitoring 中的未知指标数据

    对于 Anthos Clusters on VMware 1.10 版及更高版本，Cloud Monitoring 中集群的数据可能包含如下不相关的摘要指标条目：

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    其他可能具有不相关的摘要指标的指标类型包括

    ：
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    虽然这些摘要类型指标在指标列表中，但 gke-metrics-agent 目前不支持这些指标。
    日志记录和监控 1.10、1.11、1.12、1.13

    部分节点上缺少指标

    您可能会发现部分（但不是全部）节点上缺少以下指标：

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    临时解决方法：

    如需解决此问题，请执行以下步骤作为解决方法。对于 [1.9.5+、1.10.2+、1.11.0 版]：按照步骤 1 - 4，增加 gke-metrics-agent 的 CPU

    1. 打开 stackdriver 资源进行修改： 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. 如需将 gke-metrics-agent 的 CPU 请求从 10m 增加到 50m，将 CPU 限制从 100m 增加到 200m，请将以下 resourceAttrOverride 部分添加到 stackdriver 清单中：
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      修改后的资源应类似于以下内容： 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. 保存更改并关闭文本编辑器。
    4. 如需验证更改是否已生效，请运行以下命令： 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      如果修改生效，则该命令会查找 cpu: 50m。
    日志记录和监控 1.11.0-1.11.2、1.12.0

    管理员集群中缺少调度器和控制器管理器指标

    如果管理员集群受到此问题的影响，则表示缺少调度器和控制器管理器指标。例如，缺少以下两个指标

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    临时解决方法：

    升级到 v1.11.3+、v1.12.1+ 或 v1.13+。
    1.11.0-1.11.2、1.12.0

    用户集群中缺少调度器和控制器管理器指标

    如果用户集群受到此问题的影响，则表示缺少调度器和控制器管理器指标。例如，缺少以下两个指标：

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    临时解决方法：
    安装、升级和更新 1.10、1.11、1.12、1.13

    在创建期间未能注册管理员集群

    如果您创建的是 1.9.x 或 1.10.0 版的管理员集群，并且该管理员集群在创建期间未能使用提供的 gkeConnect 规范注册，则系统会显示以下错误。

    
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    您仍然可以使用该管理员集群，但如果您之后尝试将该管理员集群升级到 1.10.y 版，则系统会显示以下错误。

    
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    临时解决方法：
    身份 1.10、1.11、1.12、1.13

    使用 Anthos Identity Service 可能会导致 Connect Agent 以不可预测的方式重启

    如果您使用 Anthos Identity Service 功能来管理 Anthos Identity Service ClientConfig，则 Connect Agent 可能会意外重启。


    临时解决方法：

    如果您在现有集群中遇到此问题，则可以执行以下操作之一：

    • 停用 Anthos Identity Service (AIS)。如果您停用 AIS，将不会移除已部署的 AIS 二进制文件，也不会移除 AIS ClientConfig。如需停用 AIS，请运行以下命令：
      
gcloud beta container hub identity-service disable \
    --project PROJECT_NAME
      将 PROJECT_NAME 替换为集群的舰队宿主项目的名称。
    • 将集群更新为 1.9.3 版或更高版本，或者更新为 1.10.1 版或更高版本，以便升级 Connect Agent 版本。
    网络 1.10、1.11、1.12、1.13

    Cisco ACI 不适用于直接服务器返回 (DSR)

    Seesaw 在 DSR 模式下运行，默认情况下，Seesaw 由于数据平面 IP 学习无法在 Cisco ACI 中正常运行。


    临时解决方法：

    一种可能的解决方法是通过将 Seesaw IP 地址作为 L4-L7 虚拟 IP 添加到 Cisco 应用政策基础架构控制器 (APIC) 中来停用 IP 学习。

    如需配置 L4-L7 虚拟 IP 选项，请点击租户 > 应用配置文件 > 应用 EPG 或 uSeg EPG。如果无法停用 IP 学习，则会导致 Cisco API 架构中的不同位置之间出现 IP 端点波动。
    VMware 1.10、1.11、1.12、1.13

    vSphere 7.0 Update 3 问题

    VMWare 最近发现了以下 vSphere 7.0 Update 3 版本出现严重问题：

    • vSphere ESXi 7.0 Update 3（版本 18644231）
    • vSphere ESXi 7.0 Update 3a（版本 18825058）
    • vSphere ESXi 7.0 Update 3b（版本 18905247）
    • vSphere vCenter 7.0 Update 3b（版本 18901211）

    临时解决方法：

    VMWare 现已移除了这些版本。您应该将 ESXi 和 vCenter Server 升级到较新的版本。
    操作系统 1.10、1.11、1.12、1.13

    未能将 emptyDir 卷作为 exec 装载到在 COS 节点上运行的 Pod 中

    对于在使用 Container-Optimized OS (COS) 映像的节点上运行的 Pod，您无法将 emptyDir 卷装载为 exec。它会装载为 noexec，系统会显示以下错误：exec user process caused: permission denied。例如，如果您部署以下测试 Pod，则会看到此错误消息：

    
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    在测试 Pod 中，如果您运行 mount | grep test-volume，它会显示 noexec 选项：

    
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    临时解决方法：
    升级和更新 1.10、1.11、1.12、1.13

    在节点池上停用自动扩缩功能后，集群节点池副本更新不起作用

    在节点池上启用和停用自动扩缩功能后，节点池副本不会更新。


    临时解决方法：

    从相应节点池的机器部署中移除 cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size 和 cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size 注解。
    日志记录和监控 1.11、1.12、1.13

    Windows 监控信息中心显示来自 Linux 集群的数据

    从 1.11 版开始，在开箱即用的监控信息中心上，Windows Pod 状态信息中心和 Windows 节点状态信息中心还会显示来自 Linux 集群的数据。这是因为 Windows 节点和 Pod 指标也会在 Linux 集群上公开。
    日志记录和监控 1.10、1.11、1.12

    CrashLoopBackOff 常量中的 stackdriver-log-forwarder

    对于 Anthos Clusters on VMware 1.10、1.11 和 1.12 版，如果磁盘上的缓冲日志损坏，则 stackdriver-log-forwarder DaemonSet 可能会出现 CrashLoopBackOff 错误。


    临时解决方法：

    为了缓解此问题，我们需要清理节点上的缓冲日志。

    1. 为防止出现意外行为，请缩容 stackdriver-log-forwarder：
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。
    2. 部署清理 DaemonSet 以清理损坏的区块：
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. 为确保清理 DaemonSet 清理了所有区块，您可以运行以下命令。这两个命令的输出应等于集群中的节点数：
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. 删除清理 DaemonSet：
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. 恢复 stackdriver-log-forwarder：
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    安全 1.13

    NodeReady 之后 Kubelet 服务将暂时不可用

    节点在短时间内准备就绪，但 kubelet 服务器证书未准备就绪。kubectl exec 和 kubectl logs 在这几十秒内不可用。这是因为新服务器证书审批人需要一段时间才能看到节点更新后的有效 IP 地址。

    此问题仅会影响 kubelet 服务器证书，不会影响 Pod 调度。
    升级和更新 1.12

    部分管理员集群升级不会阻止之后的用户集群升级

    用户集群升级失败，并显示以下内容：

    
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    管理员集群未完全升级，状态版本仍为 1.10。用户集群升级到 1.12 不会被任何预检检查阻止，并且会因版本偏差问题而失败。


    临时解决方法：

    先将管理员集群升级到 1.11，然后将用户集群升级到 1.12。
    存储空间 1.10.0-1.10.5、1.11.0-1.11.2、1.12.0

    Datastore 错误地报告可用空间不足

    gkectl diagnose cluster 命令失败，并显示以下内容： 

    
Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    不应对现有集群节点池进行数据存储区可用空间验证，但该验证被错误地添加到 gkectl diagnose cluster 中。


    临时解决方法：

    您可以忽略错误消息或使用 --skip-validation-infra 跳过验证。
    运营、网络 1.11、1.12.0-1.12.1

    管理员集群使用 MetalLB 负载均衡器时未能添加新用户集群

    如果管理员集群设置了 MetalLB 负载均衡器配置，您可能无法添加新用户集群。

    用户集群删除过程可能会由于某种原因而停滞，从而导致 MatalLB ConfigMap 失效。无法在此状态下添加新用户集群。


    临时解决方法：

    您可以强制删除用户集群。
    安装、操作系统 1.10、1.11、1.12、1.13

    为用户集群使用 Container-Optimized OS (COS) 时失败

    如果 osImageType 为管理员集群使用 cos，并且在创建管理员集群之后和创建用户集群之前执行 gkectl check-config，则在以下情况下会失败：

    
Failed to create the test VMs: VM failed to get IP addresses on the network.

    为用户集群 check-config 创建的测试虚拟机默认使用管理员集群中的相同 osImageType，而当前测试虚拟机与 COS 不兼容。


    临时解决方法：

    为避免创建测试虚拟机的预检检查速度缓慢，请使用 gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast。
    日志记录和监控 1.12.0-1.12.1

    管理员集群中的 Grafana 无法访问用户集群

    此问题会影响使用管理员集群中的 Grafana 监控 Anthos Clusters on VMware 1.12.0 和 1.12.1 版中的用户集群的客户。此问题的原因是用户集群中的 pushprox-client 证书与管理员集群中的 pushprox-server 的许可名单不匹配。症状是用户集群中的 pushprox-client 输出如下所示的错误日志：

    
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    临时解决方法：
    其他 1.11.3

    gkectl repair admin-master 未提供用于恢复的虚拟机模板

    gkectl repair admin-master 命令失败，并显示以下内容： 

    
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    如果管理员控制平面虚拟机的名称以 t、m、p 或 l 字符结尾，则 gkectl repair admin-master 无法提取用于修复管理员控制平面虚拟机的虚拟机模板。


    临时解决方法：

    使用 --skip-validation 重新运行该命令。
    日志记录和监控 1.11

    由于权限遭拒，Cloud Audit Logging 失败

    Anthos Cloud Audit Logging 需要特殊权限设置，目前仅会通过 GKE Hub 为用户集群自动执行。建议至少有一个用户集群将相同的项目 ID 和服务帐号用于管理员集群来处理云审核日志记录，这样管理员集群将拥有云审核日志记录所需的正确权限。

    但是，如果管理员集群将不同的项目 ID 或不同的服务帐号用于任何用户集群，则来自管理员集群的审核日志将无法注入云。症状是管理员集群的 audit-proxy pod 中出现一系列 Permission Denied 错误。


    临时解决方法：

    s
    运营、安全 1.11

    gkectl diagnose 检查证书失败

    如果您的工作站无权访问用户集群工作器节点，则在运行 gkectl diagnose 时会发生以下失败：

    
Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    如果您的工作站无权访问管理员集群工作器节点或管理员集群工作器节点，则在运行 gkectl diagnose 时会发生以下失败：

    
Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    临时解决方法：

    可以放心地忽略这些消息。
    操作系统 1.8、1.9、1.10、1.11、1.12、1.13

    /var/log/audit/ 填满管理员工作站上的磁盘空间

    /var/log/audit/ 会填充审核日志。您可以通过运行 sudo du -h -d 1 /var/log/audit 来检查磁盘用量。

    管理员工作站上的某些 gkectl 命令（例如 gkectl diagnose snapshot）计入磁盘空间用量。

    从 Anthos v1.8 开始，Ubuntu 映像通过 CIS Level 2 Benchmark 进行了安全强化。并且，其中一个合规性规则“4.1.2.2 确保不会自动删除审核日志”可确保 auditd 设置 max_log_file_action = keep_logs。这会使所有审核规则保留在磁盘上。


    临时解决方法：
    网络 1.10、1.11.0-1.11.3、1.12.0-1.12.2、1.13.0

    NetworkGatewayGroup 浮动 IP 与节点地址冲突

    由于存在以下验证 webhook 错误，用户无法创建或更新 NetworkGatewayGroup 对象：

    
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    在受影响的版本中，kubelet 可能会错误地绑定到分配给节点的浮动 IP 地址，并将其报告为 node.status.addresses 中的节点地址。验证 webhook 会针对集群中的所有 node.status.addresses 检查 NetworkGatewayGroup 浮动 IP 地址，并将其视为冲突。


    临时解决方法：

    在创建或更新 NetworkGatewayGroup 对象失败的集群中，暂时停用 ANG 验证 webhook 并提交更改：

    1. 保存 webhook 配置，以便在结束时恢复：
      
kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. 修改 webhook 配置。
      
kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. 从 webhook 配置列表中移除 vnetworkgatewaygroup.kb.io 项，然后关闭以应用更改。
    4. 创建或修改 NetworkGatewayGroup 对象。
    5. 重新应用原始 webhook 配置。
      
kubectl -n kube-system apply -f webhook-config.yaml
    安装、升级和更新 1.10.0-1.10.2

    创建或升级管理员集群超时

    在尝试管理员集群升级过程中，管理员控制平面虚拟机可能会在创建期间停滞。管理员控制平面虚拟机在启动期间进入无限等待循环，您会在 /var/log/cloud-init-output.log 文件中看到以下无限循环错误：

    
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    这是因为 Anthos Clusters on VMware 尝试在启动脚本中获取节点 IP 地址时，它使用 grep -v ADMIN_CONTROL_PLANE_VIP 跳过也可以分配给 NIC 的管理员集群控制平面 VIP。但是，该命令也会跳过任何具有控制平面 VIP 前缀的 IP 地址，这会导致启动脚本挂起。

    例如，假设管理员集群控制平面 VIP 为 192.168.1.25。如果管理员集群控制平面虚拟机的 IP 地址具有相同的前缀（例如 192.168.1.254），则该控制平面虚拟机会在创建期间停滞。如果广播地址与控制平面 VIP 具有相同的前缀（例如 192.168.1.255），也可能会触发此问题。


    临时解决方法：

    • 如果管理员集群创建超时的原因在于广播 IP 地址，请在管理员集群控制平面虚拟机上运行以下命令：
      
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      这将创建不包含广播地址的一行，并取消阻止启动过程。取消阻止启动脚本后，通过运行以下命令移除添加的这一行：
      
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • 但是，如果管理员集群创建超时的原因在于控制平面虚拟机的 IP 地址，则您无法取消阻止启动脚本。切换到其他 IP 地址，然后重新创建或升级到 1.10.3 版或更高版本。
    操作系统、升级和更新 1.10.0-1.10.2

    使用 COS 映像的管理员集群的状态在管理员集群升级或管理员主节点修复时会丢失

    使用 COS 映像时，数据磁盘无法正确装载到管理员集群主节点，并且使用 COS 映像的管理员集群的状态在管理员集群升级或管理员主节点修复时会丢失。（使用 COS 映像的管理员集群是一项预览版功能）


    临时解决方法：

    重新创建管理员集群（将 osImageType 设置为 ubuntu_containerd）

    创建管理员集群并将 osImageType 设置为 cos 后，获取管理员集群 SSH 密钥并通过 SSH 连接到管理员主节点。df -h 结果包含 /dev/sdb1 98G 209M 93G 1% /opt/data。并且 lsblk 结果包含 -sdb1 8:17 0 100G 0 part /opt/data
    操作系统 1.10

    systemd-resolved 无法在 .local 网域中进行 DNS 查找

    在 Anthos Clusters on VMware 1.10.0 版中，Ubuntu 上的名称解析默认会路由到 127.0.0.53 上侦听的本地 systemd-resolved。这是因为对于在 1.10.0 版中使用的 Ubuntu 20.04 映像，/etc/resolv.conf 通过 sym 链接到 /run/systemd/resolve/stub-resolv.conf，它指向 127.0.0.53 localhost DNS 存根。

    因此，localhost DNS 名称解析会拒绝检查上游 DNS 服务器（在 /run/systemd/resolve/resolv.conf 中指定）是否存在具有 .local 后缀的名称，除非这些名称被指定为搜索网域。

    这样便会导致对 .local 名称的所有查找均失败。例如，在节点启动期间，kubelet 在从具有 .local 后缀的私有注册表中拉取映像时会失败。这是因为指定具有 .local 后缀的 vCenter 地址对管理员工作站不起作用。


    临时解决方法：

    如果您在管理员集群配置文件以及用户集群配置文件中指定 searchDomainsForDNS 字段来包含相应网域，则可以避免集群节点出现此问题。

    目前 gkectl update 尚不支持更新 searchDomainsForDNS 字段。

    因此，如果您未在创建集群之前设置此字段，则必须通过 SSH 连接到节点，并通过将 /etc/resolv.conf 的 symlink 从 /run/systemd/resolve/stub-resolv.conf（包含 127.0.0.53 本地存根）更改为 /run/systemd/resolve/resolv.conf（指向实际的上游 DNS）来绕过本地 systemd-resolved 存根：

    
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    对于管理员工作站，gkeadm 不支持指定搜索网域，因此必须通过这一手动步骤解决此问题。

    此解决方案在重新创建虚拟机后不会保留。每当重新创建虚拟机时，您都必须重新应用此解决方法。
    安装、操作系统 1.10

    Docker 网桥 IP 使用 172.17.0.1/16 而不是 169.254.123.1/24

    Anthos Clusters on VMware 会为使用 --bip=169.254.123.1/24 的 Docker 网桥 IP 地址指定专用子网，这样它就不会预留默认的 172.17.0.1/16 子网。但是，在 1.10.0 版中，Ubuntu 操作系统映像中存在一个 bug，导致自定义 Docker 配置被忽略。

    因此，Docker 选择默认的 172.17.0.1/16 作为其网桥 IP 地址子网。如果您已在该 IP 地址范围内运行工作负载，则可能会导致 IP 地址冲突。


    临时解决方法：

    如需解决此问题，您必须重命名 dockerd 的以下 systemd 配置文件，然后重启服务：

    
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    验证 Docker 选择正确的网桥 IP 地址：

    
ip a | grep docker0

    此解决方案在重新创建虚拟机后不会保留。每当重新创建虚拟机时，您都必须重新应用此解决方法。
    升级和更新 1.11

    升级到 1.11 版被 Stackdriver 就绪阻止

    在 Anthos Clusters on VMware 1.11.0 版中，与日志记录和监控相关的自定义资源定义发生了变化：

    • stackdriver 自定义资源的组名称从 addons.sigs.k8s.io 更改为 addons.gke.io；
    • monitoring 和 metricsserver 自定义资源的组名称从 addons.k8s.io 更改为 addons.gke.io；
    • 上述资源的规范开始根据其架构进行评估。具体而言，stackdriver 自定义资源中的 resourceAttrOverride 和 storageSizeOverride 规范需要在 cpu、内存和存储空间大小请求和限制的值中提供字符串类型。

    更改组名称是为了符合 Kubernetes 1.22 中的 CustomResourceDefinition 更新。

    如果您没有应用或修改受影响的自定义资源的其他逻辑，则无需执行任何操作。Anthos Clusters on VMware 升级过程将负责迁移受影响的资源，并在组名称更改后保留其现有规范。

    但是，如果您运行任何应用或修改受影响资源的逻辑，则需要特别注意。首先，您需要使用清单文件中的新组名称来引用它们。例如：

    
apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    其次，请确保 resourceAttrOverride 和 storageSizeOverride 规范值均为字符串类型。例如：

    
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

    否则，应用和修改将不会生效，并且可能导致日志记录和监控组件出现意外状态。可能的症状包括：

    • onprem-user-cluster-controller 中的协调错误日志，例如：
      
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • kubectl edit stackdriver stackdriver 失败，例如：
      
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    如果您遇到上述错误，则表示在升级之前，Stackdriver CR 规范下就已存在不受支持的类型。如需解决此问题，您可以在旧的组名称 kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver 下手动修改 Stackdriver CR，并执行以下操作：

    1. 将资源请求和限制更改为字符串类型；
    2. 移除任何 addons.gke.io/migrated-and-deprecated: true 注解（如果存在）。
    然后恢复或重启升级过程。

    如果您需要其他帮助，请与 Google 支持团队联系。