排查裸金属网络问题的 GDCV 问题

本页面介绍如何解决 Google Distributed Cloud Virtual for Bare Metal 的网络问题。我们提供了常规问题排查信息和指南，以及建议的工具。此外，还包括 MetalLB 的 DNS 问题排查信息和一些常见问题。

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

网络连接问题排查

GKE Enterprise 网络依赖于您的物理网络基础架构。例如，MetalLB 依赖于支持免费 ARP 的开关，使用边界网关协议 (BGP) 的捆绑式负载均衡依赖于您的路由器，并且所有节点都应该能够互相通信。如果您的 GKE 集群中存在网络问题，则必须确定问题在于 GKE Enterprise 组件还是您自己的基础架构。

首先确定问题的范围，然后尝试确定受影响的组件。问题的范围可以是以下三种类别之一：主体（从何处）、目标（至哪个）和网络层。

主体范围可以是下列选项之一：

  • 所有集群范围的节点（或 hostNetwork Pod）。
  • 所有集群范围的 Pod。
  • 单个节点或一组节点上的所有 Pod。
  • 来自同一 Deployment 或 DaemonSet 的所有 Pod。
  • 集群外部的客户端。

目标的范围可以是以下一项或多项：

  • 来自同一集群的所有其他 Pod IP 地址。
  • 来自同一节点的所有其他 Pod IP 地址。
  • 来自同一集群的 ClusterIP Service VIP。
  • 来自同一集群的 LoadBalancer Service VIP。
  • Ingress 第 7 层 LoadBalancer (Istio)。
  • 来自同一集群的其他节点。
  • 内部 DNS 名称（例如 *.svc.cluster.local）。
  • 外部 DNS 名称（例如 google.com）。
  • 来自集群外部的实体。
  • 互联网上的实体。

网络层可以是以下一项或多项：

  • 第 2 层链路层问题，例如近邻系统、ARP 或 NDP。
  • 第 3 层 IP 地址路由问题。
  • 第 4 层 TCP 或 UDP 端点问题。
  • 第 7 层 HTTP 或 HTTPS 问题。
  • DNS 解析问题。

了解问题的范围有助于识别问题中涉及的组件以及问题发生在哪一层。在发生问题时收集信息非常重要，因为某些问题是暂时的，因此系统恢复后的快照将不包含足够的信息进行根本原因分析。

入站流量问题

如果主体是来自集群外部的客户端，并且无法连接到 LoadBalancer 服务，则为南北连接问题。下图显示，在有效的示例中，传入流量从左到右流经堆栈，而返回流量从右到左依次流经堆栈。

入站流量从用户流向物理基础架构，通过负载均衡器流向 anetd/kube-proxy，然后流向后端。

如果此流量出现问题，请使用以下问题排查流程图来帮助确定问题所在：

通过查看数据包在环境中传输时执行的每个步骤来排查网络入站流量问题。检查过程中是否存在适当的操作和连接。

在此流程图中，以下问题排查指南可帮助确定问题所在：

  • 数据包是否离开客户端？如果为否，那么您可能遇到了网络基础架构问题。
  • 您是否使用 MetalLB？如果是，数据包是否到达 LB 节点，而 ARP 是否已正确发送？如果为否，那么您可能遇到了网络基础架构问题。
  • 您是否使用 F5 BIG-IP？如果是，您是否已检查 F5 问题？
  • 网络地址转换 (NAT) 是否正确执行？如果不是，则可能会遇到 kube-proxy/Dataplane V2 问题。
  • 数据包是否到达工作器节点？否则，您可能遇到了 Dataplane v2 Pod 到 Pod 问题。
  • 数据包是否到达 Pod？如果不是，则可能是 Dataplane v2 本地转发问题。

以下部分介绍了排查每个阶段的问题，以确定流量是否正确流动。

数据包是否离开客户端？

检查数据包是否正确离开客户端并经过物理网络基础架构中配置的路由器。

  1. 使用 tcpdump 检查数据包在离开客户端去向目标服务时的情形：

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    如果您没有看到出站流量，这便是问题的根源。

数据包是否到达 LoadBalancer 节点？

