Anthos clusters on Bare Metal 已知问题

安装

对照组 v2 不兼容

对照组 v2 (cgroup v2) 与 Anthos clusters on Bare Metal 1.6 不兼容。Kubernetes 1.18 不支持 cgroup v2。此外,Docker 从 20.10 版开始才提供实验性支持。在版本 247.2-2 中,systemd 默认切换为 cgroup v2。如果存在 /sys/fs/cgroup/cgroup.controllers,则表示系统使用的是 cgroup v2。

从 Anthos clusters on Bare Metal 1.6.2 开始,预检检查会验证 cgroup v2 未在集群机器上使用。

安装期间的良性错误消息

在高可用性 (HA) 集群安装期间,您可能会看到有关 etcdserver leader change 的错误。这些错误消息是良性的,可以忽略。

使用 bmctl 安装集群时,您可能会在 create-cluster.log 末尾看到 Log streamer failed to get BareMetalMachine 日志消息。此错误消息是良性的,可以忽略。

检查集群创建日志时,您可能会看到有关注册集群或调用网络钩子的暂时性故障。您可以放心地忽略这些错误,因为安装过程将重试这些操作,直到操作成功。

预检检查和服务帐号凭据

对于由管理员集群或混合集群触发的安装(也就是不使用 bmctl 创建的集群,例如用户集群),预检检查不会验证 Google Cloud Platform 服务帐号凭据或其相关权限。

预检检查和权限遭拒

在安装过程中,您可能会看到有关 /bin/sh: /tmp/disks_check.sh: Permission denied 的错误。这些错误消息是由于使用 noexec 选项装载 /tmp 所致。要使 bmctl 正常运行,您需要从 /tmp 装载点中移除 noexec 选项。

在查看信息中心之前创建 Cloud Monitoring 工作区

您需要先通过 Google Cloud Console 创建 Cloud Monitoring 工作区,然后才能查看任何 Anthos clusters on Bare Metal 监控信息中心。

应用默认凭据和 bmctl

bmctl 使用应用默认凭据 (ADC) 验证集群操作在 cluster spec 中的位置值(如果未设置为 global)。

要使 ADC 正常运行,您需要将 GOOGLE_APPLICATION_CREDENTIALS 环境变量指向服务帐号凭据文件,或运行 gcloud auth application-default login

Ubuntu 20.04 LTS 和 bmctl

在 1.8.2 之前的 Anthos clusters on Bare Metal 版本上,某些具有较新 Linux 内核的 Ubuntu 20.04 LTS 发行版(包括 5.8 内核上的 GCP Ubuntu 20.04 LTS 映像)在非 init 网络命名空间中将 /proc/sys/net/netfilter/nf_conntrack_max 设为了只读。这会阻止 bmctl 设置最大连接跟踪表大小,这会阻止引导集群启动。表大小不正确的症状是引导集群中的 kube-proxy pod 将崩溃循环,如以下示例错误日志中所示:

kubectl logs -l k8s-app=kube-proxy -n kube-system --kubeconfig ./bmctl-workspace/.kindkubeconfig
I0624 19:05:08.009565       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 393216
F0624 19:05:08.009646       1 server.go:495] open /proc/sys/net/netfilter/nf_conntrack_max: permission denied

解决方法是手动在主机上将 net/netfilter/nf_conntrack_max 设置为所需的值:sudo sysctl net.netfilter.nf_conntrack_max=393216。请注意,所需的值取决于节点的核心数。使用上述 kubectl logs 命令来确认 kube-proxy 日志中所需的值。

此问题在 Anthos clusters on Bare Metal 1.8.2 和更高版本中已得到修复。

Ubuntu 20.04.3+ LTS 和 HWE

Ubuntu 20.04.3 在其硬件启用 (HWE) 软件包中启用了内核 5.11。Anthos clusters on Bare Metal 1.7.x 版不支持此内核。如果要使用内核 5.11,请下载升级到 Anthos clusters on Bare Metal 1.8.0 版或更高版本。

Docker 服务

在集群节点机器上,如果 PATH 环境变量中存在 Docker 可执行文件,但 Docker 服务未处于活动状态,则预检检查将失败并报告 Docker service is not active。如需修复此错误,请移除 Docker 或启用 Docker 服务。

