已知问题

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

/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。

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 自定义资源

gkectl update 会还原您对 ClientConfig 自定义资源所做的所有手动更改。我们强烈建议您在每次手动更改后备份 ClientConfig 资源。

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

表现: 验证失败，因为找不到 F5 BIG-IP 分区（即使分区存在）。
潜在原因: F5 BIG-IP API 的问题可能会导致验证失败。
解决方法: 尝试再次运行 gkectl check-config。

使用 PodDisruptionBudget 的工作负载中断

升级集群可能会导致使用 PodDisruptionBudget (PDB) 的工作负载中断或停机。

节点无法完成升级过程

如果您配置的 PodDisruptionBudget 对象无法允许任何额外的中断，则节点升级可能会在反复尝试后仍无法升级到控制平面版本。为防止此故障，我们建议您扩容 Deployment 或 HorizontalPodAutoscaler，以允许节点排空，同时仍遵循 PodDisruptionBudget 配置。

如需查看不允许出现任何中断的所有 PodDisruptionBudget 对象，请运行以下命令：

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

因 Anthos 1.9.0 中 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.9.1 或更高版本后将不再需要这些步骤，因为 Anthos 将停用 cainjector 的主节点选举功能。

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

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

管理员集群证书续订过程

在开始之前，请确保在管理员工作站上安装了 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

您必须验证续订的证书，并验证 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

针对低于 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 会话。

升级到 1.9.0 或 1.9.1 版时，与 `cert-manager` 发生冲突

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

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

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

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

避免升级期间发生冲突

卸载您的 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

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

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

避免升级期间发生冲突

卸载您的 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 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

将 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。恢复自定义资源（如果有）。

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

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

使用 Seesaw 或手动模式负载均衡器时健康状况不佳的 konnectivity 服务器 Pod

如果您使用的是 Seesaw 或手动模式负载均衡器，则您可能会发现 konnectivity 服务器 Pod 运行状况不佳。这是因为 Seesaw 不支持在服务中重复使用 IP 地址。对于手动模式，创建负载平衡器服务不会自动在负载平衡器上预配该服务。

1.9 版集群启用了 SSH 隧道。这样一来，即使连接服务器运行状况不佳，您仍然可以使用 SSH 隧道，因此与集群内的连接不应受影响。所以您不必担心这些运行状况不佳的 Pod。

如果您计划从版本 1.9.0 升级到 1.9.x，建议您在升级前删除运行状况不佳的 konnectivity 服务器部署。运行此命令。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME delete Deployment konnectivity-server

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

负载均衡器和 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.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: code = 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: ""

如果发生此错误，请按照以下步骤修复集群注册问题。完成此修复后，您便可以升级该管理员集群。

向 govc（vSphere 的命令行界面）提供一些变量来声明您的 vCenter Server 和 vSphere 环境的元素。

注意：您可以在管理员集群配置文件中或通过登录 vCenter Server 找到其中许多值。
```
export GOVC_URL=https://VCENTER_SERVER_ADDRESS
export GOVC_USERNAME=VCENTER_SERVER_USERNAME
export GOVC_PASSWORD=VCENTER_SERVER_PASSWORD
export GOVC_DATASTORE=VSPHERE_DATASTORE
export GOVC_DATACENTER=VSPHERE_DATACENTER
export GOVC_INSECURE=true
# DATA_DISK_NAME should not include the suffix ".vmdk"
export DATA_DISK_NAME=DATA_DISK_NAME
```
替换以下内容：
- VCENTER_SERVER_ADDRESS 是您的 vCenter Server 的 IP 地址或主机名。
- VCENTER_SERVER_USERNAME 是在 vCenter Server 上拥有管理员角色或同等权限的帐号的用户名。
- VCENTER_SERVER_PASSWORD 是 vCenter Server 帐号的密码。
- VSPHERE_DATASTORE 是您在 vSphere 环境中配置的数据存储区的名称。
- VSPHERE_DATACENTER 是您在 vSphere 环境中配置的数据中心的名称。
- DATA_DISK_NAME 是数据磁盘的名称。

下载 DATA_DISK_NAME‑checkpoint.yaml 文件。

govc datastore.download ${DATA_DISK_NAME}-checkpoint.yaml temp-checkpoint.yaml

修改检查点字段。

