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

可用版本

已知问题

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

由于“无法注册到 GCP”，用户集群升级失败

类别

升级

已识别的版本

1.7.0+、1.8.0+

表现

将用户集群升级到 1.7 版本时，命令 gkectl upgrade cluster 失败并显示类似如下的错误消息：

$ gkectl upgrade cluster --kubeconfig kubeconfig --config user-cluster.yaml
…
Upgrading to bundle version: "1.7.1-gke.4"
…
Exit with error:

failed to register to GCP, gcloud output: , error: error running command 'gcloud alpha container hub memberships register foo-cluster --kubeconfig kubeconfig --context cluster --version 20210129-01-00  --enable-workload-identity --has-private-issuer --verbosity=error --quiet': error: exit status 1, stderr: 'Waiting for membership to be created...

这些错误表明用户集群升级已基本完成，但 Connect Agent 尚未升级。但是，GKE 连接的功能不应受影响。

原因

1.7 版中使用的 Connect Agent 版本 20210129-01-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.

## `kubectl describe CSINode` and `gkectl diagnose snapshot`

`kubectl describe CSINode` and `gkectl diagnose snapshot` sometimes fail due to
the
[OSS Kubernetes issue](https://github.com/kubernetes/kubectl/issues/848){:.external}
on dereferencing nil pointer fields.

## OIDC and the CA certificate

The OIDC provider doesn't use the common CA by default. You must explicitly
supply the CA certificate.

Upgrading the admin cluster from 1.5 to 1.6.0 breaks 1.5 user clusters that use
an OIDC provider and have no value for `authentication.oidc.capath` in the
[user cluster configuration file](/anthos/clusters/docs/on-prem/1.7/how-to/user-cluster-configuration-file).

To work around this issue, run the following script:

<section><pre class="devsite-click-to-copy">
USER_CLUSTER_KUBECONFIG=<var class="edit">YOUR_USER_CLUSTER_KUBECONFIG</var>

IDENTITY_PROVIDER=<var class="edit">YOUR_OIDC_PROVIDER_ADDRESS</var>

openssl s_client -showcerts -verify 5 -connect $IDENTITY_PROVIDER:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){i++}; out="tmpcert"i".pem"; print >out}'

ROOT_CA_ISSUED_CERT=$(ls tmpcert*.pem | tail -1)

ROOT_CA_CERT="/etc/ssl/certs/$(openssl x509 -in $ROOT_CA_ISSUED_CERT -noout -issuer_hash).0"

cat tmpcert*.pem $ROOT_CA_CERT > certchain.pem CERT=$(echo $(base64 certchain.pem) | sed 's\ \\g') rm tmpcert1.pem tmpcert2.pem

kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG patch clientconfig default -n kube-public --type json -p "[{ \"op\": \"replace\", \"path\": \"/spec/authentication/0/oidc/certificateAuthorityData\", \"value\":\"${CERT}\"}]"
</pre></section>

Replace the following:

* <var>YOUR_OIDC_IDENTITY_PROVICER</var>: The address of your OIDC provider:

* <var>YOUR_YOUR_USER_CLUSTER_KUBECONFIG</var>: The path of your user cluster
  kubeconfig file.

## 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}' ```

Log Forwarder 发出过多 OAuth 2.0 请求

在 Anthos clusters on VMware 1.7.1 版中，您可能会遇到 Log Forwarder 发出过多 OAuth 2.0 请求导致消耗内存的问题。要解决此问题，您可以降级 stackdriver-operator 版本，清理磁盘，然后重启 Log Forwarder。

第 0 步：将映像下载到您的私有注册表（如果适用）

如果您使用私有注册表，请按照以下步骤将以下映像下载到您的私有注册表，然后再继续操作。如果您不使用私有注册表，请忽略此步骤。

将 PRIVATE_REGISTRY_HOST 替换为您的私有 Docker 注册表的主机名或 IP 地址。

stackdriver-operator

docker pull gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440

