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

已知问题

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

ClientConfig 自定义资源

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

kubectl describe CSINodegkectl diagnose snapshot

kubectl describe CSINodegkectl diagnose snapshot 有时会由于取消引用 nil 指针字段时出现 OSS Kubernetes 问题而失败。

OIDC 和 CA 证书

默认情况下,OIDC 提供程序不使用公共 CA。您必须明确提供 CA 证书。

将管理员集群从 1.5 升级到 1.6.0 会中断使用 OIDC 提供商且用户集群配置文件中没有 authentication.oidc.capath 的值的 1.5 版用户集群。

如需解决此问题,请运行以下脚本:

USER_CLUSTER_KUBECONFIG=YOUR_USER_CLUSTER_KUBECONFIG

IDENTITY_PROVIDER=YOUR_OIDC_PROVIDER_ADDRESS

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}\"}]"

请替换以下内容:

  • YOUR_OIDC_IDENTITY_PROVICER:您的 OIDC 提供商的地址:

  • YOUR_YOUR_USER_CLUSTER_KUBECONFIG:用户集群 kubeconfig 文件的路径。

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

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 的值会被忽略。我们会在即将发布的版本中解决此问题。

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

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

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

管理员集群证书续订过程

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

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

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

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

  4. 备份旧证书:

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

    # 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 .
    
  5. 使用 kubeadm 续订证书:

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

  6. 重启管理员主节点:

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

  8. 您必须验证续订的证书,并验证 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%,那么您可能遇到了此问题。

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

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

将 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-namebundle.gke.io/component-version 标签:

  • destinationrules.networking.istio.io
  • envoyfilters.networking.istio.io
  • serviceentries.networking.istio.io
  • virtualservices.networking.istio.io
  1. 运行以下命令以更新用户集群中的 CRD destinationrules.networking.istio.io

    kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG
  2. 从 CRD 中移除 bundle.gke.io/component-versionbundle.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. 确保临时虚拟机和管理员工作站处于关机状态。

  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.

远程主机关闭 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 点。根据文件系统上的文件数,您可能会在该时间前后遇到由此 aide 进程引起的 CPU 和内存用量激增。

如果激增影响了您的工作负载,您可以停用每日 Cron 作业:

`sudo chmod -x /etc/cron.daily/aide`.