已知问题

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

ClientConfig 自定义资源

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

kubectl describe CSINode 和 gkectl diagnose snapshot

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

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

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

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

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

注意：如果您已开始升级过程，并发现证书过期错误，请与 Google 支持团队联系以获取帮助。

注意：本指南专用于管理员集群证书续订。

管理员集群证书续订过程

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-data 和 client-key-data 替换为您创建的 new_admin.conf 文件中的 client-certificate-data 和 client-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. 续订管理员集群工作器节点的证书

   检查节点证书失效日期

       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
      # check nodes are ready
      kubectl --kubeconfig $KUBECONFIG get nodes
      

将 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

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

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

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

或者，您可以直接升级到 1.6.4 或 1.7.3。

如果数据磁盘几乎已满，则升级管理员工作站可能会失败

如果您使用 gkectl upgrade admin-workstation 命令升级管理员工作站，则当数据磁盘几乎已满时，升级可能会失败，因为系统会在升级到新的管理员工作站时尝试在本地备份当前的管理员工作站。如果无法清除数据磁盘上的足够空间，请使用带有附加标志 --backup-to-local=false 的 gkectl upgrade admin-workstation 命令来防止对当前管理工作站进行本地备份。

针对低于 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.