docker tag gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440 \
    PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

docker push PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

fluent-bit

docker pull gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3

docker tag gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3 \
    PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

docker push PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

prometheus

docker pull gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0

docker tag gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0 \
    PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

docker push PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

第 1 步：降级 stackdriver-operator 版本

运行以下命令以降级您的 stackdriver-operator 版本。

kubectl  --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system patch deployment stackdriver-operator -p \
  '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","image":"gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440"}]}}}}'

第 2 步：清理 Log Forwarder 的磁盘缓冲区

在集群中部署 DaemonSet 以清理缓冲区。

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

验证磁盘缓冲区已清理。

kubectl --kubeconfig [CLUSTER_KUBECONFIG] logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

输出会显示集群中的节点数。

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

输出会显示集群中的节点数。

删除清理 DaemonSet。

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup

第 3 步：重启 Log Forwarder

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system rollout restart ds/stackdriver-log-forwarder

日志和指标不会发送到 `stackdriver.projectID` 指定的项目

在 Anthos clusters on VMware 1.7 版中，日志被发送到集群配置文件的 stackdriver.serviceAccountKeyPath 字段中指定的服务帐号的父项目。stackdriver.projectID 的值会被忽略。我们会在即将发布的版本中解决此问题。

作为变通方法，请在日志记录和监控服务帐号的父项目中查看日志。

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

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

管理员集群证书续订过程

在开始之前，请确保在管理员工作站上安装了 OpenSSL。

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

kubectl --kubeconfig [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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%，那么您可能遇到了此问题。

我们预计会在未来的版本中进行修复。同时，您可以通过以下两种解决方法之一来解决此问题：

定期移除位于 /run/aide/cron.daily.old* 的日志文件（推荐）。
按照上述外部链接中所述的步骤操作。（注意：此解决方法可能会影响节点合规性状态）。

将 Anthos Clusters on VMware 与 Anthos Service Mesh 1.7 或更高版本搭配使用

如果您将 Anthos clusters on VMware 与 Anthos Service Mesh 1.7 或更高版本搭配使用，并且想要升级到 Anthos clusters on VMware 1.6.0-1.6.3 版本或 Anthos clusters on VMware 1.7.0-1.7.2 版本，那么您必须从以下自定义资源定义 (CRD) 中移除 bundle.gke.io/component-name 和 bundle.gke.io/component-version 标签：

destinationrules.networking.istio.io
envoyfilters.networking.istio.io
serviceentries.networking.istio.io
virtualservices.networking.istio.io

运行以下命令以更新用户集群中的 CRD destinationrules.networking.istio.io：

kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG

从 CRD 中移除 bundle.gke.io/component-version 和 bundle.gke.io/component-name 标签。

或者，您也可以等待 1.6.4 和 1.7.3 版本，然后直接升级到 1.6.4 或 1.7.3。

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

如果您使用的是以下版本的 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.

远程主机关闭 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 会话。

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

已知问题

由于“无法注册到 GCP”，用户集群升级失败

类别

已识别的版本

表现

原因

临时解决方法

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

类别

已识别的版本

表现

原因

临时解决方法

Log Forwarder 发出过多 OAuth 2.0 请求

第 0 步：将映像下载到您的私有注册表（如果适用）

第 1 步：降级 stackdriver-operator 版本

第 2 步：清理 Log Forwarder 的磁盘缓冲区

第 3 步：重启 Log Forwarder

日志和指标不会发送到 stackdriver.projectID 指定的项目

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

管理员集群证书续订过程

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

将 Anthos Clusters on VMware 与 Anthos Service Mesh 1.7 或更高版本搭配使用

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

防止密码过期错误

缓解密码过期错误

管理员工作站

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

管理员集群插件虚拟机

用户集群控制层面虚拟机

用户集群工作器虚拟机

Seesaw 虚拟机

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

远程主机关闭 SSH 连接

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

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

日志和指标不会发送到 `stackdriver.projectID` 指定的项目

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