Kubernetes SIG Network 2022 年度盘点：10 个 KEP 与 Service、NetworkPolicy、DNS 能力演进全解析

Kubernetes SIG Network 2022 年度盘点：10 个 KEP 与 Service、NetworkPolicy、DNS 能力演进全解析

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

本篇文章以 sig-network/annual-report-2022.md 为骨架，系统梳理 SIG Network 在 Kubernetes v1.24、v1.25、v1.26 三个版本周期内推进的 10 个 KEP（Kubernetes Enhancement Proposal），覆盖 Service 负载均衡、NetworkPolicy、EndpointSlice、DNS 配置、拓扑感知路由等核心网络能力，并结合本仓库的 charter、sigs.yaml 与年度报告生成模板，帮助读者完整理解 2022 年 Kubernetes 网络领域的关键变化，以及这些功能对应的配置方式与适用场景。

一、报告背景：SIG Network 的职责边界与年度报告机制

SIG Network 是 Kubernetes 社区中负责网络相关组件、接口与 API 的特别兴趣小组。其使命在本仓库的 sig-network/README.md 中被概括为 "Covers networking in Kubernetes"，而其职责的具体边界则由 sig-network/charter.md 定义，主要包括：

• 网络控制面与数据面（Networking control plane and data paths）
• 网络服务抽象（Network service abstractions）
• 服务发现（DNS）
• 服务负载均衡（L4、L7）
• 网络安全与身份（Network security and identity）
• 集群连通性（Cluster connectivity）
• 网络组件的指标与监控
• 多集群网络（与 sig-multicluster 共享职责）

在代码与服务的层面，SIG Network 拥有 Services（[EndpointSlices]、[Service]、[Gateway API] 及其参考实现 kube-proxy）、Ingress、NetworkPolicy、集群 DNS、CNI 集成点等具体资产。

年度报告是 Kubernetes 社区治理流程的一部分，各 SIG 每年需提交一份总结。本仓库的 generator/annual-report/sig_report.tmpl 展示了年度报告的标准模板：报告通常包含当前重点工作（Current initiatives）、KEP 工作汇总、项目健康状况（Project health）、成员数据（Membership）、子项目（Subprojects）、工作组（Working groups）与运营任务（Operational）等小节。其中 KEP 列表部分在模板中是通过filterKEPs函数从kubernetes/enhancements仓库的 KEP 元数据中按 SIG 归属与发布周期自动筛选生成的，注释中明确指出"该列表由 kubernetes/enhancements 仓库中的 KEP 元数据生成"，因此年度报告中的 KEP 清单具有较高的权威性。

二、2022 年 KEP 全景总览

2022 年对应 Kubernetes v1.24（2022 年 5 月）、v1.25（2022 年 8 月）与 v1.26（2022 年 12 月）三个版本。SIG Network 在这三个版本中推进了 10 个 KEP，按成熟度阶段划分如下：

从阶段分布可以清晰看出 2022 年的两条主线：其一，多个 Beta/Stable 特性集中在 Service 与端点发现领域（占比最高），说明这一年 SIG Network 的工作重心是让既有网络服务能力更精细、更可控；其二，Alpha 阶段的 AdminNetworkPolicy 与 Dual Stack API Server 则代表了面向未来的新方向探索。下文逐一展开。

三、Alpha 阶段新特性：面向未来的两个探索

3.1 KEP-2091：AdminNetworkPolicy 资源（v1.24 进入 Alpha）

传统上，Kubernetes 的 NetworkPolicy 是 Namespace 级别的资源，只能由各 Namespace 内的用户管理，且是"允许列表"语义（默认拒绝、显式放行），这使集群管理员无法统一声明跨 Namespace 的安全策略基线。

KEP-2091 引入的 AdminNetworkPolicy 是一个集群级别的网络策略资源，由集群管理员创建，其优先级高于 Namespace 级别的 NetworkPolicy，用于表达"无论 Namespace 内策略如何，都必须遵守"的强制规则（例如：默认阻止所有跨 Namespace 的入站流量，或强制允许监控系统的探测流量）。与其配套的还有 BaselineAdminNetworkPolicy，用于定义"兜底"的默认策略。

从 SIG Network 的 charter 看，NetworkPolicy 相关 API（[NetworkPolicy]、[AdminNetworkPolicy]、[BaselineAdminNetworkPolicy]）正是本 SIG 的管辖范围，而网络策略子项目（见 sigs.yaml 中 sig-network 的 network-policy 子项目）负责其参考实现与演进。AdminNetworkPolicy 的出现，标志着 Kubernetes 网络策略从"应用开发者自管"走向"平台管理员统管"的重要一步。