如果您使用 MetalLB 作为负载均衡器：

  1. 查看 metallb-controller 日志以确定由哪个负载均衡器节点提供该服务 VIP：

    kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP

  2. 使用 SSH 连接到该节点。

  3. 对于 MetalLB 节点，请使用 tcpdump 查看流量：

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    对于 ManualLB，流量可以到达任何节点。根据负载均衡器配置，您可以选择一个或多个节点。使用 tcpdump 查看流量：

    tcpdump -ni any host NODE_IP and port NODE_PORT

    此命令在负载均衡器类型之间有所不同，因为 MetalLB 在将数据包转发到节点之前不会执行 NAT。

    如果您没有看到流量进入任何节点，则这是问题的来源。

是否存在 F5 BIG-IP 问题？

如需排查 F5 BIG-IP 问题，请参阅以下关于 F5 服务未收到流量的其中一个部分。

ARP 是否正确发送？

MetalLB 的负载均衡器节点依赖于 ARP 来通告服务 VIP。如果 ARP 响应已正确发送，但流量未进入，则表示物理网络基础架构存在问题。此问题的一个常见原因是某些高级数据平面学习功能会忽略软件定义网络 (SDN) 解决方案中的 ARP 响应。

  1. 使用 tcpdump 检测 ARP 响应：

    tcpdump -ni any arp

    尝试找到通告您遇到问题的 VIP 的消息。

  2. 对于 MetalLB，它不会发送免费 ARP。您看到的响应频率取决于架顶式 (ToR) 交换机等其他设备何时发送 ARP 请求。

是否执行了 NAT？

Dataplane v2/kube-proxy 执行目标网络地址转换（目标 NAT 或 DNAT），将目标 VIP 转换为后端 Pod IP 地址。如果您知道哪个节点是负载均衡器的后端，请使用 SSH 连接到该节点。

  1. 使用 tcpdump 检查 Service VIP 是否已正确转换：

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. 对于 Dataplane v2，您还可以连接到 anetd pod 并使用嵌入式 Cilium 调试工具：

    cilium monitor --type=drop

如需了解详情，请参阅以下有关 Dataplane v2/Cilium 问题的其中一个部分。

数据包是否到达工作器节点？

在工作器节点上，数据包到达外部接口，然后传送到 Pod。

  1. 使用 tcpdump 检查数据包是否到达外部接口（通常名为 eth0 或 ens192）：

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
对于 Google Distributed Cloud Virtual for Bare Metal，数据包会被封装在隧道中。将数据包解封时，它来自名为 cilium_geneve 的网络接口。

由于正常的 Service 后端在不同节点上包含多个 Pod，因此可能很难排查哪个节点出现了故障。一种常见的解决方法是捕获问题足够长的时间，以便某些数据包最终到达，或将后端数量限制为一个。

如果数据包从未到达工作节点，则表示存在网络基础架构问题。请与网络基础架构团队联系，了解数据包在 LoadBalancer 节点和工作器节点之间被丢弃的原因。一些常见问题包括：

  • 检查软件定义网络 (SDN) 日志。SDN 有时会由于各种原因而丢弃数据包，例如分割、错误校验或或反仿冒。
  • 过滤生成数据包 UDP 端口 6081 的防火墙规则。

如果数据包到达节点的外部接口或隧道接口，则需要将其转发到目标 Pod。如果 Pod 是主机网络 Pod，则无需执行此步骤，因为 Pod 与节点共享网络命名空间。否则，需要额外的包转发。

每个 Pod 都具有虚拟以太网接口对，其工作方式与管道类似。发送到接口一端的数据包从接口的另一端接收。其中一个接口移动到 Pod 的网络命名空间，并重命名为 eth0。另一个接口保存在主机命名空间中。不同的 CCI 具有不同的架构。对于 Dataplane v2，该接口通常命名为 lxcxxxx。名称具有连续的接口编号，例如 lxc17 和 lxc18。您可以使用 tcpdump 检查数据包是否到达 Pod，也可以指定接口：

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

如果数据包到达该节点，但无法到达 Pod，请检查路由表，如下所示：

  ip route

通常，每个 Pod 都应具有一个路由条目，用于将 Pod IP 地址路由到 lxc 接口。如果缺少条目，通常意味着 CNI 数据路径存在错误。如需确定根本原因，请检查 CNI DaemonSet 日志。

出站流量问题

