Anthos clusters on VMware 已知问题

本页面列出了 Anthos Clusters on VMware 的所有已知问题。如需按产品版本或类别过滤已知问题，请从以下下拉菜单中选择所需的过滤条件。

选择 Anthos Clusters on VMware 版本：

选择问题类别：

或者，搜索您的问题：

类别 已识别的版本 问题和临时解决方法
网络、操作 1.10、1.11、1.12、1.13、1.14

Anthos Network Gateway 组件由于缺少优先级类而被逐出或待处理

kube-system 中的网络网关 Pod 可能会显示 Pending 或 Evicted 状态，如以下精简示例输出所示：

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

这些错误表示逐出事件或由于节点资源而无法调度 Pod。由于 Anthos Network Gateway Pod 没有 PriorityClass，因此它们具有与其他工作负载相同的默认优先级。 当节点资源受限时，网络网关 Pod 可能会被逐出。此行为对于 ang-node DaemonSet 尤为糟糕，因为这些 Pod 必须在特定节点上调度，并且不能迁移。


临时解决方法：

升级到 1.15 或更高版本。

作为短期修复，您可以手动为 Anthos Network Gateway 组件分配 PriorityClass。Anthos Clusters on VMware 控制器会在协调过程中（例如在集群升级期间）覆盖这些手动更改。

  • 将 system-cluster-critical PriorityClass 分配给 ang-controller-manager 和 autoscaler 集群控制器 Deployment。
  • 将 system-node-critical PriorityClass 分配给 ang-daemon 节点 DaemonSet。
升级和更新 1.12、1.13、1.14、1.15.0-1.15.2

使用 gcloud 注册管理员集群后集群升级失败

使用 gcloud 向非空 gkeConnect 部分注册管理员集群后，您可能会在尝试升级集群时看到以下错误：

failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

删除 gke-connect 命名空间： 

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
 获取管理员集群名称： 
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
 删除舰队成员资格： 
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
 并恢复管理员集群升级。
操作 1.13.0-1.13.8、1.14.0-1.14.5、1.15.0-1.15.1

gkectl diagnose snapshot --log-since 无法限制在集群节点上运行的 journalctl 命令的时间窗口

这不会影响截取集群快照的功能，因为快照仍然包含通过在集群节点上运行 journalctl 默认收集的所有日志。因此，不会错过任何调试信息。
安装、升级和更新 1.9+、1.10+、1.11+、1.12+

gkectl prepare windows 失败

gkectl prepare windows 无法在 1.13 版之前的 Anthos Clusters on VMware 上安装 Docker，因为 MicrosoftDockerProvider 已被弃用。


临时解决方法：

解决此问题的一般方法是升级到 Anthos Clusters on VMware 1.13，并使用 1.13 gkectl 创建 Windows 虚拟机模板，然后创建 Windows 节点池。从当前版本升级到 Anthos Clusters on VMware 1.13 有两种方案，如下所示。

注意：我们也提供无需升级到 1.13 并在当前版本中解决此问题的方案，但它需要更多手动步骤。如果您想要考虑此方案，请与我们的支持团队联系。


方案 1：蓝/绿升级

您可以使用 Anthos Clusters on VMware 1.13+ 版本创建具有 Windows 节点池的新集群，并将工作负载迁移到新集群，然后删除当前集群。建议使用最新的 Anthos 次要版本。

注意：这需要额外的资源来预配新集群，但现有工作负载的停机时间和中断时间会减少。


方案 2：删除 Windows 节点池，并在升级到 Anthos Clusters on VMware 1.13 时重新添加回来

注意：对于此方案，在集群升级到 1.13 以及重新添加回 Windows 节点池之前，Windows 工作负载将无法运行。

  1. 通过从 user-cluster.yaml 文件中移除 Windows 节点池配置来删除现有的 Windows 节点池，然后运行以下命令： 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. 根据相应目标次要版本的升级用户指南，将仅使用 Linux 的管理员集群和用户集群升级到 1.12。
  3. （在升级到 1.13 之前，请务必执行此步骤）确保已在 OnPremUserCluster CR 中配置 enableWindowsDataplaneV2: true，否则集群将继续为 Windows 节点池使用 Docker，这将与新创建的未安装 Docker 的 1.13 Windows 虚拟机模板不兼容。如果未配置或设置为 false，请更新您的集群以在 user-cluster.yaml 中将其设置为 true，然后运行以下命令： 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. 根据升级用户指南将仅使用 Linux 的管理员集群和用户集群升级到 1.13。
  5. 使用 1.13 gkectl 准备 Windows 虚拟机模板： 
    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. 将 Windows 节点池配置添加回 user-cluster.yaml，并将 OSImage 字段设置为新创建的 Windows 虚拟机模板。
  7. 更新集群以添加 Windows 节点池 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