Containerd 需要 PATH 中的 /usr/local/bin

具有 containerd 运行时的集群要求 /usr/local/bin 位于 SSH 用户的 PATH 中,以便 kubeadm init 命令查找 crictl 二进制文件。如果找不到 crictl,则创建集群会失败。

如果您未以根用户身份登录,则使用 sudo 运行 kubeadm init 命令。sudo PATH 可能与根配置文件不同,并且不得包含 /usr/local/bin

要修复此错误,请更新 /etc/sudoers 中的 secure_path 来包含 /usr/local/bin。或者,在另一个 /bin 目录中为 crictl 创建符号链接。

从 1.8.2 开始,运行集群时,Anthos clusters on Bare Metal 会将 /usr/local/bin 添加到 PATH 中。但是,以非根用户身份运行快照仍将包含 crictl: command not found(可通过上述解决方法解决此问题)。

节点波动就绪

集群偶尔会显示快速节点就绪性(节点状态在 ReadyNotReady 之间快速变化)。不健康的 Pod 生命周期事件生成器 (PLEG) 会导致此行为。PLEG 是 kubelet 中的一个模块。

如需确认健康状况不佳的 PLEG 是否导致此行为,请使用以下 journalctl 命令检查 PLEG 日志条目:

journalctl -f | grep -i pleg

如下所示的日志条目表示 PLEG 健康状况不佳:

...
skipping pod synchronization - PLEG is not healthy: pleg was last seen active
3m0.793469
...

已知的 runc 竞争条件是导致 PLEG 运行状况不佳的可能原因。runc 进程卡住是竞争条件的症状。使用以下命令检查 runc init 进程状态:

ps aux | grep 'runc init'

要解决此问题,请按以下步骤操作:

  1. 在每个节点上运行以下命令,以安装最新的 containerd.io 并提取最新的 runc 命令行工具:

    Ubuntu

    sudo apt update
    sudo apt install containerd.io
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    

    CentOS/RHEL

    sudo dnf install containerd.io
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    
  2. 如果 runc init 进程卡滞,请重新启动节点。

    或者,您也可以手动清理所有卡滞的进程。

升级和更新

如果 .manifests 目录缺失,则 bmctl update cluster 会失败

如果在运行 bmctl update cluster 之前移除了 .manifests 目录,则该命令会失败,并显示如下所示的错误:

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

如需解决此问题,请先运行 bmctl check cluster,这将重新创建 .manifests 目录。

此问题适用于 Anthos Clusters on Bare Metal 1.10 及更早版本,并在 1.11 版及更高版本中得到修复。

error during manifests operations,导致升级卡住

在某些情况下,集群升级无法完成,并且 bmctl CLI 没有响应。此问题可能是由错误更新的资源引起的。如需确定您是否受到此问题的影响并解决此问题,请按以下步骤操作:

  1. 检查 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} 是问题资源的名称。

  2. 如果您在日志中找到这些错误,请使用 kubectl edit 从日志消息中包含的资源中移除 kubectl.kubernetes.io/last-applied-configuration 注解。

  3. 保存更改并将更改应用于资源。

  4. 重试集群升级。

bmctl update 无法移除维护块

bmctl update 命令无法在集群资源配置中移除或修改 maintenanceBlocks 部分。如需了解详情(包括从维护模式中移除节点的说明),请参阅将节点置于维护模式

将集群从 1.7.5 升级到 1.7.6 被阻止

您无法将 Anthos on Bare Metal 1.7.5 版集群升级到 1.7.6 版。此阻止不会影响 Anthos clusters on Bare Metal 的任何其他版本。例如,您可以将集群从 1.7.4 版升级到 1.7.6 版。如果您使用的是 1.7.5 版集群,要获取 1.7.6 版中解决的安全漏洞修复,则必须在更高版本可用之后进行升级。

从 1.6.0 升级

1.6.0 版本不提供升级功能。

从 1.7.0 升级到 1.7.x

