1.8 版。如 Anthos 版本支持政策中所述，提此版本是受支持的版本，提供影响 VMware 上的 Anthos 集群 (GKE On-Prem) 的安全漏洞、威胁和问题的最新补丁程序和更新。如需了解详情，请参阅版本说明。这不是最新版本。

可用版本： 1.11 1.10 1.9 更早版本

已知问题

本文档介绍 Anthos clusters on VMware (GKE On-Prem) 1.8 版的已知问题。

/var/log/audit/ 填充磁盘空间

类别

操作系统

已识别的版本

1.8.0+、1.9.0+、1.10.0+、1.11.0+、1.12.0+、1.13.0+

表现

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

原因

从 Anthos v1.8 开始，Ubuntu 映像已经过 CIS Level2 基准强化。其中一条合规性规则 4.1.2.2 Ensure audit logs are not automatically deleted 可确保 auditd 设置 max_log_file_action = keep_logs。这会使所有审核规则保留在磁盘上。

临时解决方法

管理员工作站

对于管理员工作站，您可以手动更改 auditd 设置以自动轮替日志，然后重启 auditd 服务：

sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

上述设置会使 auditd 在生成超过 250 个文件（每个文件大小为 8M）时自动轮替其日志。

集群节点

对于集群节点，将以下 DaemonSet 应用到您的集群，以防止出现潜在问题：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

请注意，进行此 auditd 配置更改会违反 CIS Level2 规则 4.1.2.2 Ensure audit logs are not automatically deleted。

由于“无法注册用户集群”，用户集群升级/更新失败

类别

升级、更新

已识别的版本

1.7.0+、1.8.0+

表现

如果之前的 gkectl 命令在以下情况下超时，请运行 gkectl diagnose cluster。

将启用 GKE 连接的用户集群升级到 1.8 版本。
在启用了 GKE 连接的 1.8 版用户集群上运行 gkectl update cluster。
运行 gkectl update cluster 以在 1.8 版用户集群上启用 GKE 连接。

$ gkectl diagnose cluster --kubeconfig kubeconfig --cluster-name foo-cluster
…
    Unhealthy Resources:
      OnPremUserCluster foo-cluster: not ready: ready condition is not true: ClusterCreateOrUpdate: failed to register user cluster "foo-cluster": failed to register cluster: ...
...

请注意，GKE 连接的功能不应受影响。换句话说，如果 GKE 连接在该命令之前正常运行，则现在仍应正常运行。

原因

1.8 版中使用的 Connect Agent 版本 20210514-00-00 不受支持。

临时解决方法

请与 Google 支持团队联系以缓解该问题。

systemd-timesyncd 在 Ubuntu 节点重新启动后无法运行

类别

操作系统

已识别的版本

1.7.1-1.7.5、1.8.0-1.8.4、1.9.0+

表现

systemctl status systemd-timesyncd 应显示该服务已失效：

● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)

这可能会导致同步超时问题。

原因

Ubuntu 操作系统映像上错误地安装了 chrony，并且 chrony 和 systemd-timesyncd 之间存在冲突，使得每次重新启动 Ubuntu 虚拟机时，systemd-timesyncd 都会变为非活跃状态，而 chrony 则变为活跃状态。但是，systemd-timesyncd 应该是虚拟机的默认 ntp 客户端。

临时解决方法

方法 1：每次虚拟机重新启动时手动运行 restart systemd-timesyncd。

方法 2：部署以下 DaemonSet，以便在 systemd-timesyncd 失效时始终对其进行重启。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ensure-systemd-timesyncd
spec:
  selector:
    matchLabels:
      name: ensure-systemd-timesyncd
  template:
    metadata:
      labels:
        name: ensure-systemd-timesyncd
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: ensure-systemd-timesyncd
        # Use your preferred image.
        image: ubuntu
        command:
        - /bin/bash
        - -c
        - |
          while true; do
            echo $(date -u)
            echo "Checking systemd-timesyncd status..."
            chroot /host systemctl status systemd-timesyncd
            if (( $? != 0 )) ; then
              echo "Restarting systemd-timesyncd..."
              chroot /host systemctl start systemd-timesyncd
            else
              echo "systemd-timesyncd is running."
            fi;
            sleep 60
          done
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: "10Mi"
            cpu: "10m"
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
````