安装、升级和更新 1.13.0-1.13.9、1.14.0-1.14.5、1.15.0-1.15.1

RootDistanceMaxSec 配置未对 ubuntu 节点生效

节点上将使用 RootDistanceMaxSec 的默认值 5 秒，而不是预期配置 20 秒。如果您通过 SSH 连接到虚拟机以检查节点启动日志（位于“/var/log/startup.log”），可能会看到以下错误：

+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

使用 5 秒 RootDistanceMaxSec 可能会导致系统时钟在时钟偏移大于 5 秒时与 NTP 服务器不同步。


临时解决方法：

通过 SSH 连接到节点并配置 RootDistanceMaxSec：

mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
升级和更新 1.12.0-1.12.6、1.13.0-1.13.6、1.14.0-1.14.2

空 osImageType 字段导致 gkectl update admin 失败

使用 1.13 版 gkectl 更新 1.12 版管理员集群时，您可能会看到以下错误：

Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

将 gkectl update admin 用于 1.13 版或 1.14 版集群时，您可能会在响应中看到以下消息：

Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

如果您检查 gkectl 日志，可能会发现多次更改包括将 osImageType 从空字符串设置为 ubuntu_containerd。

这些更新错误是由于管理员集群配置中 osImageType 字段的错误回填导致的，该字段在 1.9 版中引入。


临时解决方法：

升级到包含修复的 Anthos Clusters on VMware 版本。如果升级不可行，请与 Cloud Customer Care 联系以解决此问题。
安装、安全 1.13、1.14、1.15

SNI 在启用 Controlplane V2 的用户集群上不起作用

在启用 Controlplane V2 的情况下 (enableControlplaneV2: true)，通过 authentication.sni 为用户集群的 Kubernetes API 服务器提供额外的服务证书将不起作用。


临时解决方法：

在包含修复的 Anthos Clusters on VMware 补丁可用之前，如果您需要使用 SNI，请停用 Controlplane V2 (enableControlplaneV2: false)。
安装 1.0-1.11、1.12、1.13.0-1.13.9、1.14.0-1.14.5、1.15.0-1.15.1

私有注册表用户名中的 $ 导致管理员控制平面机器启动失败

当私有注册表用户名包含 $ 时，管理员控制平面机器无法启动。在检查管理员控制平面机器上的 /var/log/startup.log 时，您会看到以下错误：

++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

临时解决方法：

使用不含 $ 的私有注册表用户名，或者使用包含修复的 Anthos Clusters on VMware 版本。
升级和更新 1.12.0-1.12.4

管理员集群更新期间有关不受支持的更改的误报警告

更新管理员集群时，您会在日志中看到以下误报警告，您可以忽略它们。

    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }
升级和更新 1.13.0-1.13.9、1.14.0-1.14.5、1.15.0-1.15.1

KSA 签名密钥轮替后用户集群更新失败

如果您在轮替 KSA 签名密钥之后更新用户集群，gkectl update 可能会失败并显示以下错误消息： 

Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


临时解决方法：

将 KSA 签名密钥版本更改回 1，但保留最新的密钥数据：
  1. 查看管理员集群中 USER_CLUSTER_NAME 命名空间下的密钥，并获取 ksa-signing-key 密钥的名称： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. 复制 ksa-signing-key 密钥，并将复制的密钥命名为 service-account-cert： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. 删除之前的 ksa-signing-key 密钥： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. 将 ksa-signing-key-rotation-stage configmap 中的 data.data 字段更新为 '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}'： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. 停用验证 webhook 以修改 OnPremUserCluster 自定义资源中的版本信息： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. 将 OnPremUserCluster 自定义资源中的 spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation 字段更新为 1： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. 等待目标用户集群准备就绪，您可通过以下命令查看状态： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. 恢复用户集群的验证 webhook： 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. 在集群升级到包含修复的版本之前，避免再次进行 KSA 签名密钥轮替。