如果流量可以进入 Pod，则您可能会在出站流量流出 Pod 时出现问题。下图显示了一个有效的示例，即传入流量从左到右流经堆栈：

出站流量从 Pod 通过主机的外部接口传输到物理基础架构，然后流向外部服务。

  1. 如需验证传出数据包是否正确伪装成节点 IP 地址，请检查外部服务（第 4 层）。

    数据包的来源 IP 地址应从 Pod IP 地址映射到具有来源网络地址转换（来源 NAT 或 SNAT）的节点 IP 地址。在 Dataplane v2 中，此过程通过加载到外部接口上的 ebpf 实现。

    使用 tcpdump 检查来源 IP 地址是否已正确从 Pod IP 地址转换为节点 IP 地址：

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    如果 tcpdump 显示数据包已正确伪装，但远程服务没有响应，请检查与基础架构中的外部服务的连接。

  2. 如果传出数据包已正确伪装为节点 IP 地址，请使用 tcpdump 检查外部主机（第 3 层）连接：

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    在运行 tcpdump 的同时，从其中一个 Pod 执行 ping 操作：

    kubectl exec POD_NAME ping EXTERNAL_IP

    如果您没有看到 ping 响应，请检查与基础架构中的外部服务的连接。

集群内问题

对于 Pod 到 Pod 的连接问题，请尝试将范围限定为节点。通常，一组节点无法与另一组节点通信。

  1. 在 Dataplane v2 中，检查从当前节点到同一集群中的所有其他节点的节点连接。在 anetd Pod 中，检查运行状况：

    cilium status --all-health

网络层问题

确定发生连接问题的网络层是重要的一步。“从来源到目标的连接问题”错误消息并不足以帮助解决问题，这可能是应用错误、路由问题或 DNS 问题。了解出现问题的层有助于修复正确的组件。

很多时候，错误消息都会直接指明问题所在的层。以下示例可帮助您排查网络层问题：

  • HTTP 错误表明这是第 7 层问题。
    • HTTP 代码 40x、50x 或 TLS 握手错误意味着第 4 层一切正常。
  • “对等方重置了连接”错误表示这是第 4 层问题。
    • 很多时候，远程套接字无法接受连接的当前状态，因此会发送 RESET 数据包。此行为可能是连接跟踪或 NAT 错误。
  • “没有通向主机的路由”和“连接超时”错误通常是第 3 层或第 2 层问题。
    • 这些错误表示数据包无法正确路由到目标位置。

实用的问题排查工具

与网络相关的 DaemonSet 在节点上运行，并且可能是连接问题的原因。但是，节点配置错误、架顶式 (ToR) 交换机、主路由器或防火墙也可能会导致问题。您可以借助以下工具来确定问题的范围或层级，并确定问题在于您的 GKE Enterprise 节点还是物理基础架构。

Ping

Ping 在第 3 层（IP 层）工作，并检查来源和目标之间的路由。如果 ping 无法到达目的地，这通常意味着问题位于第 3 层。

但是，并非所有 IP 地址都可以进行 ping 操作。例如，对于某些负载均衡器 VIP 地址，如果它是纯第 4 层负载均衡器，则无法执行 ping 操作。在 ClusterIP Service 中，VIP 可能不会返回 ping 响应。在第 4 层，此 Service 仅在您指定端口号（例如 VIP:port）时返回 ping 响应。

Google Distributed Cloud Virtual for Bare Metal 中的 BGPLB 和 MetalLB 负载平衡器都在第 3 层工作。您可以使用 ping 操作来检查连接。虽然 F5 有所不同，但它也支持 ICMP。您可以使用 ping 操作来检查与 F5 VIP 的连接。

Arping

Arping 与 ping 类似，不同之处在于其在第 2 层有效。第 2 层和第 3 层问题通常都有来自应用的类似错误消息。Arping 和 ping 有助于区分问题。例如，如果来源和目标位于同一子网中，但您无法列出目标，则这是第 2 层问题。

成功的 arping <ip> 会返回目的地的 MAC 地址。在第 2 层，此地址通常表示物理基础架构问题。 此问题通常是节点之间的物理交换。