## ClientConfig custom resource

`gkectl update` reverts any manual changes that you have made to the ClientConfig
custom resource. We strongly recommend that you back up the ClientConfig
resource after every manual change.

## gkectl check-config</code> validation fails: can't find F5 BIG-IP partitions

<dl>
<dt>Symptoms</dt>
<dd><p>Validation fails because F5 BIG-IP partitions can't be found, even though they exist.</p></dd>
<dt>Potential causes</dt>
<dd><p>An issue with the F5 BIG-IP API can cause validation to fail.</p></dd>
<dt>Resolution</dt>
<dd><p>Try running <code>gkectl check-config</code> again.</p></dd>
</dl>

## Disruption for workloads with PodDisruptionBudgets {:#workloads_pdbs_disruption}

Upgrading clusters can cause disruption or downtime for workloads that use
[PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/){:.external}
(PDBs).

## Nodes fail to complete their upgrade process

If you have `PodDisruptionBudget` objects configured that are unable to
allow any additional disruptions, node upgrades might fail to upgrade to the
control plane version after repeated attempts. To prevent this failure, we
recommend that you scale up the `Deployment` or `HorizontalPodAutoscaler` to
allow the node to drain while still respecting the `PodDisruptionBudget`
configuration.

To see all `PodDisruptionBudget` objects that do not allow any disruptions:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}' ```

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

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

  kubectl logs --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployments/cert-manager-cainjector

可能会产生以下日志：

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"

运行以下命令来缓解问题。

首先缩减 monitoring-operator，使其不会还原对 cert-manager-cainjector Deployment 的更改。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0

其次，修补 cert-manager-cainjector Deployment 以停用主节点选举，这是安全的，因为我们只有一个副本正在运行。不需要针对一个副本执行此操作。

# Ensure that we run only 1 cainjector replica, even during rolling updates.
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=strategic --patch '
spec:
  strategy:
    rollingUpdate:
      maxSurge: 0
'
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=json --patch '[
    {
        "op": "add",
        "path": "/spec/template/spec/containers/0/args/-",
        "value": "--leader-elect=false"
    }
]'

将 monitoring-operator 副本保持为 0 作为缓解措施，直到安装完成为止。否则将会还原更改。

安装完成且集群启动并运行后，启用 monitoring-operator 以执行投产后运维：

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=1

请注意，在升级到 1.8.4 及更高版本（或者如果升级到 1.9，则为 1.9.1 及更高版本）后，不再需要这些步骤，因为 Anthos 会停用 cajector 的主节点选举功能。在此之前，如果您在每次升级期间遇到此问题，则必须再次执行相同的缓解步骤。

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

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

管理员集群证书续订过程

在开始之前，请确保在管理员工作站上安装了 OpenSSL。
设置 KUBECONFIG 变量：
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
将 ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG 替换为管理员集群 kubeconfig 文件的绝对路径。

获取管理员主节点的 IP 地址和 SSH 密钥：

kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \
-o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key

export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \
jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
--selector='node-role.kubernetes.io/master')

检查证书是否已过期：
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
```
如果证书已过期，您必须在升级管理员集群之前续订证书。
由于在管理员证书过期时管理员集群 kubeconfig 文件也会过期，因此您应该在过期之前备份此文件。
- 备份管理员集群 kubeconfig 文件：
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 

"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
```
- 将 kubeconfig 中的 client-certificate-data 和 client-key-data 替换为您创建的 new_admin.conf 文件中的 client-certificate-data 和 client-key-data。

备份旧证书：

这是一个可选步骤，但建议您执行此步骤。

# ssh into admin master if you didn't in the previous step
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"

# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout

# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .

使用 kubeadm 续订证书：

 # ssh into admin master
 ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
 # on admin master
 sudo kubeadm alpha certs renew all

