排查 VPC 集群中的 IP 地址管理问题

本页面可帮助您解决 Google Kubernetes Engine (GKE) 中 VPC 集群的 IP 地址管理问题。

本页面将指导平台管理员和运维人员诊断和解决节点和 Pod 的 IP 地址耗尽等问题、排查阻止集群操作的网络配置错误（例如范围冲突）、管理 IP 地址 CIDR 范围，以及正确配置默认 SNAT、Cloud NAT 和双栈网络等功能。

本页面还可帮助应用开发者了解底层网络限制（例如 IP 空间耗尽）如何影响其工作负载，从而导致 Pod 无法调度等问题。虽然开发者可能不会直接配置 VPC，但了解这些常见问题有助于他们更好地与平台管理员和运维人员协作，以便更快地解决问题。如需详细了解我们在Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE 用户角色和任务。

诊断 IP 地址耗尽问题

集群中的 IP 地址用尽可能会阻止节点扩缩，并中断工作负载。本部分介绍了如何在 GKE 中使用 IP 地址利用率监控来检测和解决潜在的耗尽问题。

GKE 会使用来自网络分析器数据分析和其他 GKE 数据源的数据来计算 IP 地址利用率。此监控适用于所有 VPC 原生集群。

如需查看集群的 IP 地址利用率，请执行以下操作：

  1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

    转到 KUBERNETES 集群

  2. 点击要检查的集群的名称。此操作会打开集群的详细信息页面。

  3. 使用以下任一方法前往 IP 利用率页面：

    • 选择可观测性标签页，然后在可观测性导航菜单中点击 IP 利用率。

    • 在网络部分中，找到集群 Pod IPv4 范围（默认）行，然后点击查看 IP 利用率。

  4. 查看 IP 分配的状态列。此列显示了 Pod IP 地址范围内已分配的 IP 地址百分比。GKE 会将节点的已分配 CIDR 范围内的所有 IP 地址视为已分配（无论各个 IP 地址是否已分配给 Pod）。此行为意味着，该百分比反映的是节点的整个 Pod 范围，而不仅仅是正在使用的 IP 地址。如果多个集群共用相同的 IP 地址范围，利用率百分比会显示其总和。

  5. 如需详细查看 IP 地址使用情况（包括 CIDR 范围、子网信息和建议），请点击显示详情。

如果您的 IP 地址利用率较高（接近 100%），请考虑以下解决方案，以防止 IP 地址耗尽：

  • 使用不连续的多 Pod CIDR 添加更多 Pod IPv4 地址范围。借助此功能，您可以为 Pod 添加更多 IPv4 地址，而无需重新创建集群或配置新子网。
  • 在集群中添加更多具有额外 IPv4 地址范围的子网。借助此功能，新节点池可以使用新添加的子网中的 IP 地址。
  • 创建一个新集群，并将 Pod 数上限设为较低的值。此方法为每个节点预留较少的 IP 地址，有助于您管理集群网络范围内的总体 IP 地址消耗。如需了解详情，请参阅配置每个节点的最大 Pod 数量。
  • 如果您没有足够的 IP 地址范围或 RFC 1918 地址空间，请考虑非 RFC 1918 范围（包括 E 类地址空间）。

排查特定网络问题

以下部分介绍了如何解决 VPC 原生集群的相关问题。您还可以查看 GKE IP 地址利用率数据分析。

默认网络资源尚未就绪

表现

您会收到类似于以下内容的错误消息：

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
潜在原因

同一子网上存在并行操作。例如，正在创建其他 VPC 原生集群，或正在子网上添加或删除次要范围。

解决方法

重试此命令。

IPCidrRange 值无效

表现

您会收到类似于以下内容的错误消息：

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
潜在原因

正在同时创建其他 VPC 原生集群，且该集群正尝试在同一 VPC 网络中分配相同的范围。

正在向同一 VPC 网络中的子网添加相同的次要范围。

解决方法

如果您没有指定任何次要范围，并且在创建集群时收到该错误，请重试集群创建命令。