操作 1.13.1+、1.14、1.15

Terraform 删除用户集群后 F5 BIG-IP 虚拟服务器不会被清理

当您使用 Terraform 删除具有 F5 BIG-IP 负载均衡器的用户集群后，F5 BIG-IP 虚拟服务器在集群删除后不会移除。


临时解决方法：

如需移除 F5 资源，请按照清理用户集群 F5 分区的步骤操作
安装、升级和更新 1.13.8、1.14.4

kind 集群从 docker.io 拉取容器映像

如果您创建 1.13.8 版或 1.14.4 版的管理员集群，或者将管理员集群升级到 1.13.8 版或 1.14.4 版，kind 集群会从 docker.io 拉取以下容器映像：

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • 如果无法从管理员工作站访问 docker.io，则管理员集群创建或升级无法启动 kind 集群。在管理员工作站上运行以下命令会显示相应容器正在等待并具有 ErrImagePull：

    docker exec gkectl-control-plane kubectl get pods -A

    响应包含如下条目：

    ...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

    这些容器映像应预加载到 kind 集群容器映像中。但是，kind v0.18.0 存在预加载的容器映像问题，这会导致错误地从互联网拉取这些映像。


    临时解决方法：

    在管理员集群等待创建或升级时，在管理员工作站上运行以下命令：

    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    操作 1.13.0-1.13.7、1.14.0-1.14.4、1.15.0

    当网络过滤掉重复的 GARP 请求时，高可用性 Controlplane V2 用户集群和管理员集群的故障切换失败

    如果您的集群虚拟机连接了一个用于过滤掉重复 GARP（不必要的 ARP）请求的交换机，keepalived 主节点选举可能会遇到竞态条件，导致某些节点具有错误的 ARP 表条目。

    受影响的节点可以 ping 控制平面 VIP，但与控制平面 VIP 的 TCP 连接将超时。


    临时解决方法：

    在受影响集群的每个控制平面节点上运行以下命令： 
        iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    升级和更新 1.13.0-1.13.7、1.14.0-1.14.4、1.15.0

    vsphere-csi-controller 需要在 vCenter 证书轮替后重启

    vsphere-csi-controller 应在 vCenter 证书轮替后刷新其 vCenter 密钥。但是，当前系统未正确重启 vsphere-csi-controller 的 Pod，导致 vsphere-csi-controller 在轮替后崩溃。

    临时解决方法：

    对于在 1.13 及更高版本中创建的集群，请按照以下说明重启 vsphere-csi-controller 

    
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    安装 1.10.3-1.10.7、1.11、1.12、1.13.0-1.13.1

    管理员集群创建不会因集群注册错误而失败

    即使在创建管理员集群期间集群注册失败，命令 gkectl create admin 也不会因此失败，并且可能会成功。换句话说，管理员集群创建可能在未注册到舰队的情况下“成功”。

    如需识别此症状，您可以在“gkectl create admin”的日志中查找以下错误消息。 
    
Failed to register admin cluster

    您还可以在 Cloud 控制台的已注册集群中尝试查找该集群。

    临时解决方法：

    对于在 1.12 及更高版本中创建的集群，请在创建集群后按照重试管理员集群注册中的说明操作。对于在更低版本中创建的集群，

    1. 将诸如“foo: bar”的虚构键值对附加到连接和注册 SA 密钥文件
    2. 运行 gkectl update admin 以重新注册管理员集群。

    升级和更新 1.10、1.11、1.12、1.13.0-1.13.1

    管理员集群升级期间可能跳过管理员集群重新注册

    在管理员集群升级期间，如果升级用户控制平面节点超时，管理员集群将不会向更新后的连接代理版本重新注册。


    临时解决方法：

    检查集群是否显示在已注册集群中。作为可选步骤，在设置身份验证后登录集群。如果集群仍为已注册状态，您可以跳过以下关于重新尝试注册的说明。对于升级到 1.12 及更高版本的集群，请在创建集群后按照重试管理员集群注册中的说明操作。对于升级到更低版本的集群，
    1. 将诸如“foo: bar”的虚构键值对附加到连接和注册 SA 密钥文件
    2. 运行 gkectl update admin 以重新注册管理员集群。

    配置 1.15.0

    关于 vCenter.dataDisk 的误报错误消息

    对于高可用性管理员集群，gkectl prepare 会显示以下误报的错误消息：

    
