这些错误表示逐出事件或由于节点资源而无法调度 Pod。由于 Anthos Network Gateway Pod 没有 PriorityClass，因此它们具有与其他工作负载相同的默认优先级。当节点资源受限时，网络网关 Pod 可能会被逐出。此行为对于 ang-node DaemonSet 尤为糟糕，因为这些 Pod 必须在特定节点上调度，并且不能迁移。
临时解决方法：
升级到 1.15 或更高版本。
作为短期修复，您可以手动为 Anthos Network Gateway 组件分配 PriorityClass。Anthos clusters on Bare Metal 控制器会在协调过程中（例如在集群升级期间）覆盖这些手动更改。
...
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]
[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
此问题在 Anthos clusters on Bare Metal 1.14.2 及更高版本中已得到修复。
Anthos Network Gateway 不允许您创建新的 NetworkGatewayGroup 自定义资源，其中包含 spec.floatingIPs 中已在现有 NetworkGatewayGroup 自定义资源中使用的 IP 地址。此规则由 Anthos clusters on Bare Metal 1.15.0 及更高版本中的 Webhook 强制执行。预先存在的浮动 IP 地址不会导致错误。Webhook 仅会阻止创建包含重复 IP 地址的新 NetworkGatewayGroups 自定义资源。
Webhook 错误消息标识了冲突的 IP 地址以及已在使用该地址的现有自定义资源：
IP address exists in other gateway with name default
在使用私有注册表的新或升级 1.13.7 版集群上启用 Anthos VM Runtime 时，连接到节点网络或使用 GPU 的虚拟机可能无法正常启动。此问题是由于 vm-system 命名空间中的某些系统 Pod 收到映像拉取错误导致的。例如，如果您的虚拟机使用节点网络，某些 Pod 可能会报告如下映像拉取错误：
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
此问题在 Anthos clusters on Bare Metal 1.14.0 及更高版本中已得到修复。
在种类集群中创建集群期间，由于映像拉取错误，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
访问 IPv6 Service 端点时，CentOS 或 RHEL 上的 LoadBalancer 节点会崩溃
[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")
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")
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
在大量节点上安装 Anthos Clusters on Bare Metal 时，您可能会看到类似于以下示例的 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"]}
临时解决方法：
此问题已在 Anthos Clusters on Bare Metal 1.13.4 版及更高版本中解决。
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
[...] Increase 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
与 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 节点上运行。
在多 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 故障
当 Anthos Clusters on Bare Metal 1.11.0、1.11.1 或 1.11.2 管理员集群管理 1.10.x 用户集群时，Anthos Clusters on Bare Metal 用户集群 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 流失期间遇到网络不稳定问题。
如果您的集群受到影响，则在向集群添加新节点时，anetd pod 会报告以下错误，并且没有可用的 podCIDR：
error="required IPv4 PodCIDR not available"
临时解决方法
请按照以下步骤解决此问题：
升级到 1.14.1 或更高版本。
移除工作器节点，然后重新添加。
移除控制平面节点，然后重新添加（最好逐个添加），以避免集群停机。
升级和更新
1.14.0、1.14.1
集群升级回滚失败
Anthos Clusters on Bare Metal 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
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
操作，Anthos 虚拟机运行时
1.11、1.12、1.13、1.14、1.15
虚拟机创建间歇性失败并报告上传错误
使用 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 的一部分。如果您在 Anthos 集群 1.11 版的 gmp-system 命名空间中手动部署了代管式集合组件，则升级到 1.12 版时关联的资源不会保留。
从 Anthos Clusters on Bare Metal 1.12.0 版开始，gmp-system 命名空间中的 Managed Service for Prometheus 组件和相关的自定义资源定义由 stackdriver-operator 使用 enableGMPForApplications 字段进行管理。enableGMPForApplications 字段默认为 true，因此，如果您在升级到 1.12 版之前，在命名空间中手动部署了 Managed Service for Prometheus 组件，这些资源会被 stackdriver-operator 删除。
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.
在集群节点机器上，如果 PATH 环境变量中存在 Docker 可执行文件，但 Docker 服务未处于活动状态，则预检检查将失败并报告 Docker service
is not active。
临时解决方法
移除 Docker，或启用 Docker 服务。
安装
1.10、1.11、1.12、1.13、1.14、1.15
在 vSphere 上安装
在 vSphere 虚拟机上安装 Anthos Clusters on Bare Metal 时，必须将 tx-udp_tnl-segmentation 和 tx-udp_tnl-csum-segmentation 标志设置为关闭。这些标志与 vSphere 驱动程序 VMXNET3 完成的硬件细分分流相关，它们不适用于 Anthos Clusters on Bare Metal 的 GENEVE 隧道。
临时解决方法
在每个节点上运行以下命令，以检查这些标志的当前值：
ethtool -k NET_INTFC | grep segm
将 NET_INTFC 替换为与节点的 IP 地址关联的网络接口。
响应应具有如下所示的条目：
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
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
[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 is not 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 命令可能会发生多点失败，包括在预检检查的第二阶段。
在 Anthos Clusters on Bare Metal 1.12.0 版中，与 Anthos 虚拟机运行时相关的所有资源都会迁移到 vm-system 命名空间，以更好地支持 Anthos 虚拟机运行时正式版。如果您在 1.11.x 版或更低版本的集群中启用了 Anthos 虚拟机运行时，则升级到 1.12.0 版或更高版本会失败，除非您首先停用 Anthos 虚拟机运行时。如果您遇到此问题，升级操作会报告以下错误：
Failed to upgrade cluster: cluster is not 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
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
如果节点从 Anthos Clusters on Bare Metal 无法访问，则节点的排空过程不会启动。例如，如果某个节点在集群升级过程中离线，可能会导致升级停止响应。这种情况很少见。
临时解决方法
为了最大限度地降低遇到此问题的可能性，请确保您的节点在启动升级之前正常运行。
升级和更新
1.12
containerd 1.5.13 需要 libseccomp 2.5 版或更高版本
Anthos Clusters on Bare Metal 1.12.1 版随附 1.5.13 版 containerd，此版本的 containerd 需要 libseccomp 2.5 版或更高版本。
如果您的系统未安装 libseccomp 2.5 版或更高版本，请先对其进行更新，然后再将现有集群升级到 1.12.1 版。否则，您可能会在负载均衡器节点中看到 cplb-update Pod 错误，如下所示：
runc did not terminate successfully: runc: symbol lookup error: runc: undefined
symbol: seccomp_notify_respond
临时解决方法
如需在 Ubuntu 中安装最新版本的 libseccomp，请运行以下命令：
sudo apt-get install libseccomp-dev
如需在 CentOS 或 RHEL 中安装最新版本的 libseccomp，请运行以下命令：
sudo dnf -y install libseccomp-devel
操作
1.10、1.11、1.12
如果您不使用维护模式过程，节点会取消封锁
如果您运行 Anthos Clusters on Bare Metal 版本 1.12.0 (anthosBareMetalVersion: 1.12.0) 或更低版本，并在节点上手动使用 kubectl cordon，则 Anthos Clusters on Bare Metal 可能会在您准备协调预期状态之前取消封锁节点。
临时解决方法
对于 Anthos Clusters on Bare Metal 1.12.0 及更低版本，请使用维护模式安全地封锁和排空节点。
在 1.12.1 版 (anthosBareMetalVersion: 1.12.1) 或更高版本中，Anthos Clusters on Bare Metal 不会在您使用 kubectl cordon 时意外取消封锁节点。
flag provided but not defined: -registry-mirror-host-to-endpoints
操作
1.10、1.11
kubeconfig Secret 被覆盖
在用户集群上运行时，bmctl check cluster 命令会使用管理员集群 kubeconfig 覆盖用户集群 kubeconfig Secret。覆盖该文件会导致受影响的用户集群的标准集群操作（例如更新和升级）失败。此问题影响 Anthos Clusters on Bare Metal 1.11.1 及更早版本。
Anthos 虚拟机运行时 - 重启 Pod 会导致 Pod 上的虚拟机更改 IP 地址或完全丢失其 IP 地址。
如果虚拟机的 IP 地址发生变化，这不会影响作为 Kubernetes 服务公开的虚拟机应用的可达性。
临时解决方法
如果 IP 地址丢失，您必须从虚拟机运行 dhclient 以获取虚拟机的 IP 地址。
日志记录和监控
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'
临时解决方法：
查看临时解决方法步骤
将 Anthos Clusters on Bare Metal 升级到 1.11.0 版或更高版本。
[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
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
对 metrics-server-config 的修改不会保留
在极端情况下，高 Pod 密度可能会造成过多的日志记录和监控开销，导致 Metrics Server 停止并重启。您可以修改 metrics-server-config ConfigMap 以分配更多资源来维持 Metrics Server 的运行。但由于协调，对 metrics-server-config 进行的修改可能会在集群更新或升级操作期间还原为默认值。Metrics Server 不会立即受到影响，但下次重启时，它会提取还原的 ConfigMap，从而再次容易受到过度开销的影响。
在 1.11 版之前的 Anthos Clusters on Bare Metal 版本中，推荐的 Anthos on baremetal node cpu usage exceeds
80 percent (critical) 提醒的政策定义文件使用已弃用的指标。node-cpu-usage-high.json JSON 定义文件在 1.11.0 版及更高版本中进行了更新。
临时解决方法
按照以下步骤迁移到替换指标：
在 Google Cloud 控制台中，选择 Monitoring 或点击以下按钮： 转到 Monitoring
[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
Anthos Clusters on Bare Metal 1.12.x 版不会阻止您手动修改用户集群中的网络自定义资源。Anthos Clusters on Bare Metal 会在集群升级期间协调用户集群中的自定义资源与管理员集群中的自定义资源。这种协调会覆盖直接对用户集群中的网络自定义资源所做的任何修改。网络自定义资源应仅在管理员集群中修改，但 Anthos Clusters on Bare Metal 1.12.x 版不强制执行此要求。
如果您修改了用户集群上之前提到的任何自定义资源，请修改管理员集群上相应的自定义资源使两者匹配，然后再升级。此步骤可确保您的配置更改得以保留。Anthos Clusters on Bare Metal 1.13.0 版及更高版本会阻止您直接修改用户集群中的网络自定义资源。
网络
1.11、1.12、1.13、1.14、1.15
并行连接过多导致 NAT 失败
对于集群中的给定节点，节点 IP 地址为路由到集群外部地址的数据包提供网络地址转换 (NAT)。同样，当入站数据包进入配置为使用捆绑式负载均衡 (spec.loadBalancer.mode:
bundled) 的负载均衡节点时，来源网络地址转换 (SNAT) 会将数据包路由到节点 IP 地址，然后数据包才被转发到后端 Pod。
Anthos Clusters on Bare Metal 使用的 NAT 端口范围为 32768–65535。此范围将该节点上每个协议的并行连接数限制为 32,767。每个连接都需要在 conntrack 表中有一个条目。如果短期有效的连接过多，conntrack 表的 NAT 端口会用尽。垃圾回收器会清理过时的条目，但清理不是即时的。
将外部流量政策设置为 Local 可能会导致捆绑式第 2 层负载均衡的路由错误，如 No route to
host。外部流量政策默认设置为 Cluster (externalTrafficPolicy:
Cluster)。使用此设置时，Kubernetes 会处理集群范围的流量。LoadBalancer 或 NodePort 类型的服务可以使用 externalTrafficPolicy: Local 保留客户端来源 IP 地址。但是，使用此设置时，Kubernetes 仅处理节点本地流量。
临时解决方法
如果要保留客户端来源 IP 地址，则可能需要其他配置，以确保服务 IP 地址可供访问。如需了解配置详情，请参阅“配置捆绑式负载均衡”中的保留客户端来源 IP 地址。
网络
1.10、1.11、1.12、1.13、1.14、1.15
修改 firewalld 会清除 Cilium iptable 政策链
运行在 CentOS 或 Red Hat Enterprise Linux (RHEL) 上启用了 firewalld 的 Anthos Clusters on Bare Metal 时，更改 firewalld 可能会清除主机网络上的 Cilium iptables 链。anetd Pod 在启动时会添加 iptables 链。丢失 Cilium iptables 链会导致节点上的 Pod 丢失节点外部的网络连接。
Anthos Clusters on Bare Metal 1.11.0 版和 1.11.1 版与 GA 内核（从 4.15.0-144-generic 到 4.15.0-176-generic）上的 Ubuntu 18.04.6 不兼容。这种不兼容会导致网络代理无法配置集群网络，并且 anetd 日志中会出现“BPF 程序过大”错误。您可能会在 pod 事件日志中看到 pod 卡在 ContainerCreating 状态，并显示 networkPlugin cni failed to set up pod 错误。此问题不适用于 Ubuntu 硬件启用 (HWE) 内核。
2020 年 12 月，CentOS 社区和 Red Hat 宣布了 CentOS 停用。2022 年 1 月 31 日，CentOS 8 已达到服务终止 (EOL) 期限。由于服务终止 (EOL)，yum 代码库不再适用于 CentOS，从而导致集群创建和集群升级操作失败。这适用于所有受支持的 CentOS 版本，并影响所有 Anthos Clusters on Bare Metal 版本。
临时解决方法
查看临时解决方法步骤
如需解决此问题，请运行以下命令，让 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-*
如需验证 SELinux 是否是 pod 创建失败的原因，请使用以下命令检查 kubelet 日志中的错误：
journalctl -u kubelet
如果 SELinux 导致 pod 创建失败，则命令响应中会包含如下错误：
error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied
如需验证此问题与 SELinux 强制执行相关，请运行以下命令：
ausearch -m avc
此命令会在审核日志中搜索访问矢量缓存 (AVC) 权限错误。以下示例响应中的 avc: denied 确认 pod 创建失败与 SELinux 强制执行相关。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2023-07-26。"],[],[]]
信息中心，然后删除 Anthos 集群节点状态信息中心。