本文档概述了在裸机上安装和运行 Google Distributed Cloud（纯软件）的网络要求。
本页面适用于管理底层技术基础设施的生命周期并为其组织设计和架构网络的管理员、架构师、运维人员和网络专家。如需详细了解我们在Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE Enterprise 用户角色和任务。
外部网络要求
Google Distributed Cloud 需要连接到互联网才能运行。Google Distributed Cloud 从 Container Registry 检索集群组件，并且集群已向 Connect Agent 注册。
您可以使用公共互联网，通过 HTTPS、虚拟专用网 (VPN) 或专用互连连接连接到 Google。
如果您用于管理员工作站和集群节点的机器使用代理服务器访问互联网，则您的代理服务器必须允许一些特定连接。如需了解详情，请参阅在代理后安装的前提条件部分。
内部网络要求
Google Distributed Cloud 可与集群节点之间的第 2 层或第 3 层连接搭配使用。负载均衡器节点可以是控制平面节点，也可以是一组专用节点。如需了解详情，请参阅选择和配置负载均衡器。
当您使用与 MetalLB 的捆绑式第 2 层负载均衡（spec.loadBalancer.mode: bundled 和 spec.loadBalancer.type: layer2）时，负载均衡器节点需要第 2 层相邻负载。无论您是在控制平面节点还是一组专用负载均衡节点上运行负载均衡器，第 2 层相邻要求都适用。使用 BGP 进行捆绑式负载均衡支持第 3 层协议，因此不需要严格的第 2 层相邻连接。
负载均衡器机器的要求如下：
- 对于捆绑式第 2 层负载均衡，给定集群的所有负载均衡器都在同一个第 2 层网域中。控制平面节点还必须位于同一个第 2 层网域中。
- 对于捆绑式第 2 层负载均衡功能，所有虚拟 IP 地址 (VIP) 都必须位于负载均衡器机器子网中，并且可路由到子网的网关。
- 用户负责允许入站流量负载均衡器流量。
Pod 和 Service 网络
集群配置文件中指定了可供服务和 Pod 使用的 IP 地址范围。以下部分介绍了地址范围的最小和最大限制，以及规划集群安装时需要考虑的一些相关因素。
您可以在集群中拥有的 Pod 和 Service 数量由以下设置控制：
clusterNetwork.pods.cidrBlocks用于指定集群中允许的 Pod 数量。clusterNetwork.services.cidrBlocks用于指定集群中允许的服务数量。nodeConfig.podDensity.maxPodsPerNode指定可在单个节点上运行的最大 pod 数。
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: admin-basic
namespace: cluster-admin-basic
spec:
type: admin
profile: default
...
clusterNetwork:
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/20
...
nodeConfig:
podDensity:
maxPodsPerNode: 250
Pod 和 Service 的 IP 地址范围
您可以将一个 IP 地址范围指定为要用于 Pod 的无类别域间路由 (CIDR) 块，并将另一个 CIDR 块指定为要用于 Kubernetes 服务的 ClusterIP 地址。使用专用地址空间中的 IP 地址，如 RFC 1918 中所述。集群配置文件中预先填充的值应在下表中所述的限制范围内：
| 限制 | pod | 服务 |
|---|---|---|
| 最小范围 | /18 的掩码值（16,384 个地址） |
/24 的掩码值（256 个地址） |
| 预填充的范围 | /16 的掩码值（65,536 个地址） |
掩码值为 /20（4,096 个地址） |
| 最大范围 | /8 的掩码值（16,777,216 个地址） |
/12 的掩码值（1,048,576 个地址） |
为避免与网络中可访问的 IP 地址重叠，您可能需要使用与预填充值不同的 CIDR 范围。具体来说，Service 和 pod 范围不得与以下各项重叠：
任何集群中节点的 IP 地址
控制平面节点和负载均衡器使用的 VIP 地址
DNS 服务器或 NTP 服务器的 IP 地址
如果发现重叠的 IP 地址，预检检查会阻止创建和升级集群。
创建集群后，您可以增加服务网络范围 (clusterNetwork.services.cidrBlocks)，但无法减少分配的 IP 地址数量或进行更改。您只能更改 CIDR 地址块后缀，通过缩小掩码值来增加 IP 地址数量。
clusterNetwork.pods.cidrBlocks 和 nodeConfig.podDensity.maxPodsPerNode（在下一部分中介绍）都是不可变的，因此请仔细规划集群的未来增长，以免节点容量耗尽。如需了解基于测试的每个集群的 Pod 数、每个节点的 Pod 数和每个集群的节点数的建议上限，请参阅限制。
每个节点的最大 Pod 数量
在裸机上，Google Distributed Cloud 允许您为每个节点配置最多 250 个 pod。Kubernetes 会为每个节点分配一个 CIDR 地址块，以便每个 pod 都可以有一个唯一的 IP 地址。pod CIDR 块的大小对应于每个节点的最大 pod 数量。
下表列出了 Kubernetes 根据每个节点的配置的最大 pod 数量分配给每个节点的 CIDR 地址块的大小：
| 每个节点的最大 Pod 数量 | 每个节点的 CIDR 地址块 | IP 地址数量 |
|---|---|---|
| 32 | /26 |
64 |
| 33-64 | /25 |
128 |
| 65-128 | /24 |
256 |
| 129-250 | /23 |
512 |
若要在每个节点运行 250 个 pod，则需要 Kubernetes 为每个节点预留 /23 CIDR 地址块。假设您的集群为 clusterNetwork.pods.cidrBlocks 字段使用默认值 /16，则集群的节点数上限为 (2(23-16))=128 个。
如果您打算让该集群超出此上限，我们强烈建议您将 clusterNetwork.pods.cidrBlocks 设置为比预先填充的值大得多的 pod CIDR 块。
如需详细了解 Pod 和 Service 的数量以及其他因素如何影响集群可伸缩性，请参阅扩容 Google Distributed Cloud 集群。
具有高可用性的单用户集群部署
下图通过一种可能的网络配置介绍了 Google Distributed Cloud 的一些关键网络概念。
请考虑以下信息以满足网络要求：
- 控制平面节点运行负载均衡器，并且它们都具有第 2 层连接，而其他连接（包括工作器节点）只需要第 3 层连接。
- 配置文件定义工作器节点池的 IP 地址。配置文件还定义用于以下用途的 VIP：
- 服务
- 入站
- 通过 Kubernetes API 访问控制层面
- 您需要连接到 Google Cloud。
端口使用量
本部分确定了 Google Distributed Cloud 集群的端口要求。下表展示了集群和负载均衡器节点上的 Kubernetes 组件如何使用 UDP 和 TCP 端口。
控制平面节点
1.29 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新管理员集群节点 | 管理员工作站 |
| TCP | 入站 | 2379 - 2381 | etcd 服务器客户端 API、指标和健康状况 | kube-apiserver 和 etcd |
| TCP | 入站 | 2382 - 2384 | etcd-events 服务器客户端 API、指标和健康状况 | kube-apiserver 和 etcd-events |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 6444 | Kubernetes API 服务器 | 全部 |
| TCP | 入站 | 9100 | auth-proxy | node-exporter |
| TCP | 入站 | 9101 | 仅在 localhost 上提供节点指标
（适用于 1.28 版及更高版本） |
node-exporter |
| TCP | 入站 | 9977 | 从 API 服务器接收审核事件 | audit-proxy |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 10257 | kube-controller-manager
（1.28 版及更高版本的端口号已更改） |
本身 |
| TCP | 入站 | 10259 | kube-scheduler
（1.28 版及更高版本的端口号已更改） |
本身 |
| TCP | 入站 | 11002 | GKE Identity Service 核心容器通过 hostPort 绑定到端口
（适用于 1.29 版及更高版本） |
本身 |
| TCP | 入站 | 14443 | ANG Webhook 服务 | kube-apiserver 和 ang-controller-manager |
1.28 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新管理员集群节点 | 管理员工作站 |
| TCP | 入站 | 2379 - 2381 | etcd 服务器客户端 API、指标和健康状况 | kube-apiserver 和 etcd |
| TCP | 入站 | 2382 - 2384 | etcd-events 服务器客户端 API、指标和健康状况 | kube-apiserver 和 etcd-events |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 6444 | Kubernetes API 服务器 | 全部 |
| TCP | 入站 | 8444 | GKE Identity Service 核心容器通过 hostPort 绑定到端口
（仅适用于 1.28 版） |
全部 |
| TCP | 入站 | 9100 | auth-proxy | node-exporter |
| TCP | 入站 | 9101 | 仅在 localhost 上提供节点指标
（适用于 1.28 版及更高版本） |
node-exporter |
| TCP | 入站 | 9977 | 从 API 服务器接收审核事件 | audit-proxy |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 10257 | kube-controller-manager
（1.28 版及更高版本的端口号已更改） |
本身 |
| TCP | 入站 | 10259 | kube-scheduler
（1.28 版及更高版本的端口号已更改） |
本身 |
| TCP | 入站 | 14443 | ANG Webhook 服务 | kube-apiserver 和 ang-controller-manager |
1.16 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新管理员集群节点 | 管理员工作站 |
| TCP | 入站 | 2379 - 2381 | etcd 服务器客户端 API、指标和健康状况 | kube-apiserver 和 etcd |
| TCP | 入站 | 2382 - 2384 | etcd-events 服务器客户端 API、指标和健康状况
（适用于 1.16 版及更高版本） |
kube-apiserver 和 etcd-events |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 6444 | Kubernetes API 服务器 | 全部 |
| TCP | 入站 | 9100 | 提供指标 | node-exporter |
| TCP | 入站 | 9443 | 为控制平面组件提供/代理指标（此端口要求适用于集群 1.16 版及更低版本。） | kube-control-plane-metrics-proxy |
| TCP | 入站 | 9977 | 从 API 服务器接收审核事件 | audit-proxy |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10251 | kube-scheduler |
本身 |
| TCP | 入站 | 10252 | kube-controller-manager |
本身 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 14443 | ANG Webhook 服务 | kube-apiserver 和 ang-controller-manager |
1.15 版及更低版本
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新管理员集群节点 | 管理员工作站 |
| TCP | 入站 | 2379 - 2381 | etcd 服务器客户端 API、指标和健康状况 | kube-apiserver 和 etcd |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 6444 | Kubernetes API 服务器 | 全部 |
| TCP | 入站 | 9100 | 提供指标 | node-exporter |
| TCP | 入站 | 9443 | 为控制平面组件提供/代理指标（此端口要求适用于集群 1.16 版及更低版本。） | kube-control-plane-metrics-proxy |
| TCP | 入站 | 9977 | 从 API 服务器接收审核事件 | audit-proxy |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10251 | kube-scheduler |
本身 |
| TCP | 入站 | 10252 | kube-controller-manager |
本身 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 14443 | ANG Webhook 服务 | kube-apiserver 和 ang-controller-manager |
工作器节点
1.29 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 9100 | auth-proxy | node-exporter |
| TCP | 入站 | 9101 | 仅在 localhost 上提供节点指标
（适用于 1.28 版及更高版本） |
node-exporter |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 30000 - 32767 | NodePort 项服务 |
本身 |
1.28 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 9100 | auth-proxy | node-exporter |
| TCP | 入站 | 9101 | 仅在 localhost 上提供节点指标
（适用于 1.28 版及更高版本） |
node-exporter |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 30000 - 32767 | NodePort 项服务 |
本身 |
1.16 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 9100 | 提供指标 | node-exporter |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 30000 - 32767 | NodePort 项服务 |
本身 |
1.15 版及更低版本
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 9100 | 提供指标 | node-exporter |
| TCP | 入站 | 10250 | kubelet API |
自行控制平面 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 30000 - 32767 | NodePort 项服务 |
本身 |
负载均衡器节点
1.29 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 入站 | 443 | 集群管理 您可以使用 |
全部 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP 和 UDP | 入站 | 7946 | MetalLB 健康检查 | 负载均衡器节点 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
| TCP | 入站 | 11000 | HAProxy 指标的监听端口（不可变）
（适用于 1.29 版及更高版本） |
全部 |
| TCP | 入站 | 11001 | GKE Identity Service 的监听端口（不可变）
（适用于 1.29 版及更高版本） |
全部 |
1.28 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 入站 | 443 | 集群管理 您可以使用 |
全部 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP 和 UDP | 入站 | 7946 | MetalLB 健康检查 | 负载均衡器节点 |
| TCP | 入站 | 8443 | GKE Identity Service 的监听端口（不可变）
（仅适用于 1.28 版） |
全部 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
1.16 版
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 入站 | 443 | 集群管理 您可以使用 |
全部 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 7946 | MetalLB 健康检查 | 负载均衡器节点 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
1.15 版及更低版本
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新用户集群节点 | 管理员集群节点 |
| TCP | 入站 | 443 | 集群管理 您可以使用 |
全部 |
| TCP | 两者 | 4240 | CNI 健康检查 | 全部 |
| UDP | 入站 | 6081 | GENEVE 封装 | 本身 |
| TCP | 入站 | 7946 | MetalLB 健康检查 | 负载均衡器节点 |
| TCP | 入站 | 10256 | 节点健康检查 | 全部 |
多集群端口要求
在多集群配置中，添加的集群必须包含以下端口才能与管理员集群通信。
| 协议 | 方向 | 端口范围 | 用途 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 22 | 预配和更新集群节点 | 所有节点 |
| TCP | 入站 | 443 | 用于添加集群的 Kubernetes API 服务器 您可以使用 |
控制平面和负载均衡器节点 |
配置 firewalld 端口
您无需停用 firewalld 即可在 Red Hat Enterprise Linux (RHEL) 上运行 Google Distributed Cloud。如需使用 firewalld，您必须打开控制平面节点、工作器节点和负载均衡器节点使用的 UDP 和 TCP 端口，如本页面上的端口使用情况中所述。以下示例配置展示了如何使用 firewalld 命令行实用程序 firewall-cmd 打开端口。您应以根用户身份运行这些命令。
控制平面节点示例配置
以下命令块展示了如何在运行控制平面节点的服务器上打开所需端口的示例：
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
如需了解您打算使用的集群版本的特定端口要求，请参阅上述端口使用情况部分。相应地更新示例命令。
将 PODS_CIDR 替换为为 clusterNetwork.pods.cidrBlocks 字段中配置的 pod 预留的 CIDR 地址块。Pod 的默认 CIDR 地址块是 192.168.0.0/16。
工作器节点示例配置
以下命令块展示了如何在运行工作器节点的服务器上打开所需端口的示例：
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
如需了解您打算使用的集群版本的特定端口要求，请参阅上述端口使用情况部分。相应地更新示例命令。
将 PODS_CIDR 替换为为 clusterNetwork.pods.cidrBlocks 字段中配置的 pod 预留的 CIDR 地址块。Pod 的默认 CIDR 地址块是 192.168.0.0/16。
负载均衡器节点示例配置
以下命令块展示了如何在运行负载均衡器节点的服务器上打开所需端口的示例：
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
如需了解您打算使用的集群版本的特定端口要求，请参阅上述端口使用情况部分。相应地更新示例命令。
将 PODS_CIDR 替换为为 clusterNetwork.pods.cidrBlocks 字段中配置的 pod 预留的 CIDR 地址块。Pod 的默认 CIDR 地址块是 192.168.0.0/16。
RHEL 9.2 和 9.4 的补充配置
Red Hat Enterprise Linux (RHEL) 版本 9.2 和 9.4 在 1.29.400 及更高版本中作为正式版受支持。对于 RHEL 版本 9.2 和 9.4，您必须在节点上执行额外的 firewalld 配置，才能让服务和 pod 正常运行：
列出节点的活跃接口，以查找主节点接口：
firewall-cmd --list-interfaces根据 Linux 机器接口的命名惯例，主接口名称可能如以下之一所示：
eth0、eno1、ens1或enp2s0。列出节点的可用区，以查找主接口使用的可用区：
firewall-cmd --list-all-zones例如，如果主接口是
eno1，则响应中的以下部分会表明主接口位于public可用区：... public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: ...运行以下 firewalld 命令，为 RHEL 9.2 或 9.4 设置自定义区域和政策详细信息：
firewall-cmd --permanent --new-zone=cilium firewall-cmd --permanent --zone=cilium --add-interface=cilium_host firewall-cmd --permanent --zone=cilium --set-target ACCEPT firewall-cmd --permanent --zone=cilium --add-masquerade firewall-cmd --permanent --zone=cilium --add-forward firewall-cmd --permanent --new-policy cilium-host-port-forwarding firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT firewall-cmd --reload根据您在上述步骤中找到的各项，将
IN_ZONE替换为以下某个值：public：预定义可用区，用于仅接受所选传入连接的公共区域。trusted：受控环境中预定义可用区，其中所有网络连接都被接受。- 您定义的自定义区域的名称。
按照供应商文档配置存储解决方案。
例如，如果您使用 Portworx 管理有状态的工作负载，Portworx 网络要求会列出需要保持打开状态的端口。
对于供应商文档中列出的每个端口，请运行以下命令：
firewall-cmd --permanent --zone=public --add-port=PORT_INFO将
PORT_INFO替换为端口号或端口号范围，后跟协议。例如10250-10252/tcp。
确认端口配置
如需验证端口配置，请在控制平面、工作器和负载均衡器节点上执行以下步骤：
运行以下 Network Mapper 命令以查看哪些端口处于打开状态：
nmap localhost运行以下命令以获取 firewalld 配置设置：
firewall-cmd --info-zone=public firewall-cmd --info-zone=k8s-pods firewall-cmd --list-all-policies如有必要，请重新运行前面部分中的命令以正确配置您的节点。您可能需要以根用户身份运行这些命令。
firewalld 的已知问题
在 Red Hat Enterprise Linux (RHEL) 上运行启用了 firewalld 的 Google Distributed Cloud 时，firewalld 的更改可能会移除主机网络上的 Cilium iptables 链。anetd Pod 在启动时会添加 iptables 链。丢失 Cilium iptables 链会导致节点上的 Pod 丢失节点外部的网络连接。
导致移除 iptables 链的 firewalld 更改包括但不限于：
使用
systemctl重启firewalld使用命令行客户端 (
firewall-cmd --reload) 重新加载firewalld
如需应用 firewalld 更改而不移除 iptables 链，请在节点上重启 anetd：
使用以下命令找到并删除
anetdPod，以重启anetd：kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ将 ANETD_XYZ 替换为
anetdPod 的名称。