已知问题

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

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

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

管理员集群证书续订过程

  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. 由于在管理员证书过期时管理员集群 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

  6. 备份旧证书:

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

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

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

  8. 重启在管理员主节点上运行的静态 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
     
  9. 您必须验证续订的证书,并验证 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 版:

避免升级期间发生冲突

  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
     

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

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

避免升级期间发生冲突

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

通常,您无需在管理员集群中重新安装 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 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恢复自定义资源(如果有)。

  • 如果您使用的是上游默认 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
    }
    '
    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: ""
  

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

  1. govc(vSphere 的命令行界面)提供一些变量来声明您的 vCenter Server 和 vSphere 环境的元素。

    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 是数据磁盘的名称。
  2. 下载 DATA_DISK_NAME‑checkpoint.yaml 文件

    govc datastore.download ${DATA_DISK_NAME}-checkpoint.yaml temp-checkpoint.yaml
  3. 修改检查点字段。

    # 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 文件的路径。

  4. 生成新的校验和。

    • 将检查点文件的最后一行更改为

      checksum:$NEW_CHECKSUM

      NEW_CHECKSUM 替换为以下命令的输出:

      sha256sum temp-checkpoint.yaml
  5. 上传新的检查点文件。

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

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

  1. stackdriver-operator 缩容:

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

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

  2. 打开 gke-metrics-agent-conf ConfigMap 进行修改:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
       edit configmap gke-metrics-agent-conf
    
  3. 将探测间隔从 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
    
  4. 关闭修改会话。

  5. 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 步进行操作
  1. 打开 stackdriver 资源进行修改:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver
    
  2. 如需将 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
    
  3. 保存更改并关闭文本编辑器。

  4. 如需验证更改是否已生效,请运行以下命令:

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

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

  5. 为防止后续更改还原,请缩减 stackdriver-operator

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system scale deploy stackdriver-operator --replicas=0
    
  6. 打开 gke-metrics-agent-conf 进行修改:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit configmap gke-metrics-agent-conf
    
  7. 修改配置以将 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
    
  8. 保存更改并关闭文本编辑器。

  9. 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 地址选项,请转到租户 > 应用配置文件 > 应用 EPGuSeg 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