# Find out the gkeOnPremVersion
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster -n kube-system $ADMIN_CLUSTER_NAME -o=jsonpath='{.spec.gkeOnPremVersion}')

# Replace the gkeOnPremVersion in temp-checkpoint.yaml
sed -i "s/gkeonpremversion: \"\"/gkeonpremversion: \"$GKE_ON_PREM_VERSION\"/" temp-checkpoint.yaml

#The steps below are only needed for upgrading from 1.9x to 1.10x clusters.

# Find out the provider ID of the admin control-plane VM
ADMIN_CONTROL_PLANE_MACHINE_NAME=$(kubectl get machines --no-headers | grep master)
ADMIN_CONTROL_PLANE_PROVIDER_ID=$(kubectl get machines $ADMIN_CONTROL_PLANE_MACHINE_NAME -o=jsonpath='{.spec.providerID}' | sed 's/\//\\\//g')

# Fill in the providerID field in temp-checkpoint.yaml
sed -i "s/providerid: null/providerid: \"$ADMIN_CONTROL_PLANE_PROVIDER_ID\"/" temp-checkpoint.yaml

将 ADMIN_CLUSTER_KUBECONFIG 替换为管理员集群 kubeconfig 文件的路径。

生成新的校验和。
- 将检查点文件的最后一行更改为
```
checksum:$NEW_CHECKSUM
```
  将 NEW_CHECKSUM 替换为以下命令的输出：
```
sha256sum temp-checkpoint.yaml
```

上传新的检查点文件。

govc datastore.upload temp-checkpoint.yaml ${DATA_DISK_NAME}-checkpoint.yaml

使用 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 版本。

流向 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.2/1.9.5 版或更高版本。

如需为早期版本缓解此问题，请执行以下操作：

将 stackdriver-operator 缩容：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   scale deployment stackdriver-operator --replicas=0

将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

打开 gke-metrics-agent-conf ConfigMap 进行修改：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit configmap gke-metrics-agent-conf

将探测间隔从 0.1 秒增加到 13 秒：

processors:
  disk_buffer/metrics:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-metrics
    probe_interval: 13s
    retention_size_mib: 6144
 disk_buffer/self:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-self
    probe_interval: 13s
    retention_size_mib: 200
  disk_buffer/uptime:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-uptime
    probe_interval: 13s
    retention_size_mib: 200

关闭修改会话。

将 gke-metrics-agent DaemonSet 版本更改为 1.1.0-anthos.8：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

部分节点上缺少指标

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

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 - 4 步，增加 gke-metrics-agent 的 CPU
[1.9.0-1.9.4 版]：按照 1 - 9 步进行操作

打开 stackdriver 资源进行修改：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

如需将 gke-metrics-agent 的 CPU 请求从 10m 增加到 50m，请将以下 resourceAttrOverride 部分添加到 stackdriver 清单：

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        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: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

保存更改并关闭文本编辑器。

如需验证更改是否已生效，请运行以下命令：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"

如果修改生效，则该命令会查找 cpu: 50m。

为防止后续更改还原，请缩减 stackdriver-operator：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system scale deploy stackdriver-operator --replicas=0

打开 gke-metrics-agent-conf 进行修改：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit configmap gke-metrics-agent-conf

修改配置以将 probe_interval: 0.1s 的所有实例都更改为 probe_interval: 13s：

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

保存更改并关闭文本编辑器。

将 gke-metrics-agent DaemonSet 版本更改为 1.1.0-anthos.8：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

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 端点波动。

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 节点重新启动后无法运行

类别

已识别的版本

表现

原因

临时解决方法

ClientConfig 自定义资源

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

使用 PodDisruptionBudget 的工作负载中断

节点无法完成升级过程

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

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

管理员集群证书续订过程

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

远程主机关闭 SSH 连接

升级到 1.9.0 或 1.9.1 版时，与 cert-manager 发生冲突

避免升级期间发生冲突

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

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

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

避免升级期间发生冲突

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

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

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

使用 Seesaw 或手动模式负载均衡器时健康状况不佳的 konnectivity 服务器 Pod

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

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

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

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

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

部分节点上缺少指标

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

gkectl diagnose 检查证书失败

升级到 1.9.0 或 1.9.1 版时，与 `cert-manager` 发生冲突

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

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