配置
控制层面和负载均衡器规范
控制层面和负载均衡器节点池规范很特别。这些规范声明和控制关键集群资源。这些资源的规范来源是它们在集群配置文件中的相应部分：
spec.controlPlane.nodePoolSpecspec.LoadBalancer.nodePoolSpec
因此，请勿直接修改顶层控制层面和负载均衡器节点池资源。请改为修改集群配置文件中的相关部分。
安装
使用多 NIC、containerd 和 HTTP 代理时集群创建失败
当您的情况满足以下条件组合时，集群创建失败：
集群配置为使用
containerd作为容器运行时（在集群配置文件中，nodeConfig.containerRuntime设置为containerd，这是 Anthos clusters on Bare Metal 1.9 版中的默认设置）。集群配置为可为 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 环境变量。
未指定的 containerRuntime 不默认为 containerd
在 Anthos clusters on Bare Metal 1.9.0 版中，containerRuntime 默认值在生成的集群配置文件中从 docker 更新为 containerd。如果 containerRuntime 字段未设置或从集群配置文件中移除，则在创建集群时将 containerRuntime 设置为 docker。containerRuntime 值应默认为 containerd，除非将它明确设置为 docker。此问题仅适用于版本 1.9.0 和 1.9.1。
如需确定您的集群正在使用的容器运行时，请按照检索集群信息中的步骤操作。查看 cluster.spec.nodeConfig 部分中的 containerRuntime 值。
更改容器运行时的唯一方法是升级集群。如需了解详情，请参阅更改容器运行时。
此问题在 Anthos clusters on Bare Metal 1.9.2 版中已得到解决。
对照组 v2 不兼容
Anthos clusters on Bare Metal 1.9 不支持对照组 v2 (cgroup v2)。如果存在 /sys/fs/cgroup/cgroup.controllers，则表示系统使用的是 cgroup v2。
预检检查会确认 cgroup v2 是在集群机器上使用。
安装期间的良性错误消息
检查集群创建日志时，您可能会看到有关注册集群或调用网络钩子的暂时性故障。您可以放心地忽略这些错误，因为安装过程将重试这些操作，直到操作成功。
预检检查和服务帐号凭据
对于由管理员集群或混合集群触发的安装（也就是不使用 bmctl 创建的集群，例如用户集群），预检检查不会验证 Google Cloud Platform 服务帐号凭据或其相关权限。
预检检查和权限遭拒
在安装过程中，您可能会看到有关 /bin/sh: /tmp/disks_check.sh: Permission denied 的错误。这些错误消息是由于使用 noexec 选项装载 /tmp 所致。要使 bmctl 正常运行，您需要从 /tmp 装载点中移除 noexec 选项。
应用默认凭据和 bmctl
bmctl 使用应用默认凭据 (ADC) 验证集群操作在 cluster spec 中的位置值（如果未设置为 global）。
要使 ADC 正常运行，您需要将 GOOGLE_APPLICATION_CREDENTIALS 环境变量指向服务帐号凭据文件，或运行 gcloud auth application-default login。
Docker 服务
在集群节点机器上，如果 PATH 环境变量中存在 Docker 可执行文件，但 Docker 服务未处于活动状态，则预检检查将失败并报告 Docker service is not active。如需修复此错误，请移除 Docker 或启用 Docker 服务。
在 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
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
... 将 NET_INTFC 替换为与节点的 IP 地址关联的网络接口。
有时，在 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
此标志更改在重新启动后不会保留。配置启动脚本，以便在系统启动时明确设置这些标志。
升级和更新
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.8 版集群的升级失败
如果有任何节点机器先前已处于维护模式，则尝试将 1.8.x 版集群升级到 1.9.x 版会失败。这是由于这些节点上仍然存在注解。
如需确定您是否受到此问题的影响，请按照以下步骤操作：
通过运行以下命令获取您要升级的集群版本：
kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME \ -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"如果返回的版本值适用于 1.8 次要版本（例如
1.8.3），则继续执行操作。否则，此问题不适合您的情况。通过运行以下命令，检查集群是否具有任何先前已处于维护模式的节点：
kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE \ --output=jsonpath="{.items[*].metadata.annotations}"如果返回的注解包含
baremetal.cluster.gke.io/maintenance-mode-duration，则表示您受到这一已知问题的影响。
如需允许集群升级，请为每个受影响的节点机器运行以下命令，以移除 baremetal.cluster.gke.io/maintenance-mode-duration 注解：
kubectl --kubeconfig ADMIN_KUBECONFIG annotate BareMetalMachine -n CLUSTER_NAMESPACE \
NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-
bmctl update 无法移除维护块
bmctl update 命令无法在集群资源配置中移除或修改 maintenanceBlocks 部分。如需了解详情（包括从维护模式中移除节点的说明），请参阅将节点置于维护模式。
用户集群补丁程序升级限制
由管理员集群管理的用户集群必须位于相同的 Anthos clusters on Bare Metal 版本或更低版本中，并且必须是一个次要版本。例如，可以管理 1.8.4 版用户集群的 1.9.0 版 (anthosBareMetalVersion: 1.9.0) 管理员集群。
当管理员集群使用的发布版本之后发布补丁时，升级限制会阻止您将用户集群升级到新的安全补丁。例如，如果您的管理员集群的版本为 1.7.2，该版本于 2021 年 6 月 2 日发布，则您无法将您的用户集群升级到 1.6.4 版，因为该版本于 2021 年 8 月 13 日发布。
节点无法覆盖时，无法启动节点排空功能
如果节点从 Anthos clusters on Bare Metal 无法访问，则节点的排空过程不会启动。例如，如果某个节点在集群升级过程中离线，可能会导致升级停止响应。这种情况很少见。为了最大限度地降低遇到此问题的可能性，请确保您的节点在启动升级之前正常运行。
操作
kubeconfig Secret 被覆盖
在用户集群上运行时，bmctl check cluster 命令会使用管理员集群 kubeconfig 覆盖用户集群 kubeconfig Secret。覆盖该文件会导致受影响的用户集群的标准集群操作（例如更新和升级）失败。此问题影响 Anthos clusters on Bare Metal 1.11.1 及更早版本。
要确定用户集群是否受到此问题的影响，请运行以下命令：
kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
USER_CLUSTER_NAME -kubeconfig -o json | jq -r '.data.value' | base64 -d
替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。USER_CLUSTER_NAME：要检查的用户集群的名称。
如果输出中的集群名称（请参阅以下示例输出中的 contexts.context.cluster）是管理员集群名称，则指定的用户集群会受到影响。
user-cluster-kubeconfig -o json | jq -r '.data.value' | base64 -d
apiVersion: v1
clusters:
- cluster:
certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
server: https://10.200.0.6:443
name: ci-aed78cdeca81874
contexts:
- context:
cluster: ci-aed78cdeca81874
user: ci-aed78cdeca81874-admin
name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
user:
client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
client-key-data: LS0tLS1CRU...0tLS0tCg==
以下步骤会恢复受影响的用户集群 (USER_CLUSTER_NAME) 的功能：
找到用户集群 kubeconfig 文件。
创建集群时，Anthos clusters on Bare Metal 会在管理员工作站上生成 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
以非根用户身份截取快照
如果您使用 containerd 作为容器运行时，则以非根用户身份运行快照要求 /usr/local/bin 位于用户的 PATH 中。否则，操作将失败并显示 crictl: command not found 错误。
如果您未以根用户身份登录，则使用 sudo 运行快照命令。sudo PATH 可能与根配置文件不同，并且不得包含 /usr/local/bin。
您可以通过将 /etc/sudoers 中的 secure_path 更新为包含 /usr/local/bin 来解决此错误。或者，在另一个 /bin 目录中为 crictl 创建符号链接。
Anthos 虚拟机运行时
重启 pod 会导致 pod 上的虚拟机更改 IP 地址或完全丢失其 IP 地址。如果虚拟机的 IP 地址发生变化，这不会影响作为 Kubernetes 服务公开的虚拟机应用的可达性。如果 IP 地址丢失，您必须从虚拟机运行 dhclient 以获取虚拟机的 IP 地址。
日志记录和监控
网络中断后日志缺失
在某些情况下，当您的集群从网络中断中恢复时，您可能会发现新日志未出现在 Cloud Logging 中。您可能还会在 stackdriver-log-forwarder 的日志中看到如下多条消息：
re-schedule retry=0x7fef2acbd8d0 239 in the next 51 seconds
如需重新激活日志转发，请重启 stackdriver-log-forwarder Pod。如果日志转发器在中断发生后的 4.5 小时内重启，则缓冲的日志将被转发到 Cloud Logging。超过 4.5 小时的日志会被丢弃。
间歇性指标导出中断
Anthos clusters on Bare Metal 1.9.x 和 1.10.x 版可能会在正常持续导出指标或某些节点上缺少指标时遇到中断。如果此问题影响到您的集群，您可能会看到以下指标存在数据缺口（至少）：
kubernetes.io/anthos/container_memory_working_set_byteskubernetes.io/anthos/container_cpu_usage_seconds_totalkubernetes.io/anthos/container_network_receive_bytes_total
如需解决此问题，请将集群升级到 1.10.3 版或更高版本。
如果您无法升级，请执行以下步骤来解决此问题：
打开
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。为防止后续更改还原，请缩减
stackdriver-operator：kubectl -n kube-system scale deploy stackdriver-operator --replicas=0打开
gke-metrics-agent-conf进行修改：kubectl -n kube-system edit configmap gke-metrics-agent-conf修改配置以将
probe_interval: 0.1s的所有实例都更改为probe_interval: 13s：183 processors: 184 disk_buffer/metrics: 185 backend_endpoint: https://monitoring.googleapis.com:443 186 buffer_dir: /metrics-data/nsq-metrics-metrics 187 probe_interval: 13s 188 retention_size_mib: 6144 189 disk_buffer/self: 190 backend_endpoint: https://monitoring.googleapis.com:443 191 buffer_dir: /metrics-data/nsq-metrics-self 192 probe_interval: 13s 193 retention_size_mib: 200 194 disk_buffer/uptime: 195 backend_endpoint: https://monitoring.googleapis.com:443 196 buffer_dir: /metrics-data/nsq-metrics-uptime 197 probe_interval: 13s 198 retention_size_mib: 200保存更改并关闭文本编辑器。
重启
gke-metrics-agent守护进程集：kubectl -n kube-system rollout restart daemonset gke-metrics-agent
安全
集群 CA 轮替（预览版功能）
升级期间，集群 CA/证书将轮替。按需轮替支持是预览版功能。
Anthos clusters on Bare Metal 自动轮替 kubelet 服务证书。当证书快要过期时，每个 kubelet 节点代理都可以发出证书签名请求 (CSR)。管理员集群中的控制器会验证并批准 CSR。
对集群执行用户集群证书授权机构 (CA) 轮替后，所有用户身份验证流程都将失败。之所以发生这种情况，是因为在 CA 轮替期间，身份验证流程中使用的 ClientConfig 自定义资源不会使用新 CA 数据进行更新。如果您已在集群上执行集群 CA 轮替，请检查 kube-public 命名空间的 default ClientConfig 中的 certificateAuthorityData 字段是否包含旧版集群 CA。
如需手动解决此问题，请使用当前集群 CA 更新 certificateAuthorityData 字段。
创建 pod 期间的 SELinux 错误
当 SELinux 阻止容器运行时在 tmpfs 装载上设置标签时，Pod 创建有时会失败。这种故障很少见，但当 SELinux 处于 Enforcing 模式和某些内核时可能会发生这种情况。
如需验证 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 强制执行相关。
type=AVC msg=audit(1627410995.808:9534): avc: denied { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0
使用 SELinux 创建此 pod 问题的根本原因是在以下 Linux 映像中发现一个内核错误：
- 8.3 之前的 Red Hat Enterprise Linux (RHEL) 版本
- 8.3 之前的 CentOS 版本
重新启动机器有助于从问题中恢复。
为防止 Pod 创建错误发生，请使用 RHEL 8.3 或更高版本，或 CentOS 8.3 或更高版本，因为这些版本已修复内核错误。
网络
具有捆绑式第 2 层负载均衡的客户端来源 IP 地址
将外部流量政策设置为 Local 可能会导致捆绑式第 2 层负载均衡的路由错误，如 No route to host。外部流量政策默认设置为 Cluster (externalTrafficPolicy: Cluster)。使用此设置时，Kubernetes 会处理集群范围的流量。LoadBalancer 或 NodePort 类型的服务可以使用 externalTrafficPolicy: Local 保留客户端来源 IP 地址。但是，使用此设置时，Kubernetes 仅处理节点本地流量。
如果要保留客户端来源 IP 地址，则可能需要其他配置，以确保服务 IP 地址可供访问。如需了解配置详情，请参阅“配置捆绑式负载均衡”中的保留客户端来源 IP 地址。
修改 firewalld 会清除 Cilium iptable 政策链
运行在 CentOS 或 Red Hat Enterprise Linux (RHEL) 上启用了 firewalld 的 Anthos clusters on Bare Metal 时，更改 firewalld 可能会清除主机网络上的 Cilium iptables 链。anetd Pod 在启动时会添加 iptables 链。丢失 Cilium iptables 链会导致节点上的 Pod 丢失节点外部的网络连接。
会导致清除 iptables 链的 firewalld 更改包括但不限于：
- 使用
systemctl重启firewalld - 使用命令行客户端 (
firewall-cmd --reload) 重新加载firewalld
您可以通过在节点上重启 anetd 来修复此连接问题。使用以下命令找到并删除 anetd Pod，以重启 anetd：
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
将 ANETD_XYZ 替换为 anetd Pod 的名称。
egressSourceIP 地址重复
使用出口 NAT 网关功能预览时，可以设置流量选择规则，指定已用于另一个 EgressNATPolicy 对象的 egressSourceIP 地址。这可能会导致出站流量路由冲突。在您的 EgressNATPolicy 自定义资源中指定 egressSourceIP 地址之前，请与您的开发团队协调以确定哪些浮动 IP 地址可供使用。
由于 I/O 超时和反向路径过滤而导致的 Pod 连接失败
Anthos clusters on Bare Metal 在节点上配置反向路径过滤以停用源验证 (net.ipv4.conf.all.rp_filter=0)。如果 rp_filter 设置更改为 1 或 2，则 Pod 会因节点外通信超时而失败。
如果观察到与 Kubernetes Service IP 地址通信之间的连接失败，就是此问题的症状。以下是您可能会看到的一些错误类型的示例：
如果给定节点的所有 pod 都无法与 Service IP 地址通信，则
istiodpod 可能会报告如下错误：{"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z", "message":"watch error in cluster Kubernetes: failed to list *v1.Node: Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5 34239\": dial tcp 172.26.0.1:443: i/o timeout"}对于在每个节点上运行的
localpv守护进程集，日志可能会显示如下超时：I1112 17:24:33.191654 1 main.go:128] Could not get node information (remaining retries: 2): Get https://172.26.0.1:443/api/v1/nodes/NODE_NAME: dial tcp 172.26.0.1:443: i/o timeout
反向路径过滤通过 IPv4 配置文件夹 (net/ipv4/conf/all) 中的 rp_filter 文件进行设置。sysctl 命令将反向路径过滤设置存储在网络安全配置文件（例如 /etc/sysctl.d/60-gce-network-security.conf）中。sysctl 命令可以替换反向路径过滤设置。
如需恢复 Pod 连接，请手动将 net.ipv4.conf.all.rp_filter 设置回 0，或者重新启动 anetd Pod 以将 net.ipv4.conf.all.rp_filter 设置回 0。如需重启 anetd Pod，请使用以下命令查找并删除 anetd Pod。新的 anetd Pod 会在其位置启动：
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
将 ANETD_XYZ 替换为 anetd Pod 的名称。
如需手动设置 net.ipv4.conf.all.rp_filter，请运行以下命令：
sysctl -w net.ipv4.conf.all.rp_filter = 0
引导（种类）集群 IP 地址和集群节点 IP 地址重叠
192.168.122.0/24 和 10.96.0.0/27 是引导（种类）集群使用的默认 pod 和服务 CIDR。如果这些地址与集群节点机器 IP 地址重叠，预检检查将失败。为避免冲突，您可以将 --bootstrap-cluster-pod-cidr 和 --bootstrap-cluster-service-cidr 标志传递给 bmctl 以指定不同的值。
不同集群的 IP 地址重叠
在更新期间，系统不会验证不同集群中的 IP 地址重叠。验证仅在创建集群/节点池创建时适用。
操作系统
在 CentOS 上创建或升级集群失败
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-*
作为长期解决方案，请考虑迁移到其他受支持的操作系统。
操作系统端点限制
在 RHEL 和 CentOS 中，存在 10 万个端点的集群级层限制。此数字是一个 Kubernetes Service 引用的所有 pod 的总和。如果两个服务引用同一组 pod，则计为两组独立的端点。RHEL 和 CentOS 中的底层 nftable 实现导致了此限制；这不是 Anthos clusters on Bare Metal 的固有限制。
重置/删除
命名空间删除
删除命名空间将阻止在该命名空间中创建新资源，包括用于重置机器的作业。删除用户集群时，您必须先删除集群对象，然后再删除其命名空间。否则，无法创建重置机器的作业，删除过程将跳过机器清理步骤。
containerd 服务
bmctl reset 命令不会删除任何 containerd 配置文件或二进制文件。containerd systemd 服务保持已启动且正在运行状态。该命令会删除调度到节点的容器运行 pod。