从 1.7.0 升级到 1.7.x 时,集群可能会卡在控制层面节点升级。您可能会看到 MACHINE-IP-machine-upgrade 作业周期性地运行和失败。此问题影响具有以下特征的 1.7.0 集群:

  • 在控制层面节点上预安装了 Docker。
  • 选择 containerd 作为运行时。

导致此问题的原因是 Anthos clusters on Bare Metal 错误地将 cri-socket 配置为 Docker 而不是 containerd。要解决此问题,您必须为 Docker 设置映像拉取凭据:

  1. 登录 Docker:

    docker login gcr.io
    

    这将创建一个 $HOME/.docker/config.json 文件。

  2. 列出所有控制层面节点的 IP 地址,以空格分隔:

    IPs=(NODE_IP1 NODE_IP2 ...)
    
  3. 将 Docker 配置复制到节点:

    for ip in "${IPs[@]}"; do
      scp $HOME/.docker/config.json USER_NAME@{ip}:docker-config.json
    

    USER_NAME 替换为在管理员集群配置文件中配置的用户名。

  4. 为 Docker 设置映像拉取凭据:

    ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"
    

用户集群补丁程序升级限制

由管理员集群管理的用户集群必须位于相同的 Anthos clusters on Bare Metal 版本或更低版本中,并且必须是一个次要版本。例如,可以接受管理 1.7.2 版用户集群的 1.8.1 版 (anthosBareMetalVersion: 1.8.1) 管理员集群,但 1.6.3 版用户集群不在一个次要版本中。

当管理员集群使用的发布版本之后发布补丁时,升级限制会阻止您将用户集群升级到新的安全补丁。例如,如果您的管理员集群的版本为 1.8.2,该版本于 2021 年 7 月 29 日发布,则您无法将您的用户集群升级到版本 1.7.3,因为该版本于 2021 年 8 月 16 日发布。

控制组驱动程序错误配置为 cgroupfs

如果您遇到与控制组 (cgroup) 驱动程序相关的问题,这可能是因为 Anthos clusters on Bare Metal 错误地将其配置为 cgroupfs 而非 systemd

