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

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

已知问题

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

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

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 对象无法允许任何额外的中断,则节点升级可能会在反复尝试后仍无法升级到控制平面版本。为防止此故障,我们建议您扩容 DeploymentHorizontalPodAutoscaler,以允许节点排空,同时仍遵循 PodDisruptionBudget 配置。

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

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 的主节点选举功能。在此之前,如果您在每次升级期间遇到此问题,则必须再次执行相同的缓解步骤。

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

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

管理员集群证书续订过程

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

  2. 设置 KUBECONFIG 变量:

    KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
    

    ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG 替换为管理员集群 kubeconfig 文件的绝对路径。

  3. 获取管理员主节点的 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')
    
  4. 检查证书是否已过期:

    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
    "sudo kubeadm alpha certs check-expiration"
    

    如果证书已过期,您必须在升级管理员集群之前续订证书。

  5. 备份旧证书:

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

    # ssh into admin master
    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 .
    
  6. 使用 kubeadm 续订证书:

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

  7. 重启管理员主节点:

      # 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
     
  8. 由于在管理员证书过期时管理员集群 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-dataclient-key-data 替换为您创建的 new_admin.conf 文件中的 client-certificate-dataclient-key-data

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

    检查节点证书失效日期

        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
       

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

  10. 您必须验证续订的证书,并验证 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 版本,您可以使用以下两种方法之一手动解决此问题:

  1. 定期移除位于 /run/aide/cron.daily.old* 的日志文件(推荐)。
  2. 按照 /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. 确保临时虚拟机和管理员工作站处于关机状态。

  2. 将管理员工作站的启动磁盘挂接到临时虚拟机。启动磁盘带有“硬盘 1”标签。

  3. 通过运行以下命令,在虚拟机内装载启动磁盘。将 dev/sdc1 替换成您自己的启动磁盘标识符。

    sudo mkdir -p /mnt/boot-disk
    sudo mount /dev/sdc1 /mnt/boot-disk
    
  4. 将 ubuntu 用户到期日期设置为较大的值,例如 99999 天。

    sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
    
  5. 关停临时虚拟机。

  6. 启动管理员工作站。现在,您应该可以照常通过 SSH 连接了。

  7. 在清理时,请删除临时虚拟机。

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

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

管理员集群插件虚拟机

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

  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 admingkectl 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 或更高版本:

避免升级期间发生冲突

  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 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恢复自定义资源(如果有)。

  • 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
    }
    '
    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 点。根据文件系统上的文件数,您可能会在该时间前后遇到由此 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 地址选项,请转到租户 > 应用配置文件 > 应用 EPGuSeg EPG。如果无法停用 IP 学习,则 Cisco API 架构中的不同位置之间会存在 IP 端点波动。

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

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

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

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

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

  1. 查找集群中的所有 anetd 守护程序:

    kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd
    
  2. 检查 anetd 守护程序当前是否看到过时的对等节点:

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

    ANETD_XYZ 替换为 anetd pod 的名称。

  3. 重启所有受影响的 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