Arping 还可以检测 IP 地址冲突。IP 地址冲突是指两个机器配置为在同一子网上使用同一 IP 地址，或者另一个物理机器使用了 VIP 地址。IP 地址冲突可能会引起难以排查的间歇性问题。如果 arping <ip> 返回多个 MAC 地址条目，则表示存在 IP 地址冲突。

从 arping 中获取 MAC 地址后，您可以使用 https://maclookup.app/ 查询 MAC 地址的制造商。每个制造商都有一个 MAC 前缀，因此您可以使用这些信息来帮助确定哪些设备尝试使用同一 IP 地址。例如，VMware 拥有 00:50:56 块，因此 MAC 地址 00:50:56:xx:yy:zz 是 vSphere 环境中的虚拟机。

iproute2

iproute2 的 ip CLI 有许多有用的子命令，例如：

  • ip r：输出路由表
  • ip n：输出 IP 地址到 MAC 地址的对应关系的邻域表
  • ip a：输出机器上的所有接口

邻域表中的缺失路由或条目可能会导致节点出现连接问题。Anetd 管理路由表和邻域表。这些表中的配置错误可能会导致连接问题。

Cilium/适用于 Dataplane v2 的 Hubble CLI

每个 anetd Pod 都有多种有用的连接调试工具：

  • cilium monitor --type=drop
    • 输出 anetd/Cilium 丢弃的每个数据包的日志。
  • hubble observe
    • 输出经过 anetd 的 ebpf 堆栈的所有数据包。
  • cilium status --all-health
    • 输出 Cilium 的状态，包括节点到节点的连接状态。每个 anetd Pod 都会检查集群中所有其他节点的运行状况，并有助于确定任何节点到节点的连接问题。

Iptables

Iptables 可在许多 Kubernetes 组件和子系统中使用。kube-proxy 使用 iptables 实现服务解析。

  1. 如需排查 iptables 级别的网络问题，请使用以下命令：

    iptables -L -v | grep DROP

    查看丢弃规则，并检查数据包计数和字节计数，了解它们是否随时间增加。

Tcpdump

Tcpdump 是一款强大的数据包捕获工具，可生成大量网络流量数据。常见做法是从来源和目标位置运行 tcpdump。如果数据包在离开源节点时被捕获，但从未在目标节点上捕获，则意味着两者之间有某个内容丢弃了该数据包。此行为通常表示物理基础架构中的某个内容错误地丢弃了数据包。

DNS 问题排查

DNS 解析问题主要分为两类：

  • 常规 Pod，使用集群内 DNS 服务器。
  • 主机网络 Pod 或节点，不使用集群内 DNS 服务器

以下部分提供了一些有关集群 DNS 架构的信息和有用的提示，以便开始排查其中某一类别的问题。

集群 DNS 架构

集群 DNS 服务会解析集群中 Pod 的 DNS 请求。 CoreDNS 为所有版本的 Google Distributed Cloud Virtual for Bare Metal 提供此服务。

每个集群有两个或更多 coredns Pod，以及一个负责根据集群大小扩缩 DNS Pod 数量的自动扩缩器。 还有一项名为 kube-dns 的服务，用于对所有后端 coredns Pod 之间的请求执行负载均衡。

大多数 Pod 已将其上游 DNS 配置为 kube-dns Service IP 地址，并且 Pod 会将 DNS 请求发送到其中一个 coredns Pod。DNS 请求可以分组到以下目标之一：

  • 如果请求是针对 cluster.local 网域，则是集群内的 DNS 名称，该名称引用集群中的 Service 或 Pod。
    • CoreDNS 会监控集群中所有 Service 和 Pod 的 api-server，并响应对有效 cluster.local 网域的请求。
  • 如果请求不是针对 cluster.local 网域，则是针对外部网域。
    • CoreDNS 会将请求转发到上游域名服务器。默认情况下，CoreDNS 使用在其运行所在节点上配置的上游域名服务器。

如需了解详情，请参阅 DNS 在 Kubernetes 中的工作原理和配置概览。

DNS 问题排查提示

如需排查 DNS 问题，您可以使用 dig 和 nslookup 工具。这些工具可让您发送 DNS 请求以测试 DNS 解析是否正常运行。以下示例展示了如何使用 dig 和 nslookup 来检查 DNS 解析问题。

  • 使用 dig 或 nslookup 发送 google.com 请求：

    dig google.com