重启在管理员主节点上运行的静态 Pod：

  # on admin master
  cd /etc/kubernetes
  sudo mkdir tempdir
  sudo mv manifests/*.yaml tempdir/
  sleep 5
  echo "remove pods"
  # ensure kubelet detect those change remove those pods
  # wait until the result of this command is empty
  sudo docker ps | grep kube-apiserver

  # ensure kubelet start those pods again
  echo "start pods again"
  sudo mv tempdir/*.yaml manifests/
  sleep 30
  # ensure kubelet start those pods again
  # should show some results
  sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd

  # clean up
  sudo rm -rf tempdir

  logout

续订管理员集群工作器节点的证书

检查节点证书失效日期

    kubectl get nodes -o wide
    # find the oldest node, fill NODE_IP with the internal ip of that node
    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${NODE_IP}"
    openssl x509 -enddate -noout -in /var/lib/kubelet/pki/kubelet-client-current.pem
    logout

如果证书即将失效，请通过手动节点修复续订节点证书。

您必须验证续订的证书，并验证 kube-apiserver 的证书。

检查证书到期时间：

ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 

"sudo kubeadm alpha certs check-expiration"

检查 kube-apiserver 的证书：

# Get the IP address of kube-apiserver
cat $KUBECONFIG | grep server
# Get the current kube-apiserver certificate
openssl s_client -showcerts -connect : 

| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  

> current-kube-apiserver.crt
# check expiration date of this cert
openssl x509 -in current-kube-apiserver.crt -noout -enddate

/etc/cron.daily/aide 脚本占用 /run 中的所有空间，导致 pod 中出现崩溃循环

从 Anthos clusters on VMware 1.7.2 开始，Ubuntu 操作系统映像通过 CIS L1 Server Benchmark 进行了安全强化。因此，安装了 cron 脚本 /etc/cron.daily/aide，以便安排 AIDE 检查以确保 CIS L1 服务器规则“1.4.2 确保定期检查文件系统完整性”。

该脚本使用 /run/aide 作为临时目录来保存其 cron 日志，随着时间的推移，它可能会耗尽 /run 中的所有空间。请参阅 /etc/cron. daily/aide 脚本使用 /run 中的所有空间，查看解决方法。

如果您在节点上看到一个或多个 pod 崩溃循环，请在节点上运行 df -h /run。如果命令输出显示空间用量为 100%，那么您可能遇到了此问题。

此问题在 1.8.1 版中已得到解决。对于 1.7.2 和 1.8.0 版本，您可以使用以下两种方法之一手动解决此问题：

定期移除位于 /run/aide/cron.daily.old* 的日志文件（推荐）。
按照 /etc/cron.daily/aide 脚本用尽 /run 中的所有空间中所述步骤执行操作。（注意：此解决方法可能会影响节点合规性状态）。

升级 1.8.0 版的 Seesaw 负载均衡器

如果您尝试使用 gkectl upgrade loadbalancer 更新 1.8.0 版中的 Seesaw 负载均衡器的一些参数，此操作将在 DHCP 及 IPAM 模式下不起作用。如果您的设置包含此配置，请勿升级到 1.8.0 版，而是升级到 1.8.1 版或更高版本。

由于密码过期问题，无法登录管理员工作站

如果您使用的是以下版本的 Anthos clusters on VMware，则可能会遇到此问题。

1.7.2-gke.2
1.7.3-gke.2
1.8.0-gke.21
1.8.0-gke.24
1.8.0-gke.25
1.8.1-gke.7
1.8.2-gke.8

当您尝试通过 SSH 连接到 Anthos 虚拟机（包括管理员工作站、集群节点和 Seesaw 节点）时，可能会遇到以下错误：

WARNING: Your password has expired.

发生此错误是因为虚拟机上的 ubuntu 用户密码已过期。在登录虚拟机之前，您必须手动将用户密码的到期时间重置为较大的值。

防止密码过期错误

如果您运行的是上面列出的受影响版本，并且用户密码尚未过期，则应在看到 SSH 错误之前延长到期时间。

在每个 Anthos 虚拟机上运行以下命令：

sudo chage -M 99999 ubuntu

缓解密码过期错误

如果用户密码已过期，并且您无法登录虚拟机来延长到期时间，请对每个组件执行以下缓解步骤。

管理员工作站

使用临时虚拟机执行以下步骤。您可以使用 1.7.1-gke.4 版创建管理员工作站，以用作临时虚拟机。

确保临时虚拟机和管理员工作站处于关机状态。
将管理员工作站的启动磁盘挂接到临时虚拟机。启动磁盘带有“硬盘 1”标签。
通过运行以下命令，在虚拟机内装载启动磁盘。将 dev/sdc1 替换成您自己的启动磁盘标识符。
```
sudo mkdir -p /mnt/boot-disk
sudo mount /dev/sdc1 /mnt/boot-disk
```
将 ubuntu 用户到期日期设置为较大的值，例如 99999 天。
```
sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
```
关停临时虚拟机。
启动管理员工作站。现在，您应该可以照常通过 SSH 连接了。
在清理时，请删除临时虚拟机。

管理员集群控制层面虚拟机

按照说明重新创建管理员集群控制层面虚拟机。

管理员集群插件虚拟机

从管理员工作站运行以下命令以重新创建虚拟机：

  kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

运行此命令后，请等待管理员集群插件虚拟机完成重新创建并准备就绪，然后再继续执行后续步骤。

用户集群控制层面虚拟机

从管理员工作站运行以下命令以重新创建虚拟机：

usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

运行此命令后，请等待用户集群控制层面虚拟机完成重新创建并准备就绪，然后再继续执行后续步骤。

用户集群工作器虚拟机

从管理员工作站运行以下命令以重新创建虚拟机。

for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done

Seesaw 虚拟机

从管理员工作站运行以下命令以重新创建 Seesaw 虚拟机。会有一些停机时间。如果为负载均衡器启用了高可用性，则最长停机时间为两秒。

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff

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

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

相关的 govmmi 错误：https://github.com/vmware/govmomi/issues/2552

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

1. The issue is fixed in vCenter versions 7.0U2 and above.

2. For lower versions:
Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the
VM's portgroup.

`gkectl create-config admin` 和 `gkectl create-config cluster` panic

在 1.8.0-1.8.3 版中，gkectl create-config admin/cluster 命令会失败，并显示消息 panic: invalid version: "latest"。

如需解决此问题，请使用 gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION。将 DESIRED_CLUSTER_VERSION 替换为所需的版本，例如 1.8.2-gke.8。

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

此问题会影响 1.8.0-1.8.3。

管理员集群创建或管理员集群升级可能会超时，并显示以下错误：

Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory

此外，外部集群快照中位于 nodes/ADMIN_MASTER_NODE/files/var/log/startup.log 的日志以下列消息结尾：

[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

当管理员控制平面虚拟机和 Container Registry 之间的网络速度较慢时，会发生此错误。请务必检查您的网络或代理设置，以减少延迟时间并增加带宽。

远程主机关闭 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.8.2 或更高版本时，与 `cert-manager` 发生冲突

如果您在 Anthos clusters on VMware 上安装了自己的 cert-manager，则您在尝试升级到 1.8.2 或更高版本时可能会遇到故障。这是因您的 cert-manager 版本（可能安装在 cert-manager 命名空间中）与 monitoring-operator 版本之间发生冲突。

如果您在升级到 Anthos clusters on VMware 1.8.2 版或更高版本后尝试安装另一个 cert-manager 副本，则安装可能会因与 monitoring-operator 管理的现有副本发生冲突而失败。

metrics-ca 集群颁发者（控制平面和可观测性组件依赖其创建和轮替证书 Secret）要求将 metrics-ca 证书 Secret 存储在集群资源命名空间中。对于 monitoring-operator 安装，此命名空间为 kube-system，对于您的安装，此命名空间可能为 cert-manager。

如果安装失败，请按照以下步骤操作，以成功升级到 1.8.2 或更高版本：

避免升级期间发生冲突

卸载您的 cert-manager 版本。如果您定义了自己的资源，建议您备份这些资源。
执行升级。
请按照以下说明恢复您自己的 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 kube-system scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0

重新安装客户的 cert-manager。恢复自定义资源（如果有）。

将 metrics-ca cert-manager.io/v1 证书和 metrics-pki.cluster.local 颁发者资源从 kube-system 复制到已安装的 cert-manager 的集群资源命名空间。如果使用的是上游默认 cert-manager 安装，则已安装的 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 kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n kube-system 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 kube-system scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0

重新安装客户的 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 get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4

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 跟踪了该修复。

`/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`.

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

Seesaw 在 DSR 模式下运行，默认情况下，它在 Cisco ACI 中无法正常运行，这是由于数据层面 IP 学习导致的。一种可能的解决方法是将 Seesaw IP 地址添加为 Cisco 应用政策基础架构控制器 (APIC) 中的 L4-L7 虚拟 IP 地址，以停用 IP 学习。

如需配置 L4-L7 虚拟 IP 地址选项，请转到租户 > 应用配置文件 > 应用 EPG 或 uSeg EPG。如果无法停用 IP 学习，则 Cisco API 架构中的不同位置之间会存在 IP 端点波动。

服务帐号不记名令牌过长可能会破坏 Seesaw 负载均衡器日志

如果您的日志记录监控服务帐号不记名令牌大于 512 KB，则会破坏 Seesaw 负载均衡器日志。要解决此问题，请升级到 1.9 版或更高版本。

`anetd` 守护程序软件死锁导致 pod 之间的连接问题

由于 anetd 守护程序（作为 Daemonset 运行）进入软件死锁状态，enableDataplaneV2 设置为 true 的集群可能会遇到 pod 之间的连接问题。在此状态下，anetd 守护程序会将过时的节点（之前删除的节点）视为对等节点，并将新添加的节点误认为新的对等节点。

如果您遇到此问题，请完成以下步骤来重启 anetd 守护程序以刷新对等节点，并且连接应该恢复。

查找集群中的所有 anetd 守护程序：

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd

检查 anetd 守护程序当前是否看到过时的对等节点：

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status

将 ANETD_XYZ 替换为 anetd pod 的名称。

重启所有受影响的 pod：

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ

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

已知问题

/var/log/audit/ 填充磁盘空间

类别

已识别的版本

表现

原因

临时解决方法

管理员工作站

集群节点

由于“无法注册用户集群”，用户集群升级/更新失败

类别

已识别的版本

表现

原因

临时解决方法

systemd-timesyncd 在 Ubuntu 节点重新启动后无法运行

类别

已识别的版本

表现

原因

临时解决方法

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

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

管理员集群证书续订过程

/etc/cron.daily/aide 脚本占用 /run 中的所有空间，导致 pod 中出现崩溃循环

升级 1.8.0 版的 Seesaw 负载均衡器

由于密码过期问题，无法登录管理员工作站

防止密码过期错误

缓解密码过期错误

管理员工作站

管理员集群控制层面虚拟机

管理员集群插件虚拟机

用户集群控制层面虚拟机

用户集群工作器虚拟机

Seesaw 虚拟机

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

gkectl create-config admin 和 gkectl create-config cluster panic

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

远程主机关闭 SSH 连接

升级到 1.8.2 或更高版本时，与 cert-manager 发生冲突

避免升级期间发生冲突

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

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

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

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

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

服务帐号不记名令牌过长可能会破坏 Seesaw 负载均衡器日志

anetd 守护程序软件死锁导致 pod 之间的连接问题

gkectl diagnose 检查证书失败

`gkectl create-config admin` 和 `gkectl create-config cluster` panic

升级到 1.8.2 或更高版本时，与 `cert-manager` 发生冲突

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

`anetd` 守护程序软件死锁导致 pod 之间的连接问题