要解决此问题,请按以下步骤操作:

  1. 登录您的机器并打开 /etc/containerd/config.toml

  2. [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] 下添加 SystemdCgroup = true

    ...
       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
         [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
           runtime_type = "io.containerd.runc.v2"
           runtime_engine = ""
           runtime_root = ""
           privileged_without_host_devices = false
           base_runtime_spec = ""
           [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
             SystemdCgroup = true
     [plugins."io.containerd.grpc.v1.cri".cni]
       bin_dir = "/opt/cni/bin"
       conf_dir = "/etc/cni/net.d"
       max_conf_num = 1
       conf_template = ""
    ...
    
  3. 保存更改并关闭该文件。

  4. 打开 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

  5. 在该文件的末尾添加 --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service

    [Service]
    Environment="HOME=/root"
    Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
    Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
    # This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
    EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
    # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
    # the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
    EnvironmentFile=-/etc/default/kubelet
    ExecStart=
    ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service
    
  6. 保存更改并重新启动服务器。

  7. 运行以下命令验证 systemd 是控制组驱动程序:

    systemd-cgls
    

    验证存在 kubepods.slice 部分并且所有 pod 都在此部分下。

操作

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) 的功能:

  1. 找到用户集群 kubeconfig 文件。

    创建集群时,Anthos clusters on Bare Metal 会在管理员工作站上生成 kubeconfig 文件。默认情况下,该文件位于 bmctl-workspace/USER_CLUSTER_NAME 目录中。

  2. 验证该 kubeconfig 是正确的用户集群 kubeconfig:

    kubectl get nodes --kubeconfig PATH_TO_GENERATED_FILE

    PATH_TO_GENERATED_FILE 替换为用户集群 kubeconfig 文件的路径。响应会返回用户集群的节点的详细信息。确认集群的机器名称正确无误。

  3. 运行以下命令以删除管理员集群中的损坏的 kubeconfig 文件:

    kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
  4. 运行以下命令,将正确的 kubeconfig Secret 保存回管理员集群:

    kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \
        --from-file=value=PATH_TO_GENERATED_FILE

重置/删除

用户集群支持

您无法使用 bmctl reset 命令重置用户集群。

装载点和 fstab

重置不会卸载 /mnt/localpv-share/ 下的装载点,并且不会清理 /etc/fstab 中的相应条目。

命名空间删除

删除命名空间将阻止在该命名空间中创建新资源,包括用于重置机器的作业。删除用户集群时,您必须先删除集群对象,然后再删除其命名空间。否则,无法创建重置机器的作业,删除过程将跳过机器清理步骤。

containerd 服务

bmctl reset 命令不会删除任何 containerd 配置文件或二进制文件。containerd systemd 服务保持已启动且正在运行状态。该命令会删除调度到节点的容器运行 pod。

安全

升级期间,集群 CA/证书将轮替。目前不支持按需轮替。

Anthos clusters on Bare Metal 自动轮替 kubelet 服务证书。当证书快要过期时,每个 kubelet 节点代理都可以发出证书签名请求 (CSR)。管理员集群中的控制器会验证并批准 CSR。

日志和监控

节点日志不会导出到 Cloud Logging

节点名称中带有点(“.”)的节点日志不会导出到 Cloud Logging。作为一种解决方法,请按照说明向 stackdriver-log-forwarder-config 资源添加过滤条件,使 Stackdriver Operator 能够识别和导出这些日志。

  1. 缩小 Stackdriver Operator stackdriver-operator 的大小:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system scale \
        deploy stackdriver-operator --replicas=0
    
  2. 修改 Log Forwarder configmap stackdriver-log-forwarder-config

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system edit configmap \
        stackdriver-log-forwarder-config
    
  3. 将以下过滤条件添加到 configmap 的 input-systemd.conf 部分的末尾:

       [FILTER]
           Name    lua
           Match_Regex   container-runtime|kubelet|node-problem-detector|node-journal
           script  replace_dot.lua
           call    replace
    
     replace_dot.lua: |
       function replace(tag, timestamp, record)
           new_record = record
    
           local local_resource_id_key = "logging.googleapis.com/local_resource_id"
    
           -- Locate the local_resource_id
           local local_resource_id = record[local_resource_id_key]
    
           local first = 1
           local new_local_resource_id = ""
           for s in string.gmatch(local_resource_id, "[^.]+") do
               new_local_resource_id = new_local_resource_id .. s
               if first == 1 then
                   new_local_resource_id = new_local_resource_id .. "."
                   first = 0
               else
                   new_local_resource_id = new_local_resource_id .. "_"
               end
           end
    
           -- Remove the trailing underscore
           new_local_resource_id = new_local_resource_id:sub(1, -2)
           new_record[local_resource_id_key] = new_local_resource_id
           return 1, timestamp, new_record
       end
    
  4. 删除所有日志转发器 pod:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch daemonset \
        stackdriver-log-forwarder -p \
        '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    

    在继续下一步之前,先验证 stackdriver-log-forwarder pod 是否已删除。

  5. 部署一个 daemonset,以清理 fluent-bit 缓冲区中所有损坏的未处理数据:

    kubectl --kubeconfig ADMIN_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
    
  6. 使用以下命令验证 daemonset 是否已清理了所有节点。

    kubectl --kubeconfig ADMIN_KUBECONFIG logs -n kube-system \
        -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
    
    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get pods \
        -l app=fluent-bit-cleanup --no-headers | wc -l
    

    这两个命令的输出应等于您的集群中的节点编号

  7. 删除清理 daemonset:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system delete ds fluent-bit-cleanup
    
  8. 重启 pod:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch \
        daemonset stackdriver-log-forwarder --type json \
        -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    

网络

具有捆绑式第 2 层负载均衡的客户端来源 IP 地址

外部流量政策设置为 Local 可能会导致捆绑式第 2 层负载均衡的路由错误,如 No route to host。外部流量政策默认设置为 Cluster (externalTrafficPolicy: Cluster)。使用此设置时,Kubernetes 会处理集群范围的流量。LoadBalancerNodePort 类型的服务可以使用 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 的名称。

由于 I/O 超时和反向路径过滤而导致的 Pod 连接失败

Anthos clusters on Bare Metal 在节点上配置反向路径过滤以停用源验证 (net.ipv4.conf.all.rp_filter=0)。如果 rp_filter 设置更改为 12,则 Pod 会因节点外通信超时而失败。

如果观察到与 Kubernetes Service IP 地址通信之间的连接失败,就是此问题的症状。以下是您可能会看到的一些错误类型的示例:

  • 如果给定节点的所有 pod 都无法与 Service IP 地址通信,则 istiod pod 可能会报告如下错误:

     {"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/2410.96.0.0/27 是引导(种类)集群使用的默认 pod 和服务 CIDR。如果这些地址与集群节点机器 IP 地址重叠,预检检查将失败。为避免冲突,您可以将 --bootstrap-cluster-pod-cidr--bootstrap-cluster-service-cidr 标志传递给 bmctl 以指定不同的值。

不同集群的 IP 地址重叠

没有验证不同集群的 IP 地址是否重叠的预检检查。

Anthos clusters on Bare Metal 中的 hostport 功能

目前不支持 ContainerPort 中的 hostport 功能。

操作系统

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

作为长期解决方案,请考虑迁移到其他受支持的操作系统,例如 UbuntuRHEL

操作系统端点限制

在 RHEL 和 CentOS 中,存在 10 万个端点的集群级层限制。此数字是一个 Kubernetes Service 引用的所有 pod 的总和。如果两个服务引用同一组 pod,则计为两组独立的端点。RHEL 和 CentOS 中的底层 nftable 实现导致了此限制;这不是 Anthos clusters on Bare Metal 的固有限制。

配置

控制层面和负载均衡器规范

控制层面和负载均衡器节点池规范很特别。这些规范声明和控制关键集群资源。这些资源的规范来源是它们在集群配置文件中的相应部分:

  • spec.controlPlane.nodePoolSpec
  • spec.LoadBalancer.nodePoolSpec

因此,请勿直接修改顶层控制层面和负载均衡器节点池资源。请改为修改集群配置文件中的相关部分。

集群和节点池规范中的可变字段

目前,在集群创建后,集群配置文件中只有以下集群和节点池规范字段可以更新(这些字段是可变字段):

  • 对于 Cluster 对象 (kind: Cluster),以下字段是可变的:

    • spec.anthosBareMetalVersion
    • spec.bypassPreflightCheck
    • spec.controlPlane.nodePoolSpec.nodes
    • spec.loadBalancer.nodePoolSpec.nodes
    • spec.maintenanceBlocks
    • spec.nodeAccess.loginUser
  • 对于 NodePool 对象 (kind: NodePool),以下字段是可变的:

    • spec.nodes

快照

以非根用户身份截取快照

对于 Anthos clusters on Bare Metal 1.8.1 版及更早版本,如果您不以根用户身份登录,则无法使用 bmctl 命令截取集群快照。从 1.8.2 版开始,裸机上的 Anthos 集群将遵循集群规范中的 nodeAccess.loginUser。如果管理员集群无法访问,您可以使用 --login-user 标志指定登录用户。

请注意,如果您将 containerd 用作容器运行时,则快照仍会运行 crictl 命令。如需查看解决方法,请参阅 Containerd 需要在 PATH 中使用 /usr/local/bin。用于 SUDO 的 PATH 设置会导致此问题。

GKE Connect

崩溃循环 gke-connect-agent Pod

大量使用 GKE Connect 网关有时可能会导致 gke-connect-agent Pod 内存不足问题。这些内存不足问题的症状包括:

  • gke-connect-agent Pod 表现出大量重启症状,或者最终出现崩溃循环状态。
  • 连接网关停止运行。

如需解决此内存不足问题,请修改 gke-connect 命名空间下前缀为 gke-connect-agent 的部署,并将内存限制提高到 256 MiB 或更高。

kubectl patch deploy $(kubectl get deploy -l app=gke-connect-agent -n gke-connect -o jsonpath='{.items[0].metadata.name}') -n gke-connect --patch '{"spec":{"containers":[{"resources":{"limits":{"memory":"256Mi"}}}]}}'

此问题在 Anthos clusters on Bare Metal 1.8.2 和更高版本中已得到修复。