3.2 KEP-2438：Dual Stack API Server（v1.24 进入 Alpha）

随着 IPv4 地址枯竭与 IPv6 部署需求增长，Kubernetes 持续推进双栈（IPv4/IPv6 共存）能力。KEP-2438 将双栈支持延伸到控制面核心组件：让 API Server 自身能够监听、服务并管理双栈网络配置，使 kube-apiserver 相关的服务发现、端点收集与健康检查逻辑完整兼容 IPv6 与双栈集群。

该 KEP 属于 SIG Network 与 SIG API Machinery 的交叉领域，是双栈集群从"数据面可用"走向"控制面原生支持"的关键补齐。结合 v1.24 同期稳定的 Service 双栈能力（Service.spec.ipFamilyPolicy），集群管理员可以更放心地将生产集群全面切换到双栈模式。

四、Beta 阶段：KEP-2595 扩展 DNS 配置（v1.26 进入 Beta）

Kubernetes Pod 的 DNS 行为由dnsPolicy与dnsConfig控制。传统上dnsConfig允许用户自定义 nameservers、searches 与 options，但对搜索域的数量、长度以及配置的组合方式存在较多限制，难以满足大型集群中复杂的 DNS 拆分与多租户场景。

KEP-2595 "Expanded DNS Configuration" 在 v1.26 进入 Beta，其核心是放宽dnsConfig中搜索域（searches）等字段的限制，并允许更灵活的 DNS 配置组合，使 Pod 能够接入更多样化的 DNS 拓扑（例如：同时搜索多个集群域、上级域与外部域）。对于运行在复杂网络环境（多集群、混合云、专有域名体系）中的工作负载，这一特性直接降低了 DNS 解析失败与配置 hack 的概率。

DNS 是 SIG Network charter 中明确的职责范围（Service discovery (DNS)），本仓库 sig-network/README.md 中 kube-dns 子项目（现多由 CoreDNS 承担服务 DNS 职责）也印证了这一领域的持续投入。

五、Stable 阶段：Service 与端点发现能力的集中成熟

2022 年有 8 个 KEP 达到 Stable，其中绝大多数集中在 Service 负载均衡与端点发现，这是本年度报告信息量最大的部分。

5.1 KEP-1864：LoadBalancer Service 可选禁用 NodePort（v1.24 稳定）

传统上，type: LoadBalancer的 Service 会同时分配一个 NodePort，以便外部流量经节点端口进入。但对于云厂商 LB 直连 Pod 或使用 LB 直通（LB Direct-to-Pod）方案的场景，NodePort 既浪费端口资源，又可能引入不必要的安全暴露面。

KEP-1864 为 Service 引入allocateLoadBalancerNodePorts字段，默认值为true以保持向后兼容；当显式设置为false时，云厂商 LB 将不再分配 NodePort，负载均衡器直接把流量转发到端点。这一特性尤其适合"LB 与后端节点之间使用独立网络（如 VPC 内网）"的部署，既减少了端口占用，也缩小了攻击面。

5.2 KEP-2079：NetworkPolicy 规则支持端口范围（v1.25 稳定）

KEP-2079 为 NetworkPolicy 的 ports 规则引入了端口范围表达能力，允许在一条规则中声明一段连续的端口区间，而无需逐端口枚举。典型配置形如：

spec: ingress: - from: - podSelector: {} ports: - protocol: TCP port: 8000 endPort: 9000

其中endPort与port配合定义闭区间 [port, endPort]。这一能力大幅简化了"开放某一大段服务端口"这类常见策略的编写，例如为监控、日志采集或开发环境开放整段端口范围时，策略文件从数百行缩减为几行。对实现方（如 kube-network-policies 等参考实现）而言，端口范围需要转换为底层数据面（iptables/nftables/ebpf）对应的规则集合，这也是 NetworkPolicy API 演进的一部分。

5.3 KEP-1435：同一 LoadBalancer Service 支持混合协议（v1.26 稳定）

在早期版本中，一个 Service 的spec.ports中的端口协议必须一致，混合 TCP 与 UDP 不被允许。KEP-1435 移除了这一限制，允许type: LoadBalancer的 Service 在同一资源中同时暴露 TCP 与 UDP 端口（例如 DNS 服务的 53/TCP 与 53/UDP）。这使诸如 DNS、NTP、VoIP 等"同端口双协议"的应用可以收敛为单一 Service 与单一负载均衡器，显著减少了资源管理与云厂商 LB 账单的复杂度。云厂商负载均衡器实现（包括 kube-controller-manager 中 service controller 与各云厂商的 LB 插件）需要支持多协议监听才能完整落地该特性。