Pod 没有足够的可用 IP 地址空间

表现

集群在较长时间内处于预配状态。

集群创建返回托管式实例组 (MIG) 错误。

向集群添加一个或多个节点时，系统会显示以下错误：

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
潜在原因

节点 IP 地址用尽：分配给集群的子网的主要 IP 地址范围用尽可用的 IP 地址。这通常发生在扩缩节点池或创建大型集群时。

Pod IP 地址用尽：分配给集群的 Pod CIDR 范围已满。当 Pod 数量超过 Pod CIDR 的容量时，就会发生这种情况，尤其是在每个节点的 Pod 密度较高或部署规模较大时。

特定子网命名惯例：子网在错误消息中命名的方式可以帮助您确定问题是出在节点 IP 地址范围（节点本身获取其 IP 地址的位置）还是 Pod IP 地址范围（Pod 内的容器获取其 IP 地址的位置）。

次要范围用尽 (Autopilot)：在 Autopilot 集群中，由于扩缩或 Pod 密度较高，为 Pod IP 地址分配的次要范围用尽。

解决方案

收集有关集群的以下信息：名称、控制平面版本、操作模式、关联的 VPC 名称、子网名称和 CIDR。此外，请注意默认集群 Pod IPv4 范围和任何其他集群 Pod IPv4 范围（包括名称和 CIDR）、是否启用了 VPC 原生流量路由，以及在集群和节点池级层设置的每个节点的 Pod 数上限（如果适用）。请注意所有受影响的节点池及其特定 IPv4 Pod IP 地址范围和每个节点的 Pod 数上限配置（如果与集群范围设置不同）。此外，请记录节点池配置中每个节点的 Pod 数上限的默认配置和自定义配置（如果有）。

确认 IP 地址用尽问题

  • Network Intelligence Center：在 Network Intelligence Center 中针对 GKE 集群检查 Pod IP 地址范围内的 IP 地址分配率是否较高。

    如果您在 Network Intelligence Center 中观察到 Pod 范围内的 IP 地址分配率较高，则表示 Pod IP 地址范围已用尽。

    如果 Pod IP 地址范围显示正常的分配率，但您仍然遇到 IP 地址用尽的问题，则很可能是节点 IP 地址范围已用尽。

  • 审核日志：检查 IP_SPACE_EXHAUSTED 条目中的 resourceName 字段，并将其与子网名称或次要 Pod IP 地址范围名称进行比较。

  • 检查已用尽的 IP 地址范围是节点 IP 地址范围还是 Pod IP 地址范围。

    如需验证已用尽的 IP 地址范围是节点 IP 地址范围还是 Pod IP 地址范围，请检查 IP_SPACE_EXHAUSTED 日志条目的 ipSpaceExhausted 部分中的 resourceName 值是否与子网名称或受影响 GKE 集群中使用的 Pod 的次要 IPv4 地址范围名称相关联。

    如果 resourceName 的值采用“[Subnet_name]”格式，则表示节点 IP 地址范围已用尽。如果 resourceName 的值采用“[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]”格式，则表示 Pod IP 地址范围已用尽。

解决 Pod IP 地址用尽问题：

  • 调整现有 Pod CIDR 的大小：增加当前 Pod IP 地址范围的大小。您可以使用连续的多 Pod CIDR 向集群添加 Pod IP 地址范围。
  • 创建其他子网：向集群添加具有专用 Pod CIDR 的子网。

减少每个节点的 Pod 数量以释放 IP 地址：

解决节点 IP 地址用尽问题：

  • 查看 IP 地址规划：确保节点 IP 地址范围符合您的扩缩要求。
  • 创建新集群（如有必要）：如果节点 IP 地址范围受到严重限制，请创建具有适当 IP 地址范围大小的替换集群。请参阅 VPC 原生集群的 IP 范围和 IP 范围规划。

使用 gcpdiag 调试 IP 地址用尽问题