vCenter.dataDisk must be present in the AdminCluster spec

    临时解决方法：

    您可以放心地忽略此错误消息。
    VMware 1.15.0

    冗余的虚拟机宿主机亲和性规则导致节点池创建失败

    在创建使用虚拟机宿主机亲和性的节点池时，竞态条件可能导致创建多条具有相同名称的虚拟机宿主机亲和性规则。这可能会导致节点池创建失败。


    临时解决方法：

    移除旧的冗余规则，以使节点池创建能够继续进行。这些规则命名为 [USER_CLUSTER_NAME]-[HASH]。
    操作 1.15.0

    gkectl repair admin-master 可能会因 failed to delete the admin master node object and reboot the admin master VM 而失败

    gkectl repair admin-master 命令可能会由于竞态条件而失败，并显示以下错误。 

    Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    临时解决方法：

    此命令具有幂等性。它可以安全地重新运行，直到命令成功为止。
    升级和更新 1.15.0

    重新创建或更新控制平面节点后 Pod 保持“Failed”状态

    重新创建或更新控制平面节点后，由于 NodeAffinity 谓词失败，某些 Pod 可能会保持 Failed 状态。这些失败的 Pod 不会影响正常的集群操作或健康状况。


    临时解决方法：

    您可以放心地忽略失败的 Pod 或手动删除它们。
    安全、配置 1.15

    私有注册表凭据导致 OnPremUserCluster 无法变为就绪状态

    如果您使用准备好的凭据和私有注册表，但尚未为私有注册表配置准备好的凭据，OnPremUserCluster 可能无法变为就绪状态，并且您可能会看到以下错误消息： 

    