5.4 KEP-1672：EndpointSlice 跟踪终止中的端点（v1.26 稳定）

当 Pod 进入 Terminating 状态（例如滚动更新或节点排空）时，传统 Endpoints API 会立即将其从端点列表移除，导致仍在途的连接被切断、或新连接被错误路由。KEP-1672 让 EndpointSlice 显式跟踪处于"终止中（Terminating）"状态的端点，并为其打上标记（terminating条件），使 kube-proxy 等消费方可基于此实现"优雅排空"：对终止中的端点，停止向其建立新连接，但允许已有的存量连接继续完成。

这一机制与 [KEP-1864] 之前的滚动更新体验问题、以及 Gateway API 等新一代 API 的端点语义一脉相承，是提升 Kubernetes 滚动更新与排空过程可靠性的关键底层改动。

5.5 KEP-2086：Service 内部流量策略（v1.26 稳定）

默认情况下，Service 会把流量负载均衡到集群内所有可达端点（包括远端节点上的 Pod），这在某些场景下引入不必要的跨节点网络跳数。KEP-2086 为 Service 引入internalTrafficPolicy字段，默认值为Cluster（保持全局负载均衡）；当设置为Local时，流量只会被路由到与发起方同节点的端点，从而将跨节点流量降到最低，适用于对网络延迟敏感、或节点本地性至关重要的工作负载（例如与数据缓存、本地存储绑定的应用）。

值得注意的是，该字段控制的是集群内部流量（如集群内 Pod 访问 Service ClusterIP），与面向外部流量的externalTrafficPolicy相互独立、互补使用。

5.6 KEP-2433：拓扑感知提示（Topology Aware Hints，v1.26 稳定）

拓扑感知提示是"把流量留在本地"理念的进一步泛化：通过 EndpointSlice 上的hints注解，把每个端点可服务的拓扑区域（如 zone）标注出来，使 kube-proxy 优先将流量路由到同一拓扑区域内的端点，从而降低跨可用区（AZ）的流量与成本。其启用方式是在 Service 上设置注解：

metadata: annotations: service.kubernetes.io/topology-mode: Auto

控制器会根据端点在各个 zone 的分布自动计算并写入 hints，当某 zone 端点分布不均衡时，系统会智能回退到全局负载均衡，避免热点。该特性对多云/多可用区部署的成本优化意义重大——跨 AZ 流量在多数公有云上都会产生额外费用。此前的 TopologyKeys（topology.kubernetes.io/zone）机制已被该特性取代，读者在迁移时需要注意。

5.7 KEP-3070：保留 Service IP 范围，支持静态与动态分配分离（v1.26 稳定）

在 v1.26 之前，Service.spec.clusterIP的静态指定与动态分配共用同一个 IP 池，导致"手动指定的 IP 与自动分配的 IP 冲突"的问题难以预防。KEP-3070 允许通过 kube-apiserver 的启动参数为 Service ClusterIP 划分两个独立地址段：

• --service-cluster-ip-range：动态分配使用的地址段（默认）
• --service-cluster-ip-range-allocated-static（或新增的静态保留段参数）：专门用于静态指定clusterIP的地址段

同时，Service 新增spec.clusterIPs的多 IP 支持与静态分配校验逻辑，保证静态指定的 IP 落在合法保留范围内。这一特性使集群管理员可以清晰地规划：动态段供日常自动分配使用，静态段供数据库、网关等需要固定 IP 的 Service 使用，两者互不干扰，从根源上消除了 IP 冲突风险。

六、子项目与工作组生态：年度报告的另一半信息

年度报告中除 KEP 之外，还列出了 SIG Network 在 2022 年存续的子项目（Subprojects）与工作组（Working groups），这些信息同样来源于仓库根目录的权威数据源 sigs.yaml。

6.1 持续运行中的子项目

报告标注为Continuing（持续运行）的子项目共 10 个：

• cluster-proportional-autoscaler：按集群节点数比例自动扩缩集群组件的控制器
• cluster-proportional-vertical-autoscaler：对应的垂直方向自动扩缩控制器
• external-dns：将 Ingress/Service 等资源的 DNS 记录同步到外部 DNS 提供商
• gateway-api：新一代流量管理 API（Gateway、HTTPRoute 等）及其一致性测试套件
• ingress：Ingress 控制器生态（ingress-nginx、ingress-gce）与一致性测试
• iptables-wrappers：对 iptables 命令的封装，用于安全、可预测的规则操作
• kpng：Kube Proxy Next Generation，kube-proxy 的模块化下一代探索项目
• kube-dns：Kubernetes 最早的 Service DNS 实现（现已多由 CoreDNS 替代）
• network-policy：NetworkPolicy 与 AdminNetworkPolicy 等 API 的演进与参考实现
• pod-networking：Pod 网络模型与 CNI 相关组件