gcpdiag 是一种开源工具，不是官方支持的 Google Cloud 产品。您可以使用 gcpdiag 工具来帮助识别和修复 Google Cloud项目问题。如需了解详情，请参阅 GitHub 上的 gcpdiag 项目。

如需检查 Autopilot 和 Standard GKE 集群的 IP 地址用尽原因，请考虑以下各项：
  • 集群状态：在报告 IP 地址用尽时检查集群状态。
  • 网络分析器：查询 Stackdriver 日志获取网络分析器日志，以确认是否存在 Pod 或节点 IP 地址用尽问题。
  • 集群类型：：检查集群类型并根据集群类型提供相关建议。

Google Cloud 控制台

  1. 完成然后复制以下命令。
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. 打开 Google Cloud 控制台并激活 Cloud Shell。
    3. 打开 Cloud 控制台
  3. 粘贴复制的命令。
  4. 运行 gcpdiag 命令以下载 gcpdiag Docker 映像，然后执行诊断检查。如果适用，请按照输出说明修复失败的检查。

Docker

您可以使用封装容器运行 gcpdiag，以在 Docker 容器中启动 gcpdiag。必须安装 Docker 或 Podman。

  1. 在本地工作站上复制并运行以下命令。 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. 执行 gcpdiag 命令： 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

查看此 Runbook 的可用参数。

替换以下内容：

  • PROJECT_ID：资源所在项目的 ID
  • CLUSTER_NAME：项目中目标 GKE 集群的名称。
  • LOCATION：集群所在的可用区或区域。
  • start_time：问题开始的时间。
  • end_time：问题结束的时间。如果问题仍然存在，请设置当前时间。

实用标志：

如需查看所有 gcpdiag 工具标志的列表和说明，请参阅 gcpdiag 使用说明。

确认是否已停用默认 SNAT

使用以下命令检查默认 SNAT 的状态：

gcloud container clusters describe CLUSTER_NAME

将 CLUSTER_NAME 替换为您的集群名称。

输出内容类似如下：

networkConfig:
  disableDefaultSnat: true
  network: ...

无法在没有 --enable-ip-alias 的情况下使用 --disable-default-snat

此错误消息和“must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster”表示您应在创建集群时明确设置 --disable-default-snat 标志，因为您是在专用集群中使用公共 IP 地址。

如果您看到类似“cannot disable default sNAT ...”的错误消息，则表示无法在集群中停用默认 SNAT。如需解决此问题，请检查您的集群配置。

在停用默认 SNAT 的情况下调试 Cloud NAT

如果您使用 --disable-default-snat 标志创建了一个专用集群，并且为 Cloud NAT 设置了互联网访问，但没有看到来自 Pod 的互联网绑定流量，请确保 Pod 范围包含在 Cloud NAT 配置中。

如果 Pod 到 Pod 的通信存在问题，请检查节点的 iptables 规则以验证 Pod 范围是否未被 iptables 规则伪装。

如需了解详情，请参阅 GKE IP 伪装文档。

如果您尚未为集群配置 IP 伪装代理，GKE 会自动确保 Pod 到 Pod 的通信未被伪装。但是，如果配置了 IP 伪装代理，则该代理将替换默认的 IP 伪装规则。验证是否在 IP 伪装代理中配置了其他规则，以忽略对 Pod 范围的伪装。

双栈集群网络通信未按预期工作

潜在原因
GKE 集群创建的防火墙规则不包含分配的 IPv6 地址。
解决方法
您可以按照以下步骤验证防火墙规则
：

  1. 验证防火墙规则内容：

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    请将 FIREWALL_RULE_NAME 替换为防火墙规则的名称。

    每个双栈集群都会创建一条防火墙规则，以允许节点和 Pod 互相通信。防火墙规则内容如下所示：

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    sourceRanges 值必须与 subnetIpv6CidrBlock 相同。targetTags 值必须与 GKE 节点上的标记相同。如需解决此问题，请使用集群 ipAllocationPolicy 块信息更新防火墙规则。

后续步骤