nslookup google.com

  • 使用 dig 将 kubernetes.default.svc.cluster.local 请求发送到服务器 192.168.0.10：

    dig @192.168.0.10 kubernetes.default.svc.cluster.local

  • 您还可以使用 nslookup 执行与上一个 dig 命令相同的 DNS 查找：

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    查看 dig 或 nslookup 命令的输出。如果您收到错误响应或未收到响应，则表示存在 DNS 解析问题。

常规 Pod

调试 DNS 问题的第一步是确定请求是否发送到 coredns Pod。通常，一般集群连接问题显示为 DNS 问题，因为 DNS 请求是工作负载发送的第一类流量。

查看来自您的应用的错误消息。io timeout 或类似错误表示没有响应，且存在常规网络连接问题。

包含 DNS 错误代码（如 NXDOMAIN 或 SERVFAIL）的错误消息表示连接到集群内 DNS 服务器，但服务器无法解析域名：

  • NXDOMAIN 错误表明 DNS 服务器报告网域不存在。验证您的应用请求的域名是否有效。
  • SERVFAIL 或 REFUSED 错误表明 DNS 服务器发回了响应，但是无法解析该网域或验证其不存在。如需了解详情，请查看 coredns Pod 的日志。

您可以使用以下命令找到 kube-dns 服务的 IP 地址：

kubectl -n kube-system get svc kube-dns

在 DNS 无法工作的 Pod 中，尝试使用 dig 或 nslookup 向此 IP 地址发送 DNS 请求，如上一部分所述：

  • 如果这些请求不起作用，请尝试向每个 coredns Pod 的 IP 地址发送请求。
  • 如果某些 Pod 正常运行，但其他 Pod 不起作用，请检查是否存在任何明显的模式，例如，DNS 解析适用于 coredns Pod 所在节点上的 Pod，但不适用于跨节点。此行为可能表明集群内存在连接问题。

如果 CoreDNS 无法解析外部域名，请参阅以下部分来排查主机网络 Pod 问题。CoreDNS 的行为类似于主机网络 Pod，并使用节点的上游 DNS 服务器来解析名称。

主机网络 Pod 或节点

主机网络 Pod 和节点使用节点上配置的域名服务器进行 DNS 解析，而不是使用集群内 DNS 服务。此域名服务器是在 /etc/resolv.conf 或 /run/systemd/resolve/resolv.conf 中配置的，具体取决于操作系统。此配置意味着它们无法解析 cluster.local 域名。

如果您遇到主机网络名称解析问题，请按照上述部分中的问题排查步骤来测试 DNS 是否适用于您的上游域名服务器。

验证所有节点是否配置了同一组服务器。如果您配置了不同的域名服务器，则可能会看到不同节点上的 DNS 解析不一致。使用 dig 或 nslookup 向每个域名服务器发送请求，以验证每个域名服务器是否正常工作。如果某些域名服务器正常运行，但其他域名服务器无法正常运行，您会看到这种类型的不一致 DNS 解析失败。

常见的网络问题

以下部分详细说明了您可能会遇到的一些常见网络问题。为帮助解决问题，请遵循适当的问题排查指南。如果您需要其他帮助，请与 Cloud Customer Care 联系。

Dataplane v2/Cilium