这些子项目在 sigs.yaml 的 sig-network 条目下都有对应的 OWNERS 文件引用与联系人（Slack 频道），例如 network-policy 子项目关联 kubernetes-sigs/network-policy-api、kube-dns 关联 kubernetes/dns 等。读者若想参与或了解某一方向的治理细节，可直接查看 sigs.yaml 中对应的子项目定义。

6.2 持续运行中的工作组

报告同时列出了 4 个由 SIG Network 赞助或关联的持续工作组：

• IoT Edge：边缘计算与物联网场景的 Kubernetes 网络需求
• Multitenancy：多租户场景下的资源隔离与网络策略
• Policy：策略类 API 的跨 SIG 协调
• Structured Logging：结构化日志规范在组件间的推广

其中 IoT Edge 与 Multitenancy 的文档已归档在 archive/wg-iot-edge 与 archive/wg-multitenancy（对应 archive 目录中的历史资料），Policy 与 Structured Logging 的年度资料也可在 archive/wg-policy、archive/wg-structured-logging 中找到，供读者追溯其历史进展。

6.3 运营（Operational）自检清单

年度报告末尾附带了 SIG 运营自检清单，包括：README 与 CONTRIBUTING 的准确性复核、sigs.yaml 中子项目与 OWNERS 链接的核对、SIG 领导层（chairs、tech leads、subproject owners）信息的时效性确认、会议记录与录制的归档，以及社区层面更新（社区会议、KubeCon、邮件列表）的记录。这套清单保证了 SIG 的治理信息与代码仓库保持同步，也说明 sigs.yaml 是全社区"单一事实来源"（generator 的 README 在 generator/README.md 中明确声明了这一点）。

七、SIG Network 的治理与领导结构（2022 年度参考）

结合 sig-network/README.md 与 sigs.yaml（第 2281 行起），SIG Network 的治理结构如下：

• Chairs（负责运营与流程）：Bowei Du（Google）、Guilherme Cassolato（Red Hat）、Michael Zappa（Microsoft）
• Technical Leads（负责子项目与技术决策）：Antonio Ojea（Google）、Dan Winship（Red Hat）、Tim Hockin（Google）
• Emeritus Leads：Casey Davenport、Dan Williams、Shane Utt
• Steering Committee Liaison：Maciej Szulik

SIG 的 OWNERS 配置（见 sig-network/OWNERS）将 reviewers 与 approvers 均指向sig-network-leads，并打上sig/network标签，确保 PR 审查与审批集中于该组的领导团队。SIG Network 的职责范围（Areas of Responsibility）在 sig-network/README.md 中归纳为五个领域：DNS、Ingress、网络插件/CNI、NetworkPolicy、Services/kube-proxy——2022 年的 10 个 KEP 恰好全部落在这五个领域之内。

八、总结与 2022 年度趋势观察

综合 sig-network/annual-report-2022.md 的 KEP 清单与相关治理资料，可以提炼出 2022 年 Kubernetes 网络演进的几个清晰趋势：

1. Service 层的精细化控制成为主流：混合协议（KEP-1435）、禁用 NodePort（KEP-1864）、内部流量策略（KEP-2086）、拓扑感知路由（KEP-2433）、IP 范围分离（KEP-3070）——五大 Stable 特性全部围绕"让负载均衡更符合实际拓扑与成本约束"展开。
2. 流量本地化是贯穿全年的主题：internalTrafficPolicy（节点级）与 Topology Aware Hints（区域级）形成了"就近路由"的两级解决方案。
3. 网络策略走向集群级治理：AdminNetworkPolicy（KEP-2091）与端口范围（KEP-2079）分别从"管理粒度"与"表达力"两个维度补强了网络策略体系。
4. 双栈与 DNS 能力持续补齐：Dual Stack API Server（KEP-2438）与 Expanded DNS Configuration（KEP-2595）让大型复杂集群的网络底座更加健壮。

对于集群管理员与应用开发者而言，这些特性（尤其是 v1.26 集中稳定的一批 Service 能力）直接影响日常的 Service 定义、网络策略编写与多可用区部署成本优化，建议在升级到对应 Kubernetes 版本后，结合 sig-network/README.md 中列出的子项目实现（如 ingress、network-policy、external-dns 等）逐一验证与采用。

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community