failed to check secret reference for private registry …


    临时解决方法：

    根据配置准备好的凭据中的说明，为用户集群准备私有注册表凭据。

    升级和更新 1.15.0

    gkectl upgrade admin 失败并显示 StorageClass standard sets the parameter diskformat which is invalid for CSI Migration

    在 gkectl upgrade admin 期间，CSI 迁移的存储预检检查会验证 StorageClass 没有在 CSI 迁移后被忽略的参数。例如，如果某个 StorageClass 具有参数 diskformat，则 gkectl upgrade admin 会标记该 StorageClass 并在预检验证中报告失败。在 Anthos 1.10 及更低版本中创建的管理员集群具有使用 diskformat: thin 的 StorageClass，这会导致此验证失败，但此 StorageClass 在 CSI 迁移后仍然可以正常工作。这些故障应被解读为警告。

    如需了解详情，请参阅将树内 vSphere 卷迁移到 vSphere 容器存储插件中的 StorageClass 参数部分。


    临时解决方法：

    确认集群的 StorageClass 具有在 CSI 迁移后被忽略的参数后，运行带有 --skip-validation-cluster-health 标志的 gkectl upgrade admin。
    存储空间 1.15

    使用 Windows 文件系统的迁移后树内 vSphere 卷无法与 vSphere CSI 驱动程序搭配使用

    在某些情况下，磁盘可以作为只读磁盘挂接到 Windows 节点。这会导致相应的卷在 Pod 中成为只读卷。当一组新节点替换旧节点时（例如集群升级或节点池更新），较有可能发生此问题。之前正常运行的有状态工作负载在新的一组节点上可能无法写入其卷。


    临时解决方法：

    1. 获取无法写入其卷的 Pod 的 UID： 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. 使用 PersistentVolumeClaim 获取 PersistentVolume 的名称： 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. 确定运行 Pod 的节点的名称： 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. 通过 SSH 或 vSphere 网页界面获取对节点的 Powershell 访问权限。
    5. 设置环境变量： 
      
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. 确定与 PersistentVolume 关联的磁盘的磁盘编号： 
      
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. 验证磁盘为 readonly： 
      
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      结果应为 True。
    8. 将 readonly 设置为 false。 
      
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. 删除 Pod 以使其重启： 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Pod 应该被安排到同一节点上。但是，如果 Pod 被安排到新节点上，您可能需要在新节点上重复上述步骤。

    升级和更新 1.12、1.13.0-1.13.7、1.14.0-1.14.4

    gkectl update credentials vsphere --admin-cluster 后 vsphere-csi-secret 不会更新

    如果您在更新集群凭据后更新管理员集群的 vSphere 凭据，则可能会发现管理员集群中的 kube-system 命名空间下的 vsphere-csi-secret 仍然使用旧凭据。


    临时解决方法：

    1. 获取 vsphere-csi-secret 密钥名称： 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. 更新您在上一步中获得的 vsphere-csi-secret 密钥的数据： 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. 重启 vsphere-csi-controller： 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. 您可以使用以下命令跟踪发布状态： 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
       部署成功发布后，控制器应使用更新后的 vsphere-csi-secret。
    升级和更新 1.10、1.11、1.12.0-1.12.6、1.13.0-1.13.6、1.14.0-1.14.2

    使用 gkectl update cluster 启用 Cloud Audit Logs 时 audit-proxy 发生崩溃循环

    audit-proxy 可能会因空 --cluster-name 而发生崩溃循环。此行为是由更新逻辑中的一个 bug 引起的，即集群名称不会传播到审核代理 Pod/容器清单。


    临时解决方法：

    对于具有 enableControlplaneV2: true 的控制平面 v2 用户集群，使用 SSH 连接到用户控制平面机器，并使用 --cluster_name=USER_CLUSTER_NAME 更新 /etc/kubernetes/manifests/audit-proxy.yaml。

    对于控制平面 v1 用户集群，修改 kube-apiserver statefulset 中的 audit-proxy 容器以添加 --cluster_name=USER_CLUSTER_NAME：

    kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    升级和更新 1.11、1.12、1.13.0-1.13.5、1.14.0-1.14.1

    在 gkectl upgrade cluster 之后立即发生控制平面重新部署

    在 gkectl upgrade cluster 之后，控制平面 Pod 可能会立即再次重新部署。 gkectl list clusters 中的集群状态从 RUNNING 变为 RECONCILING。 对用户集群发出的请求可能会超时。

    出现这种行为的原因是在 gkectl upgrade cluster 之后自动进行控制平面证书轮替。

    只有不使用控制平面 v2 的用户集群会出现此问题。


    临时解决方法：

    等待集群状态在 gkectl list clusters 中恢复为 RUNNING，或升级到包含修复的版本：1.13.6+、1.14.2+ 或 1.15+。
    升级和更新 1.12.7

    有问题的版本 1.12.7-gke.19 已移除

    Anthos Clusters on VMware 1.12.7-gke.19 是一个有问题的版本，您不应使用它。这些工件已从 Cloud Storage 存储桶中移除。

    临时解决方法：

    请改用 1.12.7-gke.20 版本。
    升级和更新 1.12.0+、1.13.0-1.13.7、1.14.0-1.14.3

    gke-connect-agent 在仓库凭据更新后继续使用旧版映像

    如果您使用以下方法之一更新仓库凭据：

    • gkectl update credentials componentaccess（如果不使用私有仓库）
    • gkectl update credentials privateregistry（如果使用私有仓库）

    您可能会发现 gke-connect-agent 会继续使用旧版映像，或者由于 ImagePullBackOff 而无法拉取 gke-connect-agent Pod。

    此问题将在 Anthos Clusters on VMware 1.13.8、1.14.4 和后续版本中修复。


    临时解决方法：

    方法 1：手动重新部署 gke-connect-agent：

    1. 删除 gke-connect 命名空间： 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. 使用原始注册服务账号密钥重新部署 gke-connect-agent（无需更新密钥）：

      对于管理员集群： 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
       对于用户集群： 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    方法 2：您可以手动更改 gke-connect-agent 部署使用的映像拉取 Secret regcred 的数据：

    kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    方法 3：您可以通过以下方式在 gke-connect-agent 部署中添加集群的默认映像拉取 Secret：

    1. 将默认 Secret 复制到 gke-connect 命名空间： 
      kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. 获取 gke-connect-agent 部署名称： 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. 将默认 Secret 添加到 gke-connect-agent 部署： 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    安装 1.13、1.14

    手动 LB 配置检查失败

    通过运行 gkectl check-config 在使用手动负载均衡器创建集群之前验证配置时，命令将失败，并显示以下错误消息。

     - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

    临时解决方法：

    方法 1：您可以使用将包含修复的补丁版本 1.13.7 和 1.14.4。

    方法 2：您也可以运行相同命令来验证配置，但跳过负载均衡器验证。

    gkectl check-config --skip-validation-load-balancer
    操作 1.0、1.1、1.2、1.3、1.4、1.5、1.6、1.7、1.8、1.9、1.10、1.11、1.12、1.13 和 1.14

    etcd watch 耗尽

    运行 etcd 3.4.13 或更早版本的集群可能会遇到 watch 耗尽且非操作性资源进行监控，这可能会导致以下问题：

    • Pod 调度中断
    • 节点无法注册
    • kubelet 不观察 Pod 变化

    这些问题可能会导致集群无法正常运行。

    此问题在 Anthos Clusters on VMware 1.12.7、1.13.6、1.14.3 和后续版本中已得到解决。这些较新的版本使用 etcd 3.4.21 版。所有旧版 Anthos Clusters on VMware 都会受到此问题的影响。

    临时解决方法

    如果您无法立即升级，则可以通过减少集群中的节点数来降低集群故障的风险。移除节点，直到 etcd_network_client_grpc_sent_bytes_total 指标小于 300 MBps。

    如需在 Metrics Explorer 中查看此指标，请执行以下操作：

    1. 前往 Google Cloud 控制台中的 Metrics Explorer：

      转到 Metrics Explorer

    2. 选择 Configuration（配置）标签页。
    3. 展开选择一个指标，在过滤栏中输入 Kubernetes Container，然后使用子菜单选择该指标：
      1. 在活跃资源菜单中，选择 Kubernetes 容器。
      2. 在活跃指标类别菜单中，选择 Anthos。
      3. 在活跃指标菜单中，选择 etcd_network_client_grpc_sent_bytes_total。
      4. 点击“应用”。
    升级和更新 1.10、1.11、1.12、1.13 和 1.14

    Anthos Identity Service 可能导致控制平面延迟

    在集群重启或升级时，Anthos Identity Service 可能会收到超出其负载的流量，这些流量包含通过身份验证 webhook 从 kube-apiserver 转发到 Anthos Identity Service 的过期 JWT 令牌。尽管 Anthos Identity Service 不会崩溃循环，但它会变得无响应，并停止处理更多请求。 此问题最终会导致控制平面的延迟时间增加。

    此问题已在以下 Anthos Clusters on VMware 版本中得到修复：

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    要确定您是否受到此问题影响，请执行以下步骤：

    1. 检查是否可以从外部访问 Anthos Identity Service 端点： 
      curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      将 CLUSTER_ENDPOINT 替换为您的集群的控制平面 VIP 和控制平面负载均衡器端口（例如 172.16.20.50:443）。

      如果您受到此问题的影响，该命令会返回 400 状态代码。如果请求超时，请重启 ais Pod 并重新运行 curl 命令，看看是否能解决问题。如果您收到状态代码 000，则说明问题已解决，您无需再执行任何操作。如果您仍然收到 400 状态代码，则说明 Anthos Identity Service HTTP 服务器未启动。在这种情况下，请继续。

    2. 检查 Anthos Identity Service 和 kube-apiserver 日志：
      1. 检查 Anthos Identity Service 日志： 
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        如果日志包含如下所示的条目，则表示您受到此问题的影响：

        I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. 检查集群的 kube-apiserver 日志：

        在以下命令中，KUBE_APISERVER_POD 是给定集群上的 kube-apiserver Pod 的名称。

        管理员集群：

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

        用户集群：

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        如果 kube-apiserver 日志包含如下所示的条目，则表示您受到此问题的影响：

        E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

    临时解决方法

    如果您无法立即升级集群以获取修复，作为临时解决方法，您可以找到引发问题的 Pod 并将其重启：

    1. 将 Anthos Identity Service 的详细程度增加到 9： 
      kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. 检查 Anthos Identity Service 日志中是否存在无效的令牌上下文： 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. 如需获取与每个无效令牌上下文关联的令牌载荷，请使用以下命令解析每个相关的服务账号 Secret：
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. 如需解码令牌并查看来源 Pod 名称和命名空间，请将令牌复制到位于 jwt.io 的调试程序。
    5. 重启令牌中标识的 Pod。
    操作 1.8、1.9、1.10

    etcd-maintenance Pod 的内存用量增加问题

    使用 etcddefrag:gke_master_etcddefrag_20210211.00_p0 映像的 etcd-maintenance 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+、1.15+

    虚拟机在意外关停/重新启动时释放 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.12.5、1.13.0-1.13.5、1.14.0-1.14.1

    管理员集群从 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、1.14

    删除用户集群后，Cluster Autoscaler clusterrolebinding 和 clusterrole 会被删除。

    删除用户集群时，集群自动扩缩器对应的 clusterrole 和 clusterrolebinding 也会被删除。这会影响启用了集群自动扩缩器的同一管理员集群上的所有其他用户集群。这是因为同一管理员集群中的所有集群自动扩缩器 Pod 都使用相同的 clusterrole 和 clusterrolebinding。

    症状如下：

    • cluster-autoscaler 日志
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
       其中，ADMIN_CLUSTER_KUBECONFIG 是管理员集群的 kubeconfig 文件。以下是您可能会看到的错误消息示例：
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    临时解决方法：

    配置 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-1.13.8、1.14.0-1.14.4、1.15.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、1.15

    监控费用异常

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

    • 已启用应用监控功能 (enableStackdriverForApplications=true)
    • 未启用 Managed Service for Prometheus (enableGMPForApplications)
    • 应用 Pod 具有 prometheus.io/scrap=true 注解。（安装 Anthos Service Mesh 也可以添加此注释。）

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


    临时解决方法

    如果您受到此问题的影响，我们建议您将集群升级到 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 注解。 如果注解由 Anthos Service Mesh 添加，请考虑在不使用 Prometheus 选项的情况下配置 Anthos Service Mesh，或关闭 Istio 指标合并功能。
    安装 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

    临时解决方法：

    此问题在 Anthos Clusters on VMware 1.13.0 及更高版本中已得到解决。请将集群升级到包含修复的版本。
    安装、升级和更新 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.10、1.11、1.12、1.13、1.14、1.15

    stackdriver-log-forwarder 不向 Cloud Logging 发送日志

    如果您没有看到来自您的集群的 Cloud Logging 日志，并且发现日志中存在以下错误： 

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    可能的原因是日志输入速率超过了日志记录代理的限制，导致 stackdriver-log-forwarder 不发送日志。所有 Anthos Clusters on VMware 版本都会出现此问题。

    临时解决方法：

    如需缓解此问题，您需要提高日志记录代理的资源限制。

    1. 打开 stackdriver 资源进行修改： 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. 如需增加 stackdriver-log-forwarder 的 CPU 请求，请将以下 resourceAttrOverride 部分添加到 stackdriver 清单中： 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
       修改后的资源应类似于以下内容： 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. 保存更改并关闭文本编辑器。
    4. 如需验证更改是否已生效，请运行以下命令： 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
       如果修改生效，则该命令会查找 cpu: 1200m。
    安全 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、1.12、1.13、1.14、1.15

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

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

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


    临时解决方法：
    操作、安全 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 注解（如果存在）。
    然后恢复或重启升级过程。

    操作系统 1.7、1.8、1.9、1.10、1.11、1.12、1.13、1.14、1.15

    在通过非正常关停主机迁移虚拟机时，COS 虚拟机不显示 IP

    每当 ESXi 服务器发生故障并且为该服务器启用了 vCenter 高可用性功能时，故障 ESXi 服务器中的所有虚拟机都会触发 vMotion 机制，并迁移到另一个正常的 ESXi 服务器。迁移的 COS 虚拟机将丢失其 IP。

    临时解决方法：

    重新启动虚拟机
    如果您需要其他帮助，请与 Google 支持团队联系。