Google Distributed Cloud for Bare Metal 已知问题

本页面列出了纯软件 Google Distributed Cloud for Bare Metal（即之前的 Google Distributed Cloud Virtual）的所有已知问题。如需按产品版本或问题类别过滤已知问题，请从下面的下拉菜单中选择所需的过滤条件。

选择您的 Google Distributed Cloud 版本：

1.29 1.28 1.16 1.15 1.14 1.13 1.12 1.11 1.10

选择问题类别：

配置 安装 升级和更新 操作 日志记录和监控 网络 安全性 重置/删除 VM Runtime on GDC

或者，搜索您的问题：

类别	已识别的版本	问题和解决方法
安装、升级和更新	1.28.0 至 1.28.600 以及 1.29.0 至 1.29.200	check_inotify_max_user_instances 和 check_inotify_max_user_watches 设置的机器预检检查失败 在安装或升级集群期间，与 fs.inotify 内核设置相关的机器预检检查可能会失败。如果您受到此问题的影响，则机器预检检查日志将包含如下错误： Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value. 出现此问题是因为系统错误地从控制平面和引导主机读取 fs.inotify max_user_instances 和 max_user_watches 值，它应该从预期的节点机器读取这些值。 临时解决方法： 如需解决此问题，请将所有控制平面和引导机器上的 fs.inotify.max_user_instances 和 fs.inotify.max_user_watches 都调整为推荐的值： echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf sudo sysctl -p 安装或升级操作完成后，您可以根据需要还原这些值。
配置、安装、升级和更新、网络、安全性	1.15、1.16、1.28、1.29	在 ipam-controller-manager 为必需组件的情况下，集群安装和升级失败 如果 ipam-controller-manager 为必需组件，且集群在 Red Hat Enterprise Linux (RHEL) 8.9 或更高版本（具体取决于上游 RHEL 更改）上运行，SELinux 在强制执行模式下运行，则集群安装和升级会失败。该问题只会在 container-selinux 版本高于 2.225.0 的情况下发生。 在以下任一情况下，您的集群都必须有 ipam-controller-manager 组件： 您的集群被配置为使用 IPv4/IPv6 双栈网络 您在配置集群时将 clusterNetwork.flatIPv4 设置为 true 您在配置集群时使用了 preview.baremetal.cluster.gke.io/multi-networking: enable 注解 如果安装了 ipam-controller-manager，集群安装和升级会失败。 临时解决方法 将每个控制平面节点上 /etc/kubernetes 目录的默认上下文设置为 etc_t 类型： semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes 这些命令会还原对 /etc/kubernetes 目录上的 container-selinux 所做的更改。 将集群升级到包含该问题修复的版本后，可在每个控制平面节点上撤消对文件上下文所做的上述更改： semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
升级	1.28.0 至 1.28.500	集群升级失败并报告 Google Cloud 可达性检查错误 使用 bmctl 升级集群时，即便能够从管理员工作站访问目标网址，升级也可能会失败并报告 GCP reachability check failed 错误。此问题是由 bmctl 1.28.0 版到 1.28.500 版中的 bug 引起的。 临时解决方法： 在运行 bmctl upgrade 命令之前，将 GOOGLE_APPLICATION_CREDENTIALS 环境变量设置为指向有效的服务账号密钥文件： export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG 以这种方式设置应用默认凭据 (ADC) 可确保 bmctl 具有访问 Google API 端点所需的凭据。
配置、安装、升级和更新、网络、安全性	1.15、1.16、1.28、1.29	在 ipam-controller-manager 为必需组件的情况下，集群安装和升级失败 如果 ipam-controller-manager 为必需组件，且集群在 Red Hat Enterprise Linux (RHEL) 8.9 或更高版本（具体取决于上游 RHEL 更改）上运行，SELinux 在强制执行模式下运行，则集群安装和升级会失败。该问题只会在 container-selinux 版本高于 2.225.0 的情况下发生。 在以下任一情况下，您的集群都必须有 ipam-controller-manager 组件： 您的集群被配置为使用 IPv4/IPv6 双栈网络 您在配置集群时将 clusterNetwork.flatIPv4 设置为 true 您在配置集群时使用了 preview.baremetal.cluster.gke.io/multi-networking: enable 注解 如果安装了 ipam-controller-manager，集群安装和升级会失败。 临时解决方法 将每个控制平面节点上 /etc/kubernetes 目录的默认上下文设置为 etc_t 类型： semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes 这些命令会还原对 /etc/kubernetes 目录上的 container-selinux 所做的更改。 将集群升级到包含该问题修复的版本后，可在每个控制平面节点上撤消对文件上下文所做的上述更改： semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
升级	1.28.0 至 1.28.500	集群升级失败并报告 Google Cloud 可达性检查错误 使用 bmctl 升级集群时，即便能够从管理员工作站访问目标网址，升级也可能会失败并报告 GCP reachability check failed 错误。此问题是由 bmctl 1.28.0 版到 1.28.500 版中的 bug 引起的。 临时解决方法： 在运行 bmctl upgrade 命令之前，将 GOOGLE_APPLICATION_CREDENTIALS 环境变量设置为指向有效的服务账号密钥文件： export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG 以这种方式设置应用默认凭据 (ADC) 可确保 bmctl 具有访问 Google API 端点所需的凭据。
安装	1.29	具有独立负载均衡器节点池的集群存在 Binary Authorization 问题 如果您在创建集群期间启用了 Binary Authorization 政策，则具有独立负载均衡器节点池的集群安装可能会失败。 出现此问题是因为 Binary Authorization webhook 会阻止创建 GKE Identity Service Pod 和其他关键 Pod。 要确定您是否受此问题影响，请执行以下步骤： 确定哪些 Pod 发生故障： kubectl get pods \ -n anthos-identity-service \ --kubeconfig CLUSTER_KUBECONFIG 描述故障 Pod。 查找输出中是否有以下消息： admission webhook "binaryauthorization.googleapis.com" denied the request: failed to post request to endpoint: Post "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview": oauth2/google: status code 400: {"error":"invalid_target","error_description":"The target service indicated by the \"audience\" parameters is invalid. This might either be because the pool or provider is disabled or deleted or because it doesn't exist."} 如果您看到上述消息，则表示您的集群存在此问题。 临时解决方法： 如需解决此问题，请完成以下步骤： 取消集群创建操作。 从集群配置文件中移除 spec.binaryAuthorization 块。 创建停用了 Binary Authorization 的集群。 安装完成后，为现有集群启用 Binary Authorization 政策。
配置、安装	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29	启用了 SELinux 的装载点导致问题 如果您启用了 SELinux 并将文件系统装载到 Kubernetes 相关目录，则可能会遇到集群创建失败、无法读取文件或缺少权限等问题。 要确定您是否受此问题影响，请运行以下命令： ls -Z /var/lib/containerd 。如果您在应该会显示其他标签（例如 system_u:object_r:container_var_lib_t:s0）的位置看到 system_u:object_r:unlabeled_t:s0，则表示您受此问题影响。 临时解决方法： 如果您最近将文件系统装载到了目录，请用 SELinux 配置确保这些目录是最新状态。 在运行 bmctl create cluster 之前，您还应在每台机器上运行以下命令： restorecon -R -v /var restorecon -R -v /etc 虽然这是一次性的修复，但无需在每次重启后重新应用修复，不过需要在每次添加具有相同装载点的新节点后再次应用修复。如需了解详情，请参阅 Red Hat 文档中的装载文件系统部分。
重置/删除	1.29.0	重置用户集群时尝试删除命名空间失败 运行 bmctl reset cluster -c ${USER_CLUSTER} 时，在所有相关操作均已完成后，该命令无法删除用户集群命名空间。用户集群命名空间卡在 Terminating 状态。最终，集群重置命令会超时并返回错误。 临时解决方法： 如需移除命名空间并完成用户集群重置操作，请按以下步骤操作： 从管理员集群中删除 metrics-server Pod： kubectl delete pods -l k8s-app=metrics-server \ -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH 在这种情况下，metrics-server Pod 会阻止移除集群命名空间。 在管理员集群中，强制移除用户集群命名空间中的终结器： kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \ jq '.spec.finalizers = []' | \ kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f - 移除终结器后，集群命名空间将被移除，集群重置操作即会完成。
配置、安装、安全性	1.16.0 至 1.16.7，1.28.0 至 1.28.400	Binary Authorization Deployment 缺少 nodeSelector 如果您启用了适用于 GKE on Bare Metal 的 Binary Authorization，并且使用的是 1.16.0 到 1.16.7 或 1.28.0 到 1.28.400 版，则如果安排该功能 Pod，便可能会遇到问题。在这些版本中，Binary Authorization Deployment 缺少 nodeSelector，因此该功能 Pod 可以安排在工作器节点上，而不是控制平面节点上。虽然此行为不会导致任何故障，但这并非预期行为。 临时解决方法： 对于所有受影响的集群，请完成以下步骤： 打开 Binary Authorization Deployment 文件： kubectl edit -n binauthz-system deployment binauthz-module-deployment 在 spec.template.spec 块中添加以下 nodeSelector： nodeSelector: node-role.kubernetes.io/control-plane: "" 保存更改。 保存更改后，Pod 只会重新部署到控制平面节点。每次升级后都需要重新应用该修复。
升级和更新	1.28.0、1.28.100、1.28.200、1.28.300	将集群升级到 1.28.0 至 1.28.300 版时出错 将 1.11.0 版之前创建的集群升级到 1.28.0 至 1.28.300 版可能会导致生命周期控制器部署方 Pod 在升级期间进入错误状态。发生这种情况时，生命周期控制器部署方 Pod 的日志会显示类似于以下内容的错误消息： "inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions 临时解决方法： 此问题已在 1.28.400 版中得到修复。升级到 1.28.400 版或更高版本即可解决此问题。 如果您无法升级，请运行以下命令来解决该问题： kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
日志记录和监控	1.13.7、1.14、1.15、1.16、1.28	Logs Explorer 中显示的项目 ID 不正确 有时，集群或容器日志在 Logs Explorer 的 resource.labels.project_id 中会使用不同的项目 ID 进行标记。 在以下情况下可能会发生该问题：集群被配置为使用可观测性 PROJECT_ONE（在集群配置的 clusterOperations.projectID 字段中设置）；而配置中的 cloudOperationsServiceAccountKeyPath 使用的是项目 PROJECT_TWO 中的服务账号密钥。 在这种情况下，所有日志都会路由到 PROJECT_ONE，但 resource.labels.project_id 会被标记为 PROJECT_TWO。 临时解决方法： 请使用以下任一方法来解决该问题： 使用来自同一目标项目的服务账号。 将服务账号密钥 JSON 文件中的 project_id 更改为当前项目。 通过 Logs Explorer 中的日志过滤器直接更改 project_id。
网络	1.29.0	使用 BGP 进行捆绑式负载均衡的集群性能下降 对于使用 BGP 进行捆绑式负载均衡的 1.29.0 版集群，当 LoadBalancer 类型的 Service 总数接近 2,000 时，负载均衡性能可能会下降。随着性能下降，新创建的 Service 可能需要很长时间才能与客户端建立连接，或者根本就无法建立连接。现有 Service 虽然可以继续运行，但无法有效地处理故障模式（例如负载均衡器节点丢失）。当 ang-controller-manager Deployment 由于内存不足而终止时，便会发生这些 Service 问题。 如果您的集群受此问题影响，则集群中的 Service 无法访问且健康状况不佳，并且 ang-controller-manager Deployment 会陷入 CrashLoopBackOff 状态。列出 ang-controller-manager Deployment 时的响应如下所示： ang-controller-manager-79cdd97b88-9b2rd 0/1 CrashLoopBackOff 639 (59s ago) 2d10h 10.250.210.152 vm-bgplb-centos4-n1-02 <none> <none> ang-controller-manager-79cdd97b88-r6tcl 0/1 CrashLoopBackOff 620 (4m6s ago) 2d10h 10.250.202.2 vm-bgplb-centos4-n1-11 <none> <none> 临时解决方法 如需解决此问题，您可以将 ang-controller-manager Deployment 的内存资源限额提高 100MiB，并移除 CPU 限额： kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG 成功进行上述更改并关闭编辑器后，您应该会看到如下输出： deployment.apps/ang-controller-manager edited 如要验证更改是否已生效，您可以检查集群中的 ang-controller-manager 的清单： kubectl get deployment ang-controller-manager \ -n kube-system \ -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \ --kubeconfig ADMIN_KUBECONFIG 响应应类似如下所示： NAME CPU_LIMITS MEMORY_LIMITS ang-controller-manager <none> 400Mi
安装、升级、备份和恢复	1.28.0、1.28.100	Container Registry 端点 gcr.io 的连接问题可能会阻止集群操作 有多项管理员集群操作会创建引导集群。在创建引导集群之前，bmctl 会从管理员工作站执行 Google Cloud 可达性检查。此检查可能会因 Container Registry 端点 gcr.io 的连接问题而失败，并且您可能会看到如下错误消息： system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers) 临时解决方法 如需解决此问题，请使用 --ignore-validation-errors 标志重试操作。
网络	1.15、1.16	GKE Dataplane V2 与部分存储驱动程序不兼容 GKE on Bare Metal 集群使用 GKE Dataplane V2，但后者与部分存储空间服务不兼容。您可能会遇到 NFS 卷或 Pod 卡住问题。如果您的工作负载使用由下列易受此问题影响的存储驱动程序提供支持的 ReadWriteMany 卷，则这种情况尤为可能发生： Robin.io Portworx（sharedv4 服务卷） csi-nfs 该列表并不详尽。 临时解决方法 以下 Ubuntu 版本提供了对此问题的修复： 20.04 LTS：使用高于 linux-image-5.4.0-166-generic 的 5.4.0 内核映像 22.04 LTS：使用高于 linux-image-5.15.0-88-generic 的 5.15.0 内核映像，或者使用 6.5 HWE 内核。 如果您使用的不是上述版本之一，请与 Google 支持团队联系。
日志记录和监控	1.15、1.16、1.28	大型集群中出现 kube-state-metrics 内存不足 (OOM) 您可能会注意到，kube-state-metrics 或是与 kube-state-metrics 位于同一节点上的 gke-metrics-agent Pod 内存不足 (OOM)。 如果集群中的节点数量超过 50 个或是包含的 Kubernetes 对象过多，则可能会发生这种情况。 临时解决方法 如需解决此问题，请将 stackdriver 自定义资源定义更新为使用 ksmNodePodMetricsOnly 特性门控。此特性门控可确保仅公开少量关键指标。 如需使用此临时解决方法，请完成以下步骤： 查看 stackdriver 自定义资源定义可用的特性门控： kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly 更新 stackdriver 自定义资源定义以启用 ksmNodePodMetricsOnly： kind:stackdriver spec: featureGates: ksmNodePodMetricsOnly: true
安装	1.28.0 至 1.28.200	由于缺少 iptables，RHEL 9.2 上的预检检查失败 在 Red Hat Enterprise Linux (RHEL) 9.2 操作系统上安装集群时，如果缺少 iptables 包，则可能会发生故障。预检检查期间发生故障，并触发类似于以下内容的错误消息： 'check_package_availability_pass': "The following packages are not available: ['iptables']" 对于 Google Distributed Cloud 1.28 版，RHEL 9.2 为预览版。 临时解决方法 在集群资源上将 spec.bypassPreflightCheck 设置为 true，绕过预检检查错误。
操作	1.10、1.11、1.12、1.13、1.14、1.15、1.16	有大量服务需要处理时 MetalLB 故障切换缓慢 如果 MetalLB 需要处理大量服务（超过 10,000 个），则故障切换过程可能需要超过一个小时才能完成。这是因为 MetalLB 使用的是有速率限制的队列，如果有大量服务需要处理，该队列可能需要一段时间才能到达需要进行故障切换的服务。 临时解决方法 将集群升级到 1.28 版或更高版本。如果您无法进行升级，可以通过手动修改服务（例如添加注解）使服务更快地进行故障切换。
操作	1.16.0 至 1.16.6、1.28.0 至 1.28.200	如果启用了代理，则必须在管理员工作站上设置环境变量 如果您未在管理员工作站中定义 HTTPS_PROXY 和 NO_PROXY 环境变量，bmctl check cluster 可能会因代理故障而失败。bmctl 命令会报告有关无法调用某些 Google 服务的错误消息，如以下示例所示： [2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred: * GKERegister check failed: 2 errors occurred: * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout 临时解决方法 在管理员工作站中手动设置 HTTPS_PROXY 和 NO_PROXY。
升级和更新	1.28.0-gke.435	如果 audit.log 的所有权不正确，则升级到 1.28.0-gke.435 版可能会失败 在某些情况下，控制平面节点上的 /var/log/apiserver/audit.log 文件会将群组和用户所有权都设置为 root。在将集群从 1.16.x 版升级到 1.28.0-gke.435 版时，此文件所有权设置会导致控制平面节点升级失败。此问题只会出现在 1.11 版之前创建并停用了 Cloud Audit Logs 的集群中。1.9 版及更高版本的集群默认会启用 Cloud Audit Logs。 临时解决方法 如果您无法将集群升级到 1.28.100-gke.146 版，请按照以下步骤将集群升级到 1.28.0-gke.435 版来临时解决该问题： 如果启用了 Cloud Audit Logs，请移除 /var/log/apiserver/audit.log 文件。 如果 Cloud Audit Logs 已停用，请将 /var/log/apiserver/audit.log 所有权更改为与父级目录 /var/log/apiserver 相同。
网络、升级和更新	1.28.0-gke.435	MetalLB 未将 IP 地址分配给 VIP Service Google Distributed Cloud 使用 MetalLB 进行捆绑式负载均衡。在 Google Distributed Cloud 1.28.0-gke.435 版中，捆绑式 MetalLB 升级到了 0.13 版，其中引入了对 IPAddressPools 的 CRD 支持。但是，由于 ConfigMaps 允许 IPAddressPool 使用任何名称，因此，必须通过在 IPAddressPool 名称末尾附加哈希值来将池名称转换为与 Kubernetes 兼容的名称。例如，将集群升级到 1.28.0-gke.435 版时，名为 default 的 IPAddressPool 会被转换为类似 default-qpvpd 这样的名称。 由于 MetalLB 需要有特定的 IPPool 名称才能选择相应池，因此名称转换之后，MetalLB 将无法选择池和分配 IP 地址。而使用 metallb.universe.tf/address-pool 注解为 IP 地址选择地址池的 Service 也不会再从 MetalLB 控制器接收 IP 地址。 此问题在 Google Distributed Cloud 1.28.100-gke.146 版中已得到修复。 临时解决方法 如果您无法将集群升级到 1.28.100-gke.146 版，请按照以下步骤操作来解决该问题： 获取转换后的 IPAddressPool 名称： kubectl get IPAddressPools -n kube-system 更新受影响的 Service，将 metallb.universe.tf/address-pool 注解设置为附加了哈希值的转换后名称。 例如，如果 IPAddressPool 名称已从 default 转换为类似 default-qpvpd 这样的名称，请将 Service 中的 metallb.universe.tf/address-pool: default 注解更改为 metallb.universe.tf/address-pool: default-qpvpd。 由于名称转换过程使用的哈希值是确定性的，因此该解决方法是永久性的。
升级和更新	1.14、1.15、1.16、1.28、1.29	升级到 1.14.x 版后产生孤立 Pod 将 Google Distributed Cloud 集群升级到 1.14.x 版时，之前版本中的部分资源不会被删除。具体而言，您可能会看到一组孤立 Pod，如下所示： capi-webhook-system/capi-controller-manager-xxx capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx 这些孤立对象不会直接影响集群操作，但我们建议您最好将其移除。 运行以下命令以移除孤立对象： kubectl delete ns capi-webhook-system kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration 此问题在 Google Distributed Cloud 1.15.0 及更高版本中已得到修复。
安装	1.14	集群创建卡在 machine-init 作业 如果您尝试安装 Google Distributed Cloud 1.14.x 版，则可能会因 machine-init 作业而安装失败，并会看到类似如下所示的输出： "kubeadm join" task failed due to: error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members "kubeadm reset" task failed due to: panic: runtime error: invalid memory address or nil pointer dereference 临时解决方法： 移除导致 machine-init 作业失败的过时 etcd 成员。在正常运行的控制平面节点上完成以下步骤： 列出现有的 etcd 成员： etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member list 查找状态为 unstarted 的成员，如以下示例输出所示： 5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false 99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false 移除失败的 etcd 成员： etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member remove MEMBER_ID 将 MEMBER_ID 替换为失败的 etcd 成员的 ID。在前面的示例输出中，此 ID 为 bd1949bcb70e2cb5。 以下示例输出显示该成员已被移除： Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
网络	1.28.0	Cilium-operator 缺少节点 list 和 watch 权限 在 Cilium 1.13 中，cilium-operator ClusterRole 权限不正确。缺少节点 list 和 watch 权限。cilium-operator 未能启动垃圾回收器，从而导致以下问题： Cilium 资源泄露。 系统不会从 BFP 政策映射中移除过时的身份。 政策映射可能会达到 16K 的大小上限。 无法添加新条目。 NetworkPolicy 强制执行不正确。 身份可能会达到 64K 的大小上限。 无法创建新 Pod。 缺少节点权限的 Operator 会报告以下示例日志消息： 2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s 如果 Cilium 代理无法将条目插入政策映射，会报告如以下示例所示的错误消息： level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint 临时解决方法： 移除 Cilium 身份，然后将缺少的 ClusterRole 权限添加到 Operator： 移除现有的 CiliumIdentity 对象： kubectl delete ciliumid –-all 修改 cilium-operator ClusterRole 对象： kubectl edit clusterrole cilium-operator 为 nodes 添加一个包含缺少权限的部分，如以下示例所示： - apiGroups: - "" resources: - nodes verbs: - get - list - watch 保存并关闭编辑器。Operator 会动态检测权限更改。您无需手动重启 Operator。
升级和更新	1.15.0 至 1.15.7、1.16.0 至 1.16.3	预检检查期间遇到暂时性问题 在升级预检检查期间运行的其中一个 kubeadm 健康检查任务可能会失败，并报告以下错误消息： [ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found 您可以放心地忽略此错误。如果此错误阻止了升级成功完成，重新运行升级命令即可。 如果您在使用 bmctl preflightcheck 命令运行预检时观察到此错误，则此错误不会有任何影响。再次运行预检检查即可获取准确的预检信息。 临时解决方法： 重新运行升级命令；如果在 bmctl preflightcheck 期间遇到该错误，重新运行 preflightcheck 命令。
操作	1.14、1.15.0 至 1.15.7、1.16.0 至 1.16.3、1.28.0	替换或移除节点后，定期网络健康检查失败 此问题会影响在替换或移除节点后执行定期网络健康检查的集群。如果您的集群需要定期进行健康检查，则在替换或移除节点后进行定期网络健康检查会导致失败，因为网络清单 ConfigMap 在创建后不会更新。 临时解决方法： 建议您删除清单 ConfigMap 和定期网络健康检查以临时解决该问题。集群 Operator 会自动使用最新信息重新创建这些对象。 对于 1.14.x 集群，请运行以下命令： kubectl delete configmap \ $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ CLUSTER_NAME-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 对于 1.15.0 及更高版本的集群，请运行以下命令： kubectl delete configmap \ $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ bm-system-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG
网络	1.14、1.15、1.16.0 至 1.16.2	设备名称包含英文句点时，Network Gateway for GDC 无法应用您的配置 如果您的网络设备名称中包含英文句点字符 (.），例如 bond0.2，Network Gateway for GDC 在运行 sysctl 做出更改时会将该英文句点视为目录路径。在 Network Gateway for GDC 检查是否启用了重复地址检测 (DAD) 时，检查可能会失败，因此不会进行协调。 该行为在不同集群版本中的表现会有所不同： 1.14 和 1.15：仅当使用 IPv6 浮动 IP 地址时，才会发生此错误。如果您不使用 IPv6 浮动 IP 地址，则即便您的设备名称中包含英文句点，也不会出现此问题。 1.16.0 至 1.16.2：如果您的设备名称中包含英文句点，则一定会发生此错误。 临时解决方法： 将集群升级到 1.16.3 版或更高版本。 在升级集群之前，若要解决此问题，请从设备名称中移除英文句点 (.)。
升级和更新、网络、安全性	1.16.0	停用 seccomp 后，升级到 1.16.0 失败 如果为集群停用了 seccomp（spec.clusterSecurity.enableSeccomp 设置为 false），则升级到 1.16.0 版会失败。 Google Distributed Cloud 1.16 版使用 Kubernetes 1.27 版。在 Kubernetes 1.27.0 及更高版本中，将使用正式版功能来设置 seccomp 配置文件，而不再使用特性门控。如果在集群配置中停用 seccomp，此项 Kubernetes 更改会导致升级到 1.16.0 版失败。此问题在 1.16.1 版及更高版本的集群中已得到修复。如果将 cluster.spec.clusterSecurity.enableSeccomp 字段设为了 false，可以升级到 1.16.1 版或更高版本。 未设置 spec.clusterSecurity.enableSeccomp 或将其设为 true 的集群不受影响。
安装、操作	1.11、1.12、1.13、1.14、1.15.0 至 1.15.5、1.16.0 至 1.16.1	装载 /var/lib/containerd 后，containerd 元数据在重启后可能会损坏 如果您选择了装载 /var/lib/containerd，则 containerd 元数据可能会在重启后损坏。损坏的元数据可能会导致 Pod（包括系统关键 Pod）故障。 如需检查此问题是否对您有影响，请查看是否在 /etc/fstab 中为 /var/lib/containerd/ 定义了可选装载，以及装载选项中是否有 nofail。 临时解决方法： 移除 /etc/fstab 中的 nofail 装载选项，或将集群升级到 1.15.6 版或更高版本。
操作	1.13、1.14、1.15、1.16、1.28	清理集群中的过时 Pod 您可能会看到由 Deployment (ReplicaSet) 管理的 Pod 状态为 Failed，并且有 TaintToleration 状态。这些 Pod 虽然不会使用集群资源，但应该将其删除。 您可以使用以下 kubectl 命令列出可以清理的 Pod： kubectl get pods –A | grep TaintToleration 以下示例输出显示了有 TaintToleration 状态的 Pod： kube-system stackdriver-metadata-agent-[...] 0/1 TaintToleration 0 临时解决方法： 对于具有所述问题的每个 Pod，检查该 Pod 所属的 ReplicaSet。如果相应 ReplicaSet 满足条件，则可以删除该 Pod： 获取管理 Pod 的 ReplicaSet 并找到 ownerRef.Kind 值： kubectl get pod POD_NAME -n NAMESPACE -o yaml 获取 ReplicaSet 并验证 status.replicas 是否与 spec.replicas 相同： kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml 如果名称一致，则可删除 Pod： kubectl delete pod POD_NAME -n NAMESPACE.
升级	1.16.0	升级到 1.16.0 版后，etcd-events 可能会停滞 将现有集群升级到 1.16.0 版后，与 etcd-events 相关的 Pod 故障可能会导致操作停滞。具体而言，升级节点作业在 TASK [etcd_events_install : Run etcdevents] 步骤失败。 如果您受此问题影响，则会看到如下 Pod 故障： kube-apiserver Pod 无法启动，并报告以下错误： connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused" etcd-events Pod 无法启动，并报告以下错误： Error: error syncing endpoints with etcd: context deadline exceeded 临时解决方法： 如果您无法将集群升级到包含该问题修复的版本，可以使用以下临时解决方法来解决该问题： 使用 SSH 访问包含所报告错误的控制平面节点。 修改 etcd-events 清单文件 /etc/kubernetes/manifests/etcd-events.yaml，并移除 initial-cluster-state=existing 标志。 应用清单。 升级现在应能继续完成。
网络	1.15.0 至 1.15.2	无法识别 CoreDNS orderPolicy OrderPolicy 未被识别为参数，因此未被使用。因此，Google Distributed Cloud 始终使用 Random。 出现此问题是因为 CoreDNS 模板未更新，导致 orderPolicy 被忽略。 临时解决方法： 更新 CoreDNS 模板并应用修复。该修复在升级之前一直有效。 修改现有模板： kubectl edit cm -n kube-system coredns-template 将模板内容替换为以下内容： coredns-template: |- .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } {{- if .PrivateGoogleAccess }} import zones/private.Corefile {{- end }} {{- if .RestrictedGoogleAccess }} import zones/restricted.Corefile {{- end }} prometheus :9153 forward . {{ .UpstreamNameservers }} { max_concurrent 1000 {{- if ne .OrderPolicy "" }} policy {{ .OrderPolicy }} {{- end }} } cache 30 {{- if .DefaultDomainQueryLogging }} log {{- end }} loop reload loadbalance }{{ range $i, $stubdomain := .StubDomains }} {{ $stubdomain.Domain }}:53 { errors {{- if $stubdomain.QueryLogging }} log {{- end }} cache 30 forward . {{ $stubdomain.Nameservers }} { max_concurrent 1000 {{- if ne $.OrderPolicy "" }} policy {{ $.OrderPolicy }} {{- end }} } } {{- end }}
网络、操作	1.10、1.11、1.12、1.13、1.14	Network Gateway for GDC 组件由于缺少优先级类而被逐出或挂起 kube-system 中的网络网关 Pod 可能会显示 Pending 或 Evicted 状态，如以下精简示例输出所示： $ kubectl -n kube-system get pods | grep ang-node ang-node-bjkkc 2/2 Running 0 5d2h ang-node-mw8cq 0/2 Evicted 0 6m5s ang-node-zsmq7 0/2 Pending 0 7h 这些错误表示逐出事件或由于节点资源而无法调度 Pod。由于 Network Gateway for GDC Pod 没有 PriorityClass，因此它们具有与其他工作负载相同的默认优先级。当节点资源受限时，网络网关 Pod 可能会被逐出。此行为对于 ang-node DaemonSet 尤为糟糕，因为这些 Pod 必须在特定节点上调度，并且不能迁移。 临时解决方法： 升级到 1.15 或更高版本。 作为短期修复，您可以手动为 Network Gateway for GDC 组件分配 PriorityClass。Google Distributed Cloud 控制器会在协调过程中（例如在集群升级期间）覆盖这些手动更改。 将 system-cluster-critical PriorityClass 分配给 ang-controller-manager 和 autoscaler 集群控制器 Deployment。 将 system-node-critical PriorityClass 分配给 ang-daemon 节点 DaemonSet。
安装、升级和更新	1.15.0、1.15.1、1.15.2	由于集群名称长度，集群创建和升级失败 创建版本 1.15.0、1.15.1 或 1.15.2 集群或将集群升级到版本 1.15.0、1.15.1 或 1.15.2 时，如果集群名称长度超过 48 个字符（1.15.0 版）或 45 个字符（1.15.1 或 1.15.2 版），则会失败。在集群创建和升级操作期间，Google Distributed Cloud 会创建一个健康检查资源，并用一个包含集群名称和版本信息的名称为该资源命名： 对于 1.15.0 版集群，健康检查资源名称为 CLUSTER_NAME-add-ons-CLUSTER_VER。 对于 1.15.1 版或 1.15.2 版集群，健康检查资源名称为 CLUSTER_NAME-kubernetes-CLUSTER_VER。 对于长集群名称，健康检查资源名称超出了 Kubernetes 标签名称的 63 个字符长度限制，这会阻止创建健康检查资源。 如果没有成功的健康检查，集群操作将失败。 如需查看您是否受到此问题的影响，请使用 kubectl describe 检查失败的资源： kubectl describe healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 如果此问题影响您，则响应将包含针对 ReconcileError 的警告，如下所示： ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred: * failed to create job for health check db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch "bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters, spec.template.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters] 临时解决方法 如需解锁集群升级或创建，您可以绕过健康检查。使用以下命令来修补具有传递状态的健康检查自定义资源：(status: {pass: true}) kubectl patch healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG --type=merge \ --subresource status --patch 'status: {pass: true}'
升级和更新	1.14、1.15	具有预览版功能的 1.14.0 和 1.14.1 版集群无法升级到 1.15.x 版 如果 1.14.0 和 1.14.1 版集群启用了预览版功能，则它们将无法成功升级到 1.15.x 版。这适用于预览版功能，例如可以在没有 kube-proxy 的情况下创建集群，该功能可在集群配置文件中使用以下注释来启用： preview.baremetal.cluster.gke.io/kube-proxy-free: "enable" 如果您受到此问题的影响，则在集群升级期间会收到如下错误： [2023-06-20 23:37:47+0000] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid: Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]: Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature isn't supported in 1.15.1 Anthos Bare Metal version 此问题在 1.14.2 版及更高版本的集群中已得到修复。 临时解决方法： 如果在升级到 1.15.x 版之前您无法将集群升级到 1.14.2 版或更高版本，则可以使用引导集群直接升级到 1.15.x 版： bmctl upgrade cluster --use-bootstrap=true
操作	1.15	1.15 版集群不接受重复的浮动 IP 地址 Network Gateway for GDC 不允许您创建包含 spec.floatingIPs 中已在现有 NetworkGatewayGroup 自定义资源中使用的 IP 地址的新 NetworkGatewayGroup 自定义资源。在 Google Distributed Cloud 1.15.0 版及更高版本的集群中，此规则由 webhook 强制执行。预先存在的浮动 IP 地址不会导致错误。Webhook 仅会阻止创建包含重复 IP 地址的新 NetworkGatewayGroups 自定义资源。 Webhook 错误消息标识了冲突的 IP 地址以及已在使用该地址的现有自定义资源： IP address exists in other gateway with name default 高级网络功能（例如出站流量 NAT 网关）的初始文档并未针对重复的 IP 地址发出警告。 最初，协调器只能识别名为 default 的 NetworkGatewayGroup 资源。Network Gateway for GDC 现在可识别系统命名空间中的所有 NetworkGatewayGroup 自定义资源。系统会遵循现有的 NetworkGatewayGroup 自定义资源。 临时解决方法： 仅在创建新的 NetworkGatewayGroup 自定义资源时发生错误。 如需解决错误，请执行以下操作： 使用以下命令列出 NetworkGatewayGroups 自定义资源： kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system -o yaml 打开现有的 NetworkGatewayGroup 自定义资源并移除任何有冲突的浮动 IP 地址 (spec.floatingIPs)： kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system RESOURCE_NAME 如需应用更改，请关闭并保存修改后的自定义资源。
VM Runtime on GDC	1.13.7	虚拟机可能无法在采用私有注册表的 1.13.7 集群上启动 在使用私有注册表的新或升级 1.13.7 版集群上启用 VM Runtime on GDC 后，连接到节点网络或使用 GPU 的虚拟机可能无法正常启动。此问题是由于 vm-system 命名空间中的某些系统 Pod 收到映像拉取错误导致的。例如，如果您的虚拟机使用节点网络，某些 Pod 可能会报告如下映像拉取错误： macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m 此问题在 1.14.0 版及更高版本的 Google Distributed Cloud 集群中已得到修复。 临时解决方法 如果您无法立即升级集群，则可以手动拉取映像。以下命令会为您的虚拟机拉取 macvtap CNI 插件映像并将其推送到您的私有注册表： docker pull \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker tag \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker push \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 将 REG_HOST 替换为您在本地镜像的主机的域名。
安装	1.11、1.12	在种类集群中创建集群期间，gke-metric-agent pod 无法启动 在种类集群中创建集群期间，由于映像拉取错误，gke-metrics-agent pod 无法启动，如下所示： error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" 此外，您将在引导集群的 containerd 日志中看到以下条目： Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" 您会在 pod 中看到以下“无法拉取”错误： gcr.io/gke-on-prem-staging/gke-metrics-agent 临时解决方法 尽管存在错误，但集群创建过程不会被屏蔽，因为种类集群中的 gke-metrics-agent pod 的目的是提高集群创建成功率以及进行内部跟踪和监控。因此，您可以忽略此错误。 临时解决方法 尽管存在错误，但集群创建过程不会被屏蔽，因为种类集群中的 gke-metrics-agent pod 的目的是提高集群创建成功率以及进行内部跟踪和监控。因此，您可以忽略此错误。
操作、网络	1.12、1.13、1.14、1.15、1.16、1.28	访问 IPv6 Service 端点时，CentOS 或 RHEL 上的 LoadBalancer 节点会崩溃 当您访问双栈 Service（同时具有 IPv4 和 IPv6 端点的 Service）并使用 IPv6 端点时，该 Service 的 LoadBalancer 节点可能会崩溃。此问题会影响使用双栈服务以及 CentOS 或 RHEL 以及内核版本低于 kernel-4.18.0-372.46.1.el8_6 的客户。 如果您认为此问题会影响您，请使用 uname -a 命令检查 LoadBalancer 节点上的内核版本。 临时解决方法： 将 LoadBalancer 节点更新为内核版本 kernel-4.18.0-372.46.1.el8_6 或更高版本。此内核版本在 CentOS 和 RHEL 8.6 及更高版本中默认可用。
网络	1.11、1.12、1.13、1.14.0	节点重新启动后出现间歇性连接问题 重启节点后，您可能会看到 NodePort 或 LoadBalancer Service 出现间歇性连接问题。例如，可能出现间歇性 TLS 握手或连接重置错误。此问题已在 1.14.1 版及更高版本的集群中得到修复。 如需检查此问题是否对您有影响，请查看运行受影响 Service 的后端 Pod 的节点上的 iptables 转发规则： sudo iptables -L FORWARD 如果您在 iptables 中的 CILIUM_FORWARD 规则之前看到 KUBE-FORWARD 规则，则您可能受到此问题的影响。以下示例输出显示了出现问题的节点： Chain FORWARD (policy ACCEPT) target prot opt source destination KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */ CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ 临时解决方法： 在配置错误的节点上重启 anetd Pod。重启 anetd Pod 后，应正确配置 iptables 中的转发规则。 以下示例输出显示 CILIUM_FORWARD 规则现在在 KUBE-FORWARD 规则之前正确配置： Chain FORWARD (policy ACCEPT) target prot opt source destination CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
升级和更新	1.9、1.10	预览版功能不会保留原始权限和所有者信息 使用 bmctl 1.9.x 的 1.9.x 集群预览版功能不会保留原始权限和所有者信息。如需验证您是否受到此功能的影响，请使用以下命令提取备份文件： tar -xzvf BACKUP_FILE 临时解决方法 验证 metadata.json 是否存在以及 bmctlVersion 是否为 1.9.x。如果 metadata.json 不存在，请升级到 1.10.x 集群并使用 bmctl 1.10.x 进行备份/恢复。
升级和创建	1.14.2	clientconfig-operator 卡在“待处理”状态，并显示“CreateContainerConfigError” 如果您已升级到或创建了使用 OIDC/LDAP 配置的 1.14.2 版集群，则可能会看到 clientconfig-operator Pod 卡在待处理状态。此问题发生时，有两个 clientconfig-operator Pod：一个处于运行状态，另一个处于待处理状态。 此问题只会出现在 1.14.2 版集群中。早期版本（例如 1.14.0 和 1.14.1）的集群不受影响。此问题已在版本 1.14.3 和所有后续版本（包括 1.15.0 及更高版本）中修复。 临时解决方法： 如需解决此问题，您可以修补 clientconfig-operator 部署以添加其他安全上下文，并确保部署已准备就绪。 使用以下命令修补目标集群中的 clientconfig-operator： kubectl patch deployment clientconfig-operator -n kube-system \ -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \ --kubeconfig CLUSTER_KUBECONFIG 请替换以下内容： CLUSTER_KUBECONFIG：目标集群的 kubeconfig 文件的路径。
操作	1.11、1.12、1.13、1.14、1.15	没有捆绑式负载均衡的集群的证书授权机构轮替失败 对于没有捆绑式负载均衡的集群（spec.loadBalancer.mode 设置为 manual）、bmctl update credentials certificate-authorities rotate 命令可能会无响应并失败，并出现以下错误：x509: certificate signed by unknown authority。 如果您受此问题影响，则 bmctl 命令可能会在输出以下消息之后变得无响应： Signing CA completed in 3/0 control-plane nodes 在这种情况下，该命令最终会失败。具有三个控制平面的集群的轮替证书授权机构日志可能包含如下所示的条目： [2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK [2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK Signing CA completed in 0/0 control-plane nodes Signing CA completed in 1/0 control-plane nodes Signing CA completed in 2/0 control-plane nodes Signing CA completed in 3/0 control-plane nodes ... Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") 临时解决方法 如需额外帮助，请与 Google 支持团队联系。
安装、网络	1.11、1.12、1.13、1.14.0-1.14.1	双栈集群中的 ipam-controller-manager 崩溃循环 部署双栈集群（同时具有 IPv4 和 IPv6 地址的集群）时，ipam-controller-manager Pod 可能会崩溃循环。此行为导致节点在 Ready 和 NotReady 状态之间循环，并可能导致集群安装失败。当 API 服务器处于高负载时，可能会发生此问题。 如需了解此问题是否对您产生影响，请检查 ipam-controller-manager Pod 是否失败并出现 CrashLoopBackOff 错误： kubectl -n kube-system get pods | grep ipam-controller-manager 以下示例输出显示了处于 CrashLoopBackOff 状态的 Pod： ipam-controller-manager-h7xb8 0/1 CrashLoopBackOff 3 (19s ago) 2m ipam-controller-manager-vzrrf 0/1 CrashLoopBackOff 3 (19s ago) 2m1s ipam-controller-manager-z8bdw 0/1 CrashLoopBackOff 3 (31s ago) 2m2s 获取处于 NotReady 状态的节点的详细信息： kubectl describe node <node-name> | grep PodCIDRs 在存在此问题的集群中，没有为节点分配 PodCIDR，如以下示例输出中所示： PodCIDRs: 在运行状况良好的集群中，所有节点都应分配有双栈 PodCIDR，如以下示例输出中所示： PodCIDRs: 192.168.6.0/24,222:333:444:555:5:4:7:0/120 临时解决方法： 重启 ipam-controller-manager Pod： kubectl -n kube-system rollout restart ds ipam-controller-manager
操作	1.6、1.7、1.8、1.9、1.10、1.11、1.12、1.13 和 1.14	etcd watch 耗尽 运行 etcd 3.4.13 或更早版本的集群可能会遇到 watch 耗尽且非操作性资源进行监控，这可能会导致以下问题： Pod 调度中断 节点无法注册 kubelet 不观察 Pod 变化 这些问题可能会导致集群无法正常运行。 此问题已在 Google Distributed Cloud 1.12.9、1.13.6、1.14.3 及后续版本中得到修复。这些较新的版本使用 etcd 3.4.21 版。所有旧版 Google Distributed Cloud 都会受此问题影响。 临时解决方法 如果您无法立即升级，则可以通过减少集群中的节点数来降低集群故障的风险。移除节点，直到 etcd_network_client_grpc_sent_bytes_total 指标小于 300 MBps。 如需在 Metrics Explorer 中查看此指标，请执行以下操作： 前往 Google Cloud 控制台中的 Metrics Explorer： 转到 Metrics Explorer 选择配置标签页。 展开选择一个指标，在过滤栏中输入 Kubernetes Container，然后使用子菜单选择该指标： 在活跃资源菜单中，选择 Kubernetes 容器。 在活跃指标类别菜单中，选择 Anthos。 在活跃指标菜单中，选择 etcd_network_client_grpc_sent_bytes_total。 点击“应用”。
网络	1.11.6、1.12.3	SR-IOV 运算符的 vfio-pci 模式“失败”状态 SriovNetworkNodeState 对象的 syncStatus 可以报告已配置节点的“失败”值。要查看节点的状态并确定问题是否对您有影响，请运行以下命令： kubectl -n gke-operators get \ sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \ -o jsonpath='{.status.syncStatus}' 将 NODE_NAME 替换为要检查的节点的名称。 临时解决方法： 如果 SriovNetworkNodeState 对象状态为“失败”，请将集群升级到 1.11.7 版或更高版本或者 1.12.4 版或更高版本。
升级和更新	1.10、1.11、1.12、1.13、1.14.0、1.14.1	某些工作器节点在升级后未处于 Ready 状态 升级完成后，某些工作器节点的 Ready 状态可能设置为 false。在 Node 资源上，您会在 Ready 状态旁边看到类似于以下示例的错误： container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized 当您登录停滞的机器时，该机器上的 CNI 配置为空： sudo ls /etc/cni/net.d/ 临时解决方法 通过删除节点的 anetd Pod 将其重启。
升级和更新、安全性	1.10	从 cert-manager 进行多次证书轮替导致不一致 多次手动或自动证书轮替后，Webhook Pod（例如 anthos-cluster-operator）未使用 cert-manager 颁发的新证书进行更新。对集群自定义资源的任何更新均失败，并导致如下所示的错误： Internal error occurred: failed calling webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "webhook-service.kube-system.svc") 在以下情况下可能会发生此问题： 您在存在时间超过 180 天的集群上对 cert-manager 颁发的证书执行了两次手动轮替，并且从未重启 anthos-cluster-operator。 您在存在时间超过 90 天的集群上对 cert-manager 颁发的证书执行了一次手动轮替，并且从未重启 anthos-cluster-operator。 临时解决方法 通过终止 anthos-cluster-operator 来重启 pod。
升级和更新	1.14.0	在用户集群升级期间创建过时的生命周期控制器部署者 Pod 在 1.14.0 版管理员集群中，可能会在用户集群升级期间创建一个或多个过时的生命周期控制器部署者 Pod。 此问题见于最初在低于 1.12 的版本上创建的用户集群。意外创建的 Pod 不会妨碍升级操作，但它们可能处于异常状态。我们建议您移除过时的 Pod。 此问题在 1.14.1 版中已得到解决。 临时解决方法： 如需移除过时的生命周期控制器部署者 Pod，请执行以下操作： 列出预检检查资源： kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A 输出类似于以下内容： NAMESPACE NAME PASS AGE cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d 其中 ci-87a021b9dcbb31c 是集群名称。 删除 PASS 列中值为 true 或 false 的资源。 例如，如需删除上述示例输出中的资源，请使用以下命令： kubectl delete preflightchecks ci-87a021b9dcbb31c \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG
网络	1.9、1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	传入路由过多导致 BGPSession 状态不断变化 当外部对等体通告大量路由（大约 100 条或更多）时，Google Distributed Cloud 高级网络无法正确管理 BGP 会话。当有大量传入路由时，节点本地 BGP 控制器需要很长时间来协调 BGP 会话，并且无法更新状态。缺少状态更新或健康检查会导致会话被删除或过时。 BGP 会话上可能出现并表明存在问题的异常行为包括： 不断删除并重新创建 bgpsession。 bgpsession.status.state 永不变为 Established 路由通告失败或反复通告和撤销。 如果与 LoadBalancer 服务的连接有问题，则可能发生了 BGP 负载均衡问题。 如果与 Pod 的连接有问题，则可能发生了 BGP FlatIP 问题。 如需确定 BGP 问题是否是由远程对等体通告过多的路由引起的，请使用以下命令查看关联的状态和输出： 对受影响的集群使用 kubectl get bgpsessions。 输出显示 bgpsessions 的状态为“Not Established”，并且上一次报告时间不断增加到约 10-12 秒，然后重置为零。 kubectl get bgpsessions 的输出显示受影响的会话正在重复重新创建： kubectl get bgpsessions \ -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}" 日志消息表明过时的 BGP 会话被删除： kubectl logs ang-controller-manager-POD_NUMBER 将 POD_NUMBER 替换为集群中的主要 Pod。 临时解决方法： 使用导出政策减少或消除从远程对等体通告到集群的路由数量。 在 Google Distributed Cloud 1.14.2 版及更高版本的集群中，您还可以使用 AddOnConfiguration 停用处理已接收路由的功能。将 --disable-received-routes 参数添加到 ang-daemon daemonset 的 bgpd 容器中。
网络	1.14、1.15、1.16、1.28	conntrack 表插入失败导致应用超时 在使用内核 5.15 或更高版本的 Ubuntu 操作系统上运行的集群容易发生 netfilter 连接跟踪 (conntrack) 表插入失败。即使 conntrack 表有空间可用于添加新条目，也可能会发生这种情况。失败是由内核 5.15 及更高版本中的更改引起的，这些更改根据链长度限制表插入。 如需查看您是否受到此问题的影响，您可以使用以下命令检查内核内连接跟踪系统统计信息： sudo conntrack -S 响应如下所示： cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0 ... 如果响应中的 chaintoolong 值为非零数字，则表示您受到此问题的影响。 临时解决方法 短期缓解措施是增加 netfiler 哈希表 (nf_conntrack_buckets) 和 netfilter 连接跟踪表 (nf_conntrack_max) 的大小。在每个集群节点上使用以下命令来增加表的大小： sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE 将 TABLE_SIZE 替换为新的大小（以字节为单位）。默认表大小值为 262144。我们建议您设置一个等于节点核心数 65,536 倍的值。例如，如果您的节点有 8 个核心，请将表大小设置为 524288。
升级和更新	1.11.3、1.11.4、1.11.5、1.11.6、1.11.7、1.11.8、1.12.4、1.12.5、1.12.6、1.12.7、1.12.8、1.13.4、1.13.5	某些版本无法使用 bmctl 恢复集群备份 我们建议您在升级之前备份集群，以便在升级失败时可以恢复之前的版本。 bmctl restore cluster 命令的问题会导致它无法恢复某些版本的集群的备份。此问题特定您要通过其恢复之前版本的备份的升级。 如果您的集群受到影响，则 bmctl restore cluster 日志包含以下错误： Error: failed to extract image paths from profile: anthos version VERSION not supported 临时解决方法： 在此问题得到解决之前，我们建议您按照备份和恢复集群中的说明手动备份集群，并在需要时手动恢复集群。
网络	1.10、1.11、1.12、1.13、1.14.0-1.14.2	当接口上没有 IP 地址时 NetworkGatewayGroup 会崩溃 NetworkGatewayGroup 无法为只有 IPv4 或 IPv6 接口的节点创建守护程序。这导致 BGP LB 和 EgressNAT 等功能失败。如果您查看 kube-system 命名空间中失败的 ang-node Pod 的日志，则缺少 IPv6 地址时，系统会显示类似于以下示例的错误： ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error": "creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""} 在上面的示例中，ens192 接口上没有 IPv6 地址。如果节点缺少 IPv4 地址，则系统会显示类似的 ARP 错误。 NetworkGatewayGroup 尝试建立与链路本地 IP 地址的 ARP 连接和 NDP 连接。如果 IP 地址不存在（IPv4 用于 ARP，IPv6 用于 NDP），则连接会失败，守护程序不会继续。 此问题在 1.14.3 版中已得到解决。 临时解决方法： 使用 SSH 连接到节点，并将 IPv4 或 IPv6 地址添加到包含节点 IP 的链路中。在上面的示例日志条目中，此接口为 ens192： ip address add dev INTERFACE scope link ADDRESS 请替换以下内容： INTERFACE：节点的接口，例如 ens192。 ADDRESS：要应用于接口的 IP 地址和子网掩码。
重置/删除	1.10、1.11、1.12、1.13.0-1.13.2	移除控制平面节点时发生 anthos-cluster-operator 崩溃循环 当您尝试通过从 Cluster.Spec 中移除 IP 地址来移除控制平面节点时，anthos-cluster-operator 进入崩溃循环状态，从而阻止任何其他操作。 临时解决方法： 此问题在 1.13.3 和 1.14.0 及更高版本中已得到解决。所有其他版本都受到影响。请升级到一个已修复的版本 如需暂时解决此问题，请运行以下命令： kubectl label baremetalmachine IP_ADDRESS \ -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply- 请替换以下内容： IP_ADDRESS：处于崩溃循环状态的节点的 IP 地址。 CLUSTER_NAMESPACE：集群命名空间。
安装	1.13.1、1.13.2 和 1.13.3	由于令牌不匹配，大型集群中的 kubeadm join 失败 安装具有大量节点的 Google Distributed Cloud 集群时，您可能会看到类似于以下示例的 kubeadmin join 错误消息： TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] *** fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join --config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1, "start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n To see the stack trace of this error execute with --v=5 or higher", "stderr_lines": ["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"", "To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight] Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]} 临时解决方法： 此问题已在 Google Distributed Cloud 1.13.4 版及更高版本中得到修复。 如果您需要使用受影响的版本，请先创建节点数少于 20 的集群，然后在安装完成后调整集群大小以添加更多节点。
日志记录和监控	1.10、1.11、1.12、1.13.0	Edge 集群中 metrics-server 的 CPU 限制低 在 Google Distributed Cloud Edge 集群中，如果 metrics-server 的 CPU 限额过低，则可能会导致 metrics-server 频繁重启。由于 metrics-server 健康状况不佳，Pod 横向自动扩缩 (HPA) 不起作用。 如果 metrics-server CPU 限制低于 40m，集群可能会受到影响。如需查看 metrics-server CPU 限制，请参阅以下文件之一： Google Distributed Cloud 1.x 至 1.12 版集群： kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml Google Distributed Cloud 1.13 版或更高版本的集群： kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml 临时解决方法： 此问题已在 Google Distributed Cloud 1.13.1 版或更高版本的集群中得到修复。如需解决此问题，请升级集群。 在升级集群之前，一种临时解决方法是手动提高 metrics-server 的 CPU 限制，如下所示： 将 metrics-server-operator 缩容： kubectl scale deploy metrics-server-operator --replicas=0 更新配置并提高 CPU 限额： Google Distributed Cloud 1.x 至 1.12 版集群： kubectl -n kube-system edit deployment metrics-server Google Distributed Cloud 1.13 版集群： kubectl -n gke-managed-metrics-server edit deployment metrics-server 移除 --config-dir=/etc/config 行并提高 CPU 限额，如以下示例所示： [...] - command: - /pod_nanny # - --config-dir=/etc/config # <--- Remove this line - --container=metrics-server - --cpu=50m # <--- Increase CPU, such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true [...] 保存并关闭 metrics-server 以应用更改。
网络	1.14、1.15、1.16	与 hostNetwork Pod 的直接 NodePort 连接不起作用 当后端 Pod 与目标 NodePort 位于同一节点上时，与通过 NodePort Service 启用了 hostNetwork 的 Pod 的连接会失败。当 LoadBalancer Service 与启用了 hostNetwork 的 Pod 一起使用时，此问题会影响 LoadBalancer Service。使用多个后端时，可能会发生偶发的连接失败。 此问题是由 eBPF 程序中的 bug 引起的。 临时解决方法： 使用 Nodeport Service 时，请勿以运行任何后端 Pod 的节点为目标。使用 LoadBalancer Service 时，请确保启用了 hostNetwork 的 Pod 不在 LoadBalancer 节点上运行。
升级和更新	1.12.3、1.13.0	1.13.0 版管理员集群无法管理 1.12.3 版用户集群 运行 1.13.0 版的管理员集群无法管理运行 1.12.3 版的用户集群。针对 1.12.3 版用户集群的操作失败。 临时解决方法： 将管理员集群升级到 1.13.1 版，或将用户集群升级到与管理员集群相同的版本。
升级和更新	1.12	具有工作器节点池的管理员集群在升级到 1.13.x 时遭阻止 1.13.0 版和更高版本的管理员集群不能包含工作器节点池。 使用工作器节点池的管理员集群升级到 1.13.0 或更高版本会被阻止。如果您的管理员集群升级停滞，您可以通过检查 bmctl-workspace 文件夹内的 upgrade-cluster.log 文件中的以下错误来确认工作器节点池是否是导致问题的原因： Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed. 临时解决方法： 在升级之前，请将所有工作器节点池移动到用户集群。如需了解如何添加和移除节点池，请参阅管理集群中的节点池。
升级和更新	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	使用 kubectl apply 更新资源时出错 如果您使用 kubectl apply 更新现有资源（例如 ClientConfig 或 Stackdriver 自定义资源），则控制器可能会返回错误或还原您的输入和计划的更改。 例如，您可以尝试按照以下方式修改 Stackdriver 自定义资源，即先获取资源，然后应用更新后的版本： 获取现有 YAML 定义： kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml 在 YAML 文件中启用功能或更新配置。 重新应用更新后的 YAML 文件： kubectl apply -f stackdriver.yaml 在 kubectl apply 的最后一步中您可能会遇到问题。 临时解决方法： 请勿使用 kubectl apply 更改现有资源。请改用 kubectl edit 或 kubectl patch，如以下示例所示： 修改 Stackdriver 自定义资源： kubectl edit stackdriver -n kube-system stackdriver 在 YAML 文件中启用功能或更新配置。 保存并退出编辑器 使用 kubectl patch 的替代方法： 获取现有 YAML 定义： kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml 在 YAML 文件中启用功能或更新配置。 重新应用更新后的 YAML 文件： kubectl patch stackdriver stackdriver --type merge \ -n kube-system --patch-file stackdriver.yaml
日志记录和监控	1.12、1.13、1.14、1.15、1.16	损坏的积压数据块导致 stackdriver-log-forwarder 崩溃循环 如果 stackdriver-log-forwarder 尝试处理损坏的积压数据块，则会发生崩溃循环。容器日志中会显示以下示例错误： [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks 发生此崩溃循环时，您无法在 Cloud Logging 中查看日志。 临时解决方法： 如需解决这些错误，请完成以下步骤： 确定损坏的积压数据块。查看以下示例错误消息： [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks 在此示例中，存储在 var/log/fluent-bit-buffers/tail.1/ 中的文件 tail.1/1-1659339894.252926599.flb 出现错误。必须移除每个未能通过格式检查的 *.flb 文件。 结束 stackdriver-log-forwarder 的正在运行的 Pod： kubectl --kubeconfig KUBECONFIG -n kube-system \ patch daemonset stackdriver-log-forwarder \ -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' 将 KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。 在继续下一步之前，先验证 stackdriver-log-forwarder Pod 是否已删除。 使用运行 stackdriver-log-forwarder 的 SSH 连接到节点。 在该节点上，删除 var/log/fluent-bit-buffers/tail.1/ 中所有损坏的 *.flb 文件。 如果有太多损坏的文件，并且您希望应用一个脚本来清理所有积压数据块，请使用以下脚本： 部署一个 DaemonSet 以清理 fluent-bit 的缓冲区中的所有脏数据： kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF 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 EOF 确保 DaemonSet 已清理所有节点。以下两个命令的输出应等于集群中的节点数： kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l 删除清理 DaemonSet： kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup 重启 stackdriver-log-forwarder Pod： kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
网络、VM Runtime on GDC	1.14.0	在集群上重启 Dataplane V2 (anetd) 可能会导致现有虚拟机无法连接到非 Pod 网络 在多 NIC 集群上，重启 Dataplane V2 (anetd) 可能会导致虚拟机无法连接到网络。在 anetd Pod 日志中可能会观察到类似于以下内容的错误： could not find an allocator to allocate the IP of the multi-nic endpoint 临时解决方法： 您可以重启虚拟机以快速解决问题。为避免问题再次发生，请将集群升级到 1.14.1 版或更高版本。
操作	1.13、1.14.0、1.14.1	gke-metrics-agent 在边缘配置文件集群上没有内存限制 根据集群的工作负载，gke-metrics-agent 可能会使用大于 4608 MiB 的内存。此问题仅影响 Google Distributed Cloud Edge 配置文件集群。默认配置文件集群不受影响。 临时解决方法： 将集群升级到 1.14.2 版或更高版本。
安装	1.12、1.13	集群创建可能会因竞态条件而失败 在使用 kubectl 创建集群时，由于竞态条件，预检检查可能无法完成。因此，在某些情况下集群创建可能会失败。 预检检查协调器会创建 SecretForwarder 以将默认 ssh-key Secret 复制到目标命名空间。 通常，预检检查会利用所有者引用，并在 SecretForwarder 完成后进行协调。但在极少数情况下，SecretForwarder 的所有者引用可能会丢失对预检检查的引用，导致预检检查卡住。因此，集群创建会失败。为了继续进行控制器驱动的预检检查协调，请删除 cluster-operator pod 或删除 preflight-check 资源。当您删除 preflight-check 资源时，它会再创建一个资源并继续协调。或者，您可以将使用较早版本创建的现有集群升级到已修复的版本。
网络	1.9、1.10、1.11、1.12、1.13、1.14、1.15	将 whereabouts 插件与多 NIC 功能搭配使用时，不会释放预留的 IP 地址 在多 NIC 功能中，如果您使用的是 CNI whereabouts 插件，并且使用 CNI DEL 操作删除 Pod 的网络接口，则某些预留的 IP 地址可能无法正确释放。当 CNI DEL 操作中断时，会发生这种情况。 您可以通过运行以下命令来验证 Pod 未使用的 IP 地址预留： kubectl get ippools -A --kubeconfig KUBECONFIG_PATH 临时解决方法： 手动删除未使用的 IP 地址 (ippool)。
安装	1.10、1.11.0、1.11.1、1.11.2	1.10.4 用户集群中发生 Node Problem Detector 故障 如果 1.11.0、1.11.1 或 1.11.2 版管理员集群管理 1.10.x 版用户集群，1.10.x 版用户集群中可能会发生 Node Problem Detector 故障。Node Problem Detector 发生故障时，日志会更新，并显示以下错误消息： Error - NPD not supported for anthos baremetal version 1.10.4: anthos version 1.10.4 not supported. 临时解决方法 将管理员集群升级到 1.11.3 可解决此问题。
操作	1.14	1.14 孤岛模式 IPv4 集群节点的 pod CIDR 掩码大小为 24 在 1.14 版中，maxPodsPerNode 设置未考虑孤岛模式集群，因此为节点分配的 pod CIDR 掩码大小为 24（256 个 IP 地址）。这可能导致集群提前耗尽 pod IP 地址。例如，如果集群的 pod CIDR 掩码大小为 22；为每个节点分配的 pod CIDR 掩码大小为 24，该集群最多只能支持 4 个节点。当 maxPodsPerNode 设置为 129 或更高，并且每个节点的 pod CIDR 中没有足够的开销时，您的集群可能还会在高 pod 流失期间遇到网络不稳定问题。 此问题仅会影响使用的 maxPodsPerNode 超出范围 65 到 128 的孤岛模式 IPv4 集群。 如果您的集群受到影响，则在向集群添加新节点时，anetd pod 会报告以下错误，并且没有可用的 podCIDR： error="required IPv4 PodCIDR not available" 临时解决方法 请按照以下步骤解决此问题： 升级到 1.14.1 或更高版本。 移除工作器节点，然后重新添加。 移除控制平面节点，然后重新添加（最好逐个添加），以避免集群停机。
升级和更新	1.14.0、1.14.1	集群升级回滚失败 对于 1.14.0 或 1.14.1 版集群，升级回滚可能会失败。如果您将集群从 1.14.0 升级到 1.14.1，然后尝试使用 bmctl restore cluster 命令回滚到 1.14.0，则可能会返回如以下示例所示的错误： I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff. Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io" denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid: Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690), Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil), CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable 临时解决方法： 删除集群命名空间下的所有 healthchecks.baremetal.cluster.gke.io 资源，然后重新运行 bmctl restore cluster 命令： 列出所有 healthchecks.baremetal.cluster.gke.io 资源： kubectl get healthchecks.baremetal.cluster.gke.io \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 替换以下内容： CLUSTER_NAMESPACE：集群的命名空间。 ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。 删除上一步中列出的所有 healthchecks.baremetal.cluster.gke.io 资源： kubectl delete healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_RESOURCE_NAME \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 将 HEALTHCHECK_RESOURCE_NAME 替换为健康检查资源的名称。 重新运行 bmctl restore cluster 命令。
网络	1.12.0	Service 外部 IP 地址在平面模式下不起作用 在 flatIPv4 设置为 true 的集群中，无法通过外部 IP 地址访问 LoadBalancer 类型的 Service。 此问题在 1.12.1 版中已得到解决。 临时解决方法： 在 cilium-config ConfigMap 中，将 enable-415 设置为 "true"，然后重启 anetd Pod。
升级和更新	1.13.0、1.14	从 1.13.0 到 1.14.x 的就地升级始终无法完成 尝试使用 bmctl 1.14.0 和 --use-bootstrap=false 标志执行从 1.13.0 到 1.14.x 的就地升级时，升级始终无法完成。 preflight-check 运算符错误会导致集群始终不安排必要的检查，这意味着预检检查永远无法完成。 临时解决方法： 先升级到 1.13.1，然后再升级到 1.14.x。从 1.13.0 到 1.13.1 的就地升级应该正常。或者，不使用 --use-bootstrap=false 标志进行从 1.13.0 到 1.14.x 的升级。
升级和更新、安全性	1.13 和 1.14	升级到 1.14.0 的集群会丢失主污点 控制平面节点需要两个特定污点之一，以防止工作负载 pod 被调度到其上。将 1.13 版 GKE 集群升级到 1.14.0 版时，控制平面节点会丢失以下必需的污点： node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/master:PreferNoSchedule 注意：自行管理集群（例如独立类型集群）默认使用 PreferNoSchedule 污点。 此问题不会导致升级失败，但不应在控制平面节点上运行的 Pod 可能会遇到此问题。这些工作负载 Pod 会使控制平面节点过载，进而导致集群不稳定。 确定您是否受到影响 使用以下命令查找控制平面节点： kubectl get node -l 'node-role.kubernetes.io/control-plane' \ -o name --kubeconfig KUBECONFIG_PATH 如需检查节点上的污点列表，请使用以下命令： kubectl describe node NODE_NAME \ --kubeconfig KUBECONFIG_PATH 如果所需污点均未列出，则您将会受到影响。 临时解决方法 对受影响的 1.14.0 版集群的每个控制平面节点执行以下步骤，以使其恢复正常运行。这些步骤适用于 node-role.kubernetes.io/master:NoSchedule 污点和相关 pod。如果您打算让控制平面节点使用 PreferNoSchedule 污点，请相应地调整步骤。 查看临时解决方法步骤 应用缺少的污点： kubectl taint nodes NODE_NAME \ node-role.kubernetes.io/master:NoSchedule \ -–kubeconfig KUBECONFIG_PATH 查找未使用 node-role.kubernetes.io/master:NoSchedule 容忍设置的 pod： kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \ -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \ --kubeconfig KUBECONFIG_PATH | \ grep -v "node-role.kubernetes.io/master" | uniq 删除没有 node-role.kubernetes.io/master:NoSchedule 容忍设置的 pod： kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
操作、VM Runtime on GDC	1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29	虚拟机创建间歇性失败并报告上传错误 使用 kubectl virt create vm 命令创建新的虚拟机 (VM) 会在映像上传期间失败。此问题同时适用于 Linux 和 Windows 虚拟机。该错误如以下示例所示： PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready Uploading data to https://10.200.0.51 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s fail to upload image: unexpected return value 500, ... 临时解决方法 重试 kubectl virt create vm 命令以创建虚拟机。
升级和更新、日志记录和监控	1.11	升级到 1.12 版时，1.11 版集群中的代管式集合组件未保留 代管式集合组件是 Managed Service for Prometheus 的一部分。如果您在 1.11 版集群的 gmp-system 命名空间中手动部署了代管式集合组件，则升级到 1.12 版时关联的资源不会保留。 从 1.12.0 版集群开始，gmp-system 命名空间中的 Managed Service for Prometheus 组件和相关的自定义资源定义由 stackdriver-operator 通过 enableGMPForApplications 字段进行管理。enableGMPForApplications 字段默认为 true，因此，如果您在升级到 1.12 版之前，在命名空间中手动部署了 Managed Service for Prometheus 组件，这些资源会被 stackdriver-operator 删除。 临时解决方法 如需保留手动管理的集合资源，请执行以下操作： 备份所有现有的 PodMonitoring 自定义资源。 将集群升级到 1.12 版并启用 Managed Service for Prometheus。 在升级后的集群上重新部署 PodMonitoring 自定义资源。
升级和更新	1.13	某些使用 Docker 容器运行时的 1.12 版集群无法升级到 1.13 版 如果使用 Docker 容器运行时的 1.12 版集群缺少以下注解，则该集群无法升级到 1.13 版： baremetal.cluster.gke.io/allow-docker-container-runtime: "true" 如果您受到此问题的影响，则 bmctl 会在 bmctl-workspace 文件夹内的 upgrade-cluster.log 文件中写入以下错误： Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook "vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources. Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file. 这在从 1.11 版本升级的 1.12 版 Docker 集群中最有可能发生，因为该升级不需要注解来维护 Docker 容器运行时。在这种情况下，集群在升级到 1.13 时没有注解。请注意，从 1.13 版开始，containerd 是唯一允许的容器运行时。 临时解决方法： 如果您受到此问题的影响，请使用缺少的注解更新集群资源。您可以在升级运行时或取消之后、重试升级之前添加注解。
安装	1.11	bmctl 在集群创建完成之前退出 对于 Google Distributed Cloud 1.11.0 版，集群创建可能会失败（此问题已在 Google Distributed Cloud 1.11.1 版中得到修复）。在某些情况下，bmctl create cluster 命令会提前退出，并将如下错误写入日志： Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster 临时解决方法 失败的操作会生成工件，但集群无法运行。如果此问题影响您，请按照以下步骤清理工件并创建集群： 查看临时解决方法步骤 如需删除集群工件并重置节点机器，请运行以下命令： bmctl reset -c USER_CLUSTER_NAME 如需启动集群创建操作，请运行以下命令： bmctl create cluster -c USER_CLUSTER_NAME \ --keep-bootstrap-cluster 如果此命令失败，则 --keep-bootstrap-cluster 标志非常重要。如果集群创建命令成功，则您可以跳过其余步骤。否则请继续。 运行以下命令以获取引导集群的版本： kubectl get cluster USER_CLUSTER_NAME \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig bmctl-workspace/.kindkubeconfig \ -o=jsonpath='{.status.anthosBareMetalVersion} 输出应为 1.11.0。如果输出不是 1.11.0，请等待一两分钟，然后重试。 如需手动将资源从引导集群移动到目标集群，请运行以下命令： bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \ --to-kubeconfig \ bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \ -n USER_CLUSTER_NAMESPACE 如需删除引导集群，请运行以下命令： bmctl reset bootstrap
安装、VM Runtime on GDC	1.11、1.12	安装报告虚拟机运行时协调错误 集群创建操作可能会报告类似于以下内容的错误： I0423 01:17:20.895640 3935589 logs.go:82] "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError" 临时解决方法 此错误是良性的，您可以放心地忽略它。
安装	1.10、1.11、1.12	使用多 NIC、containerd 和 HTTPS 代理时集群创建失败 当您的情况满足以下条件组合时，集群创建失败： 集群配置为使用 containerd 作为容器运行时（在集群配置文件中，nodeConfig.containerRuntime 设置为 containerd，这是 Google Distributed Cloud 1.13 版及更高版本的默认设置）。 集群配置为可为 pod 提供多个网络接口、多 NIC（在集群配置文件中，clusterNetwork.multipleNetworkInterfaces 设置为 true）。 集群已配置为使用代理（在集群配置文件中指定了 spec.proxy.url）。即使集群创建失败，此设置也会在您尝试创建集群时传播。您可能会在 HTTPS_PROXY 环境变量或 containerd 配置 (/etc/systemd/system/containerd.service.d/09-proxy.conf) 中看到此代理设置。 临时解决方法 将服务 CIDR (clusterNetwork.services.cidrBlocks) 附加到所有节点机器上的 NO_PROXY 环境变量。
安装	1.10、1.11、1.12	umask 设置受限的系统失败 Google Distributed Cloud 1.10.0 版引入了无根控制平面功能，该功能以非根用户身份运行所有控制平面组件。以非根用户身份运行所有组件可能会导致在 umask 设置更严格 (0077) 的系统上安装或升级失败。 临时解决方法 重置控制平面节点，并将所有控制平面机器上的 umask 设置更改为 0022。请在这些机器更新后重新尝试安装。 或者，您可以更改控制平面机器上 /etc/kubernetes 的目录和文件权限，以继续进行安装或升级。 将 /etc/kubernetes 及其所有子目录均设为全局可读：chmod o+rx。 （以递归方式）将目录 /etc/kubernetes 下 root 用户拥有的所有文件设为全局可读 (chmod o+r)。从这些更改中排除私钥文件 (.key)，因为它们已使用正确的所有权和权限创建完毕。 将 /usr/local/etc/haproxy/haproxy.cfg 设为全局可读。 将 /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml 设为全局可读。
安装	1.10、1.11、1.12、1.13	对照组 v2 不兼容 Google Distributed Cloud 1.13 版及更低版本的集群不支持对照组 v2 (cgroup v2)。但 1.14 版支持 cgroup v2 作为预览版功能。如果存在 /sys/fs/cgroup/cgroup.controllers，则表示系统使用的是 cgroup v2。 临时解决方法 如果您的系统使用 cgroup v2，请将集群升级到 1.14 版。
安装	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29	预检检查和服务账号凭据 对于由管理员集群或混合集群触发的安装（也就是不使用 bmctl 创建的集群，例如用户集群），预检检查不会验证 Google Cloud 服务账号凭据或其相关权限。
安装	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29	在 vSphere 上安装 在 vSphere 虚拟机上安装 Google Distributed Cloud 集群时，必须将 tx-udp_tnl-segmentation 和 tx-udp_tnl-csum-segmentation 标志设置为关闭。这些标志与 vSphere 驱动程序 VMXNET3 完成的硬件细分分流相关，它们不适用于 Google Distributed Cloud 集群的 GENEVE 隧道。 临时解决方法 在每个节点上运行以下命令，以检查这些标志的当前值： ethtool -k NET_INTFC | grep segm 将 NET_INTFC 替换为与节点的 IP 地址关联的网络接口。 响应应具有如下所示的条目： ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... 有时，在 RHEL 8.4 中，ethtool 显示这些标志为关闭，但其实并未关闭。如需将这些标志明确设置为关闭，请使用以下命令将其设置为开启，然后设置为关闭： ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \ tx-udp_tnl-csum-segmentation on ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \ tx-udp_tnl-csum-segmentation off 此标志更改在重新启动后不会保留。配置启动脚本，以便在系统启动时明确设置这些标志。
升级和更新	1.10	bmctl 无法创建、更新或重置较低版本的用户集群 无论管理员集群版本如何，bmctl CLI 都无法创建、更新或重置具有较低次要版本的用户集群。例如，您不能使用 bmctl 和 1.N.X 版本来重置用户集群 1.N-1.Y 版本，即使管理员集群的版本同样为 1.N.X。 如果您受到此问题的影响，则在使用 bmctl 时应该看到类似于以下内容的日志： [2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: * cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported 临时解决方法： 使用 kubectl 在管理员集群内创建、修改或删除用户集群自定义资源。 升级用户集群的能力不受影响。
升级和更新	1.12	集群升级到 1.12.1 版时可能会停滞 将集群升级到 1.12.1 版时，有时会由于 API 服务器变为不可用导致升级过程停滞。此问题会影响所有集群类型和所有受支持的操作系统。出现此问题时，bmctl upgrade cluster 命令可能会发生多点失败，包括在预检检查的第二阶段。 临时解决方法 您可以检查升级日志以确定您是否受此问题影响。升级日志默认位于 /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP 中。 upgrade-cluster.log 可能包含如下错误： Failed to upgrade cluster: preflight checks failed: preflight check failed 机器日志可能包含如下错误（反复的操作失败表示您受此问题影响）： FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left). FAILED - RETRYING: Query CNI health endpoint (28 retries left). ... 确保 HAProxy 和 Keepalived 在每个控制平面节点上运行，然后重新尝试将集群升级到 1.12.1 版。在每个节点上使用 crictl 命令行界面检查 haproxy 和 keepalived 容器是否正在运行： docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived 如果 HAProxy 或 Keepalived 未在某个节点上运行，请在该节点上重启 kubelet： systemctl restart kubelet
升级和更新、VM Runtime on GDC	1.11、1.12	启用 VM Runtime on GDC 后，无法将集群升级到 1.12.0 版或更高版本 在 1.12.0 版 Google Distributed Cloud 集群中，与 VM Runtime on GDC 相关的所有资源都会迁移到 vm-system 命名空间，以更好地支持正式版 VM Runtime on GDC。如果您在 1.11.x 版或更低版本的集群中启用了 VM Runtime on GDC，则升级到 1.12.0 版或更高版本会失败，除非您首先停用 VM Runtime on GDC。如果您遇到此问题，升级操作会报告以下错误： Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to 1.12.0 and higher version 临时解决方法 如需停用 VM Runtime on GDC，请执行以下操作： 修改 VMRuntime 自定义资源： kubectl edit vmruntime 将规范中的 enabled 设置为 false： apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... 在编辑器中保存自定义资源。 集群升级完成后，重新启用 VM Runtime on GDC。 如需了解详情，请参阅使用基于虚拟机的工作负载。
升级和更新	1.10、1.11、1.12	error during manifests operations，导致升级卡住 在某些情况下，集群升级无法完成，并且 bmctl CLI 没有响应。此问题可能是由错误更新的资源引起的。如需确定您是否受此问题影响并纠正此问题，请检查 anthos-cluster-operator 日志并查找类似于以下条目的错误： controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update 这些条目是错误更新资源的问题，其中 {RESOURCE_NAME} 是问题资源的名称。 临时解决方法 如果您在日志中找到这些错误，请完成以下步骤： 使用 kubectl edit 从日志消息中包含的资源中移除 kubectl.kubernetes.io/last-applied-configuration 注释。 保存更改并将更改应用于资源。 重试集群升级。
升级和更新	1.10、1.11、1.12	含有使用 Network Gateway for GDC 的功能的集群禁止升级 对于使用出站流量 NAT 网关或使用 BGP 的捆绑式负载均衡的集群，集群从 1.10.x 升级到 1.11.x 会失败。这些功能均使用 Network Gateway for GDC。集群升级过程卡在 Waiting for upgrade to complete... 命令行消息处，anthos-cluster-operator 会记录如下错误： apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable... 临时解决方法 注意：以下解决方法会删除清单，并会导致使用 BGP 的捆绑式负载均衡短暂停机 30–60 秒。在此期间，BGP 会话将被丢弃然后重新建立，并且 LoadBalancer 服务在此期间不可用。当 anthos-cluster-operator 重新安装清单时，系统会恢复该功能。 如需取消升级，请对正在升级的集群运行以下命令： kubectl -n kube-system delete deployment \ ang-controller-manager-autoscaler kubectl -n kube-system delete deployment \ ang-controller-manager kubectl -n kube-system delete ds ang-node
升级和更新	1.10、1.11、1.12、1.13、1.14、1.15	bmctl update 无法移除维护块 bmctl update 命令无法在集群资源配置中移除或修改 maintenanceBlocks 部分。 临时解决方法 如需了解详情（包括从维护模式中移除节点的说明），请参阅将节点置于维护模式。
操作	1.10、1.11、1.12	如果您不使用维护模式过程，节点会取消封锁 如果您运行 1.12.0 版 (anthosBareMetalVersion: 1.12.0) 或更低版本的集群，并在节点上手动使用 kubectl cordon，则 Google Distributed Cloud 可能会在您准备协调预期状态之前取消封锁节点。 临时解决方法 对于 1.12.0 版及更低版本的集群，请使用维护模式安全地封锁和排空节点。 在 1.12.1 版 (anthosBareMetalVersion: 1.12.1) 或更高版本中，Google Distributed Cloud 不会在您使用 kubectl cordon 时意外取消封锁节点。
操作	1.11	使用注册表镜像的 11 版管理员集群无法管理 1.10 版集群 如果您的管理员集群使用 1.11 版并使用注册表镜像，则它无法管理使用更低次要版本的用户集群。此问题会影响用户集群上的重置、更新和升级操作。 如需确定此问题是否对您有影响，请检查集群操作（例如创建、升级或重置）的日志。这些日志默认位于 bmctl-workspace/CLUSTER_NAME/ 文件夹中。如果您遇到此问题，您的日志中会包含以下错误消息： flag provided but not defined: -registry-mirror-host-to-endpoints
操作	1.10、1.11	kubeconfig Secret 被覆盖 在用户集群上运行时，bmctl check cluster 命令会使用管理员集群 kubeconfig 覆盖用户集群 kubeconfig Secret。覆盖该文件会导致受影响的用户集群的标准集群操作（例如更新和升级）失败。此问题会影响 Google Distributed Cloud 1.11.1 版及更早版本的集群。 如需确定此问题是否影响用户集群，请运行以下命令： kubectl --kubeconfig ADMIN_KUBECONFIG \ get secret -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME -kubeconfig \ -o json | jq -r '.data.value' | base64 -d 请替换以下内容： ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。 USER_CLUSTER_NAMESPACE：集群的命名空间。默认情况下，Google Distributed Cloud 集群的集群命名空间是以 cluster- 开头的集群名称。例如，如果您将集群命名为 test，则默认命名空间为 cluster-test。 USER_CLUSTER_NAME：要检查的用户集群的名称。 如果输出中的集群名称（请参阅以下示例输出中的 contexts.context.cluster）是管理员集群名称，则指定的用户集群会受到影响。 apiVersion: v1 clusters: - cluster: certificate-authority-data:LS0tLS1CRU...UtLS0tLQo= server: https://10.200.0.6:443 name: ci-aed78cdeca81874 contexts: - context: cluster: ci-aed78cdeca81 user: ci-aed78cdeca81-admin name: ci-aed78cdeca81-admin@ci-aed78cdeca81 current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81 kind: Config preferences: {} users: - name: ci-aed78cdeca81-admin user: client-certificate-data: LS0tLS1CRU...UtLS0tLQo= client-key-data: LS0tLS1CRU...0tLS0tCg== 临时解决方法 以下步骤会恢复受影响的用户集群 (USER_CLUSTER_NAME) 的功能： 找到用户集群 kubeconfig 文件。当您创建集群时，Google Distributed Cloud 会在管理员工作站上生成 kubeconfig 文件。默认情况下，该文件位于 bmctl-workspace/USER_CLUSTER_NAME 目录中。 验证该 kubeconfig 是正确的用户集群 kubeconfig： kubectl get nodes \ --kubeconfig PATH_TO_GENERATED_FILE 将 PATH_TO_GENERATED_FILE 替换为用户集群 kubeconfig 文件的路径。响应会返回用户集群的节点的详细信息。确认集群的机器名称正确无误。 运行以下命令以删除管理员集群中的损坏的 kubeconfig 文件： kubectl delete secret \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig 运行以下命令，将正确的 kubeconfig Secret 保存回管理员集群： kubectl create secret generic \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig \ --from-file=value=PATH_TO_GENERATED_FILE
操作	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29	以非根用户身份截取快照 如果您使用 containerd 作为容器运行时，则以非根用户身份运行快照要求 /usr/local/bin 位于用户的 PATH 中。 否则，操作将失败并显示 crictl: command not found 错误。 如果您未以根用户身份登录，则使用 sudo 运行快照命令。sudo PATH 可能与根配置文件不同，并且不得包含 /usr/local/bin。 临时解决方法 更新 /etc/sudoers 中的 secure_path 以包含 /usr/local/bin。或者，在另一个 /bin 目录中为 crictl 创建符号链接。
日志记录和监控	1.10	stackdriver-log-forwarder 有 [parser:cri] invalid time format 个警告日志 如果容器运行时接口 (CRI) 解析器使用不正确的正则表达式来解析时间，则 stackdriver-log-forwarder Pod 的日志将包含如下错误和警告： [2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z' 临时解决方法： 查看临时解决方法步骤 将集群升级到 1.11.0 版或更高版本。 如果您无法立即升级集群，请按照以下步骤操作以更新 CRI 解析正则表达式： 为防止后续更改还原，请缩减 stackdriver-operator： kubectl --kubeconfig KUBECONFIG \ -n kube-system scale deploy \ stackdriver-operator --replicas=0 修改 stackdriver-log-forwarder-config ConfigMap 中的 Regex 条目： kubectl --kubeconfig KUBECONFIG \ -n kube-system edit configmap \ stackdriver-log-forwarder-config 修改后的资源应类似于以下内容： [PARSER] # https://rubular.com/r/Vn30bO78GlkvyB Name cri Format regex # The timestamp is described in https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9] {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9] {2}:[0-9]{2})) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z Time_Keep off 重启日志转发器 pod： kubectl --kubeconfig KUBECONFIG \ -n kube-system rollout restart daemonset \ stackdriver-log-forwarder
日志记录和监控	1.10、1.11、1.12、1.13、1.14、1.15	监控费用异常 对于 Google Distributed Cloud 1.10 至 1.15 版集群，一些客户会发现结算页面上的 Metrics volume 费用超出预期。只有在同时满足以下所有条件时，此问题才会对您产生影响： 已启用应用监控功能 (enableStackdriverForApplications=true) 未启用 Managed Service for Prometheus (enableGMPForApplications) 应用 Pod 具有 prometheus.io/scrap=true 注解 如需确认您是否受此问题影响，请列出您的用户定义的指标。如果您看到针对不需要的指标的计费，则表示此问题适用于您。 临时解决方法 如果您受此问题影响，我们建议您将集群升级到 1.12 版，并切换到可解决此问题的新应用监控解决方案 managed-service-for-prometheus： 使用单独的标志来控制应用日志与应用指标的收集 已捆绑 Google Cloud Managed Service for Prometheus 如果您无法升级到 1.12 版，请按以下步骤操作： 找到具有不必要的计费的来源 Pod 和 Service： kubectl --kubeconfig KUBECONFIG \ get pods -A -o yaml | grep 'prometheus.io/scrape: "true"' kubectl --kubeconfig KUBECONFIG get \ services -A -o yaml | grep 'prometheus.io/scrape: "true"' 从 Pod 或 Service 中移除 prometheus.io/scrap=true 注解。
日志记录和监控	1.11、1.12、1.13、1.14、1.15、1.16、1.28	对 metrics-server-config 的修改不会保留 在极端情况下，高 pod 密度可能会造成过多的日志记录和监控开销，导致 Metrics Server 停止并重启。您可以修改 metrics-server-config ConfigMap 以分配更多资源来维持 Metrics Server 的运行。但由于协调，对 metrics-server-config 进行的修改可能会在集群更新或升级操作期间还原为默认值。 Metrics Server 不会立即受到影响，但下次重启时，它会提取还原的 ConfigMap，从而再次容易受到过度开销的影响。 临时解决方法 对于 1.11.x，您可以编写 ConfigMap 修改脚本并将其与集群更新或升级一起执行。对于 1.12 及更高版本，请与支持团队联系。
日志记录和监控	1.11、1.12	影响 Cloud Monitoring 信息中心的已弃用指标 多个 GKE on Bare Metal 指标已被弃用，并且从 Google Distributed Cloud 1.11 版开始，不再为这些已弃用的指标收集数据。如果您在任何提醒政策中使用这些指标，则没有任何数据会触发提醒条件。 下表列出了已弃用的单个指标以及用于替换这些指标的指标。 已弃用的指标 替换指标 kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled kube_node_status_allocatable_cpu_cores kube_node_status_allocatable_memory_bytes kube_node_status_allocatable_pods kube_node_status_allocatable kube_node_status_capacity_cpu_cores kube_node_status_capacity_memory_bytes kube_node_status_capacity_pods kube_node_status_capacity 在 1.11 版之前的 Google Distributed Cloud 集群中，推荐的 Anthos on baremetal node cpu usage exceeds 80 percent (critical) 提醒的政策定义文件会使用已弃用的指标。node-cpu-usage-high.json JSON 定义文件在 1.11.0 版及更高版本中进行了更新。 临时解决方法 按照以下步骤迁移到替换指标： 在 Google Cloud 控制台中，选择 Monitoring 或点击以下按钮： 转到 Monitoring 在导航窗格中，选择 信息中心，然后删除 Anthos 集群节点状态信息中心。 点击示例库标签页并重新安装 Anthos 集群节点状态信息中心。 按照创建提醒政策中的说明，使用更新后的 node-cpu-usage-high.json 政策定义文件创建政策。
日志记录和监控	1.10、1.11	stackdriver-log-forwarder 有 CrashloopBackOff 错误 在某些情况下，fluent-bit 日志记录代理可能会卡在处理损坏的区块。当日志记录代理无法绕过损坏的区块时，您可能会发现 stackdriver-log-forwarder 持续崩溃并显示 CrashloopBackOff 错误。如果遇到此问题，日志条目将如下所示： [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5 in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232 #1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523 #2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105 #3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490 #4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0 临时解决方法： 清理 Stackdriver Log Forwarder 的缓冲区区块。 注意：在以下命令中，将 KUBECONFIG 替换为管理员集群 kubeconfig 文件的路径。 终止所有 stackdriver-log-forwarder pod： kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \ stackdriver-log-forwarder -p \ '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' 在继续下一步之前，先验证 stackdriver-log-forwarder pod 是否已删除。 部署以下 DaemonSet 以清理 fluent-bit 缓冲区中的任何损坏数据： kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF 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 EOF 使用以下命令验证 DaemonSet 已清理所有节点： kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l \ app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG -n \ kube-system get pods -l \ app=fluent-bit-cleanup --no-headers | wc -l 这两条命令的输出应等于集群中的节点数。 删除清理 DaemonSet： kubectl --kubeconfig KUBECONFIG -n \ kube-system delete ds fluent-bit-cleanup 重启日志转发器 pod： kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset \ stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
日志记录和监控	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	gke-metrics-agent 日志中显示未知指标错误 gke-metrics-agent 是一个 DaemonSet，用于收集每个节点上的指标并将其转发到 Cloud Monitoring。它可能会生成如下日志： Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile 其他指标类型可能会发生类似的错误，包括但不限于： apiserver_admission_step_admission_duration_seconds_summary go_gc_duration_seconds scheduler_scheduling_duration_seconds gkeconnect_http_request_duration_seconds_summary alertmanager_nflog_snapshot_duration_seconds_summary 您可以放心地忽略这些错误日志，因为它们引用的指标不受支持，并且对监控用途不大。
日志记录和监控	1.10、1.11	间歇性指标导出中断 Google Distributed Cloud 集群可能会在正常持续导出指标或某些节点上缺少指标时发生中断问题。如果此问题影响到您的集群，您可能会看到以下指标存在数据缺口（至少）： 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.11.1 或更高版本。 如果您无法升级，请执行以下步骤来解决此问题： 打开 stackdriver 资源进行修改： kubectl -n 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: baremetal 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 -n kube-system get daemonset \ gke-metrics-agent -o yaml | grep "cpu: 50m" 如果修改生效，则该命令会查找 cpu: 50m。
网络	1.10	多个默认网关中断与外部端点的连接 节点中存在多个默认网关可能会导致从 Pod 内部中断与外部端点（如 google.com）的连接。 如需确定您是否受此问题影响，请在节点上运行以下命令： ip route show 响应中的多个 default 实例表示您受到影响。
网络	1.12	用户集群上的网络自定义资源修改被覆盖 1.12.x 版 Google Distributed Cloud 集群不会阻止您手动修改用户集群中的网络自定义资源。Google Distributed Cloud 会在集群升级期间协调用户集群中的自定义资源与管理员集群中的自定义资源。这种协调会覆盖直接对用户集群中的网络自定义资源所做的任何修改。网络自定义资源应仅在管理员集群中修改，但 1.12.x 版集群不强制执行此要求。 高级网络功能（例如使用 BGP 进行捆绑式负载均衡、出站流量 NAT 网关、SR-IOV 网络、使用 BGP 实现平面模式和 Pod 的多 NIC 使用以下自定义资源： BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode 您可以在管理员集群中修改这些自定义资源，并且协调步骤会将更改应用于用户集群。 临时解决方法 如果您修改了用户集群上之前提到的任何自定义资源，请修改管理员集群上相应的自定义资源使两者匹配，然后再升级。此步骤可确保您的配置更改得以保留。Google Distributed Cloud 1.13.0 版及更高版本的集群会阻止您直接修改用户集群中的网络自定义资源。
网络	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	Pod 连接失败和反向路径过滤 Google Distributed Cloud 会在节点上配置反向路径过滤以停用来源验证 (net.ipv4.conf.all.rp_filter=0)。如果 rp_filter 设置被更改为 1 或 2，则 Pod 会因节点外通信超时而失败。 反向路径过滤是使用 IPv4 配置文件夹 (net/ipv4/conf/all) 中的 rp_filter 文件设置的。此值也可能被 sysctl 替换，后者会将反向路径过滤设置存储在网络安全配置文件（例如 /etc/sysctl.d/60-gce-network-security.conf）中。 临时解决方法 您可以通过执行以下任一解决方法来恢复 Pod 连接： 手动将 net.ipv4.conf.all.rp_filter 的值设置回 0，然后运行 sudo sysctl -p 以应用更改。 或 重启 anetd Pod 以将 net.ipv4.conf.all.rp_filter 设置回 0。如需重启 anetd Pod，请使用以下命令找到并删除 anetd Pod，之后系统会在该位置启动一个新的 anetd Pod 来取代被删除的 Pod： kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ 将 ANETD_XYZ 替换为 anetd Pod 的名称。 执行任一解决方法后，在每个节点上运行 sysctl net.ipv4.conf.all.rp_filter，以验证 net.ipv4.conf.all.rp_filter 值是否设为了 0。
网络	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29	引导（种类）集群 IP 地址和集群节点 IP 地址重叠 192.168.122.0/24 和 10.96.0.0/27 是引导（种类）集群使用的默认 pod 和服务 CIDR。如果这些地址与集群节点机器 IP 地址重叠，预检检查将失败。 临时解决方法 为避免冲突，您可以将 --bootstrap-cluster-pod-cidr 和 --bootstrap-cluster-service-cidr 标志传递给 bmctl 以指定不同的值。
操作系统	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	在 CentOS 上创建或升级集群失败 2020 年 12 月，CentOS 社区和 Red Hat 宣布了 CentOS 停用。2022 年 1 月 31 日，CentOS 8 已达到服务终止 (EOL) 期限。由于服务终止 (EOL)，yum 代码库不再适用于 CentOS，从而导致集群创建和集群升级操作失败。这适用于所有受支持的 CentOS 版本，并会影响 Google Distributed Cloud 集群的所有版本。 临时解决方法 查看临时解决方法步骤 如需解决此问题，请运行以下命令，让 CentOS 使用归档 Feed： sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-* sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-* 作为长期解决方案，请考虑迁移到其他受支持的操作系统。
安全性	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	容器无法向 Dockerfile 中定义的采用了 Containerd 和 SELinux 的 VOLUME 写入数据 如果您使用 containerd 作为容器运行时，并且您的操作系统启用了 SELinux，则应用 Dockerfile 中定义的 VOLUME 可能无法写入。例如，使用以下 Dockerfile 构建的容器无法写入 /tmp 文件夹。 FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp 如需验证您是否受此问题影响，请在托管有问题的容器的节点上运行以下命令： ausearch -m avc 如果您受此问题影响，则会看到如下 denied 错误： time->Mon Apr 4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc: denied { write } for pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0 临时解决方法 如需解决此问题，请执行以下任一更改： 关闭 SELinux。 不在 Dockerfile 中使用 VOLUME 功能。
升级和更新	1.10、1.11、1.12	集群升级后默认不启用 Node Problem Detector 升级 Google Distributed Cloud 集群后，默认不会启用 Node Problem Detector。此问题存在于版本 1.10 到 1.12.1 的升级，并且已在版本 1.12.2 中修复。 临时解决方法： 如需启用 Node Problem Detector，请执行以下操作： 验证 node-problem-detector systemd 服务是否正在节点上运行。 使用 SSH 命令并连接到节点。 检查 node-problem-detector systemd 服务是否正在节点上运行： systemctl is-active node-problem-detector 如果命令结果显示 inactive，则 node-problem-detector 未在节点上运行。 如需启用 Node Problem Detector，请使用 kubectl edit 命令并修改 node-problem-detector-config ConfigMap。如需了解详情，请参阅 Node Problem Detector。
操作	1.9、1.10	使用非根用户身份登录时集群备份失败 如果 nodeAccess.loginUser 设置为非根用户名，则 bmctl backup cluster 命令会失败。] 临时解决方法： 此问题会出现在 1.9.x、1.10.0 和 1.10.1 版中，并已在 1.10.2 版及更高版本中得到修复。
网络	1.10、1.11、1.12	负载均衡器服务无法与控制平面主机网络上的容器搭配使用 anetd 中存在一个错误，如果后端 Pod 同时在控制平面节点上运行并使用容器规范中的 hostNetwork: true 字段，则 LoadBalancer Service 的数据包会被丢弃。 1.13 版或更高版本中不存在此错误。 临时解决方法： 如果您使用由 hostNetwork Pod 支持的 LoadBalancer Service，以下解决方法会有帮助： 在工作器节点（而非控制平面节点）上运行它们 在 Service 规范中使用 externalTrafficPolicy: local，并确保您的工作负载在负载均衡器节点上运行
升级和更新	1.12、1.13	孤立的 anthos-version-$version$ pod 无法拉取映像 从 1.12.x 升级到 1.13.x 的集群可能会观察到出现 ImagePullBackOff 错误的 anthos-version-$version$ pod。 这是由于 anthos-cluster-operator 的竞态条件升级而造成的，它不会影响任何常规集群功能。 1.13 版或更高版本中不存在此错误。 临时解决方法： 通过 kubectl delete job anthos-version-$version$ -n kube-system 删除 dynamic-version-installer 的作业
升级和更新	1.13	从 1.11 升级的 1.12 集群无法升级到 1.13.0 从 1.11 版升级的 1.12 版集群无法升级到 1.13.0 版。此升级问题不影响 1.12 版中创建的集群。 如需确定您是否受到影响，请检查管理员集群中包含 upgrade-first-no* 字符串的升级作业的日志。如果您看到以下错误消息，则表明您受到影响。 TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] ******* ... [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name. ... 临时解决方法： 如需解决此问题，请执行以下操作： 在管理员工作站上运行以下命令： echo '[{ "op": "remove", "path": \ "/spec/clusterConfiguration/featureGates" }]' \ > remove-feature-gates.patch export KUBECONFIG=$ADMIN_KUBECONFIG kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \ 'kubectl patch kubeadmconfig $1 -n $0 --type json \ --patch-file remove-feature-gates.patch' 重试集群升级。
日志和监控	1.16.2、1.16.3	stackdriver-operator 的 CPU 使用率高 stackdriver-operator 中有一个问题会导致它耗用比正常情况更长的 CPU 时间。正常情况下，stackdriver-operator 处于空闲状态时，CPU 使用率会低于 50 milliCPU (50m)。出现该问题是因为 stackdriver-operator 应用的证书资源与 cert-manager 预期的证书资源不匹配。这种不匹配导致 cert-manager 和 stackdriver-operator 在更新这些资源时产生竞态条件。 此问题可能会导致 CPU 可用性受限的集群性能下降。 临时解决方法： 在可以升级到修复了此错误的版本之前，请先使用以下临时解决方法： 应用 AddonConfiguration 自定义资源，将 stackdriver-operator 暂时缩减到 0 个副本： kubectl scale deploy stackdriver-operator --replicas=0 待升级到可修复此问题的版本之后，可重新扩容 stackdriver-operator： kubectl scale deploy stackdriver-operator --replicas=1
日志和监控	1.16.0、1.16.1	基于注解的指标爬取不起作用 在 Google Distributed Cloud 1.16 次要版本中，stackdriver 自定义资源规范中的 enableStackdriverForApplications 字段已被弃用。此字段被 Stackdriver 自定义资源中的两个字段 enableCloudLoggingForApplications 和 enableGMPForApplications 取代。 我们建议您使用 Google Cloud Managed Service for Prometheus 来监控工作负载。可使用 enableGMPForApplications 字段启用此功能。 如果您的工作负载依赖于由 prometheus.io/scrape 注解触发的指标收集，您可以使用 annotationBasedApplicationMetrics 特性门控标志来保留这一旧行为。但是，有一个问题会导致 annotationBasedApplicationMetrics 无法正常工作，从而阻止将指标从应用收集到 Cloud Monitoring。 临时解决方法： 如需解决此问题，请将集群升级到 1.16.2 版或更高版本。 通过 annotationBasedApplicationMetrics 特性门控启用的基于注解的工作负载指标收集功能会针对具有 prometheus.io/scrape 注解的对象收集指标。许多开源软件系统可能会使用此注解。如果您继续使用该指标收集方法，请注意对象之间的依赖关系，以免对 Cloud Monitoring 中产生的指标费用感到意外。

如果您需要其他帮助，请与 Cloud Customer Care 联系。