常见错误：[PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

此错误表示 Cilium 代理由于速率限制而拒绝 Pod 创建事件。对于每个节点，Cilium 对 PUT 端点有 4 个并发请求限制。当一个节点出现大量请求时，这种行为符合预期。Cilium 代理应赶上延迟请求。

在 GKE Enterprise 1.14 及更高版本中，速率限制会自动调整到节点容量。速率限制器可以收敛到更合理的数字，对更强大的节点具有更高的速率限制。

常见错误：Ebpf map size is full

Dataplane v2 将状态存储在 eBFP 映射中。状态包括 Service、连接跟踪、Pod 身份和网络政策规则。如果映射已满，则代理无法插入条目，这会导致控制平面和数据平面之间存在差异。例如，Service 映射具有 64k 条目限制。

  1. 如需检查 eBFP 映射条目及其当前大小，请使用 bpftool。以下示例会检查负载均衡器映射：

    bpftool map dump pinned \
/sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1

bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1

  2. 如果映射接近 64k 限制，请清理映射。以下示例演示了如何清理负载均衡器映射：

    bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key

  3. 如需将状态重新填充到 eBFP 映射，请重启 anetd。

由于 NetworkPluginNotReady 错误，节点未准备就绪

如果 CNI Pod 未在节点上运行，则您可能会看到类似于以下内容的错误：

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

节点可能也会处于就绪状态，错误类似于以下示例：

  "Network plugin not installed"

初始化节点时，kubelet 会等待多个事件发生，然后再将节点标记为 Ready。kubelet 检查的一个事件是安装了容器网络接口 (CNI) 插件。CNI 插件应由 anetd 使用 init 容器进行安装，以将 CNI 二进制文件和 CNI 配置安装到所需的主机目录中。

如需排查此问题，请检查这些 Pod 未在节点上运行的原因。此错误通常是由网络问题导致的。这些 pod 在主机网络上运行，因此没有网络依赖项。

  1. 检查 anetd pod 的状态。请查看以下问题排查步骤，以帮助确定问题的原因：

    • 如果 Pod 处于 Crashlooping 状态，请检查日志以了解 Pod 无法正常运行。
    • 如果 Pod 处于 Pending 状态，请使用 kubectl describe 并查看 Pod 事件。例如，Pod 可能缺少卷之类的资源。
    • 如果 Pod 处于 Running 状态，请检查日志和配置。 某些 CNI 实现提供了停用 CNI 安装的选项，如 Cilium。
    • anetd 中有一个名为 custom-cni-conf 的配置选项。如果此设置配置为 true，则 anetd 不会安装其 CNI 二进制文件。

F5 Service 未收到流量

如果没有流量传递到 F5 Service，请查看以下问题排查步骤：

  1. 检查 F5 BIG-IP 中的每个分区是否在一个集群中配置（无论是管理员集群还是用户集群）。如果多个不同集群共享一个分区，您可能会遇到间歇性连接中断。出现这种行为的原因是两个集群尝试控制同一分区，并从其他集群中删除 Service。

  2. 验证以下两个 Pod 是否正在运行。任何未运行的 Pod 都表示存在错误：

    Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj

    由 GKE Enterprise 拥有的 Load-balancer-f5，用于为每个 LoadBalancer 类型 Service 创建 ConfigMap。ConfigMap 最终由 bigip 控制器使用。

  3. 确保每个 Service 的每个端口都存在 ConfigMap。例如，对于以下端口：

    Kube-server-443-tcp     2   31h
Kube-server-8132-tcp        2   31h

    该 kube-server 命令应类似于以下示例：

    Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h

    ConfigMap 中的数据部分应具有前端 VIP 和端口，如以下示例所示：

    data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
  schema: f5schemadb://bigip-virtual-server_v0.1.7.json

  4. 查看您的 BIG-IP 实例日志和指标。如果 ConfigMap 已正确配置，但 BIG-IP 实例未能遵循配置，则可能是 F5 问题。对于 BIG-IP 实例中发生的问题，请与 F5 支持团队联系，以诊断和排查问题。

并行连接过多导致 NAT 失败

对于集群中的给定节点，节点 IP 地址为路由到集群外部地址的数据包提供网络地址转换 (NAT)。同样，当入站数据包进入配置为使用捆绑式负载均衡 (spec.loadBalancer.mode: bundled) 的负载均衡节点时，来源网络地址转换 (SNAT) 会将数据包路由到节点 IP 地址，然后数据包才被转发到后端 Pod。

GDCV 用于裸金属的 NAT 端口范围为 32768-65535。此范围将该节点上每个协议的并行连接数限制为 32,767 个。每个连接都需要在 conntrack 表中有一个条目。如果短期连接过多，则 conntrack 表会耗尽 NAT 端口。垃圾回收器会清理过时的条目，但系统不会立即清理。

当节点上的连接数接近 32,767 时，您开始看到需要 NAT 的连接的数据包丢失。

要确定您是否受到此问题的影响，请执行以下操作：

  1. 在有问题的节点上的 anetd Pod 上运行以下命令：

    kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

    您应该会看到以下形式的错误：

    No mapping for NAT masquerade DROPPED

如需解决此问题，请将您的流量重新分配到其他节点。

后续步骤

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