企业官网建设流程全解析

Kubernetes SIG Network 2021 年度技术盘点：双栈网络 GA、Gateway API 演进与 KEP 全景

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

本文基于 Kubernetes 社区仓库中的 sig-network/annual-report-2021.md 年度报告，结合 sig-network/README.md、sig-network/charter.md 与根目录 sigs.yaml 中的组织结构数据，系统梳理 SIG Network 在 2021 年的核心技术成果。你将了解到双栈 IPv4/IPv6 网络正式 GA、Gateway API 从 Service APIs 更名并推进到 v1alpha2、一批网络类 KEP 的 Stable/Beta/Alpha 状态分布，以及 ingress-nginx、kube-dns 等子项目的健康度与社区治理情况，可作为理解 Kubernetes 网络演进脉络和 SIG 年度运营机制的参考索引。

SIG Network 的职责范围与年度报告定位

根据 sig-network/charter.md，SIG Network 负责向 Kubernetes 用户和工作负载暴露网络能力的组件、接口与 API，并提供部分参考实现（例如 kube-proxy 作为 Service API 的参考实现）。其职责范围覆盖：网络控制面与数据面、网络服务抽象、服务发现（DNS）、L4/L7 服务负载均衡、网络安全与身份、集群连通性、可伸缩性等跨领域关注点，以及与 sig-multicluster 共同负责的多集群网络。

对应到代码层面，SIG Network 管辖的服务与 API 包括：EndpointSlices / Endpoints 端点抽象、Service / Gateway API 等 L3/4 负载均衡 API、Ingress 与 Gateway API 等 L7 入口负载均衡 API、NetworkPolicy / AdminNetworkPolicy 网络策略 API，以及集群 DNS 和 CNI 集成点。这份职责清单与 sigs.yaml 中登记的子项目列表一一对应，而 2021 年度报告正是对该 SIG 一整年工作在这些职责面上的集中复盘。

2021 年高光工作：四件大事

报告第一部分列出了 SIG 在 2021 年最值得关注的四项成果，构成了当年 Kubernetes 网络领域的核心看点：

1. Dual-stack IPv4/IPv6 网络特性达到 GA：KEP 563（Dual stack）在 2021 年底随 Kubernetes 1.23 正式发布（官方博客发布于 2021 年 12 月 8 日），标志着集群级双栈网络从长期实验状态走向生产可用。这是当年对集群运维影响最大的网络事件之一。
2. KPNG（Kube Proxy Next Generation）：作为下一代 kube-proxy 的探索项目，KPNG 致力于在模块化与可适配性上重构传统 kube-proxy 架构，评估数据面实现的替代路径。该项目在 2021 年被正式接纳为 SIG Network 的新子项目（见下文子项目清单）。
3. AdminNetworkPolicy KEP（KEP 2091）：该 KEP 提出了面向集群管理员的、优先于普通 NetworkPolicy 的网络策略 API，旨在补足 NetworkPolicy 在"管理员级策略"场景下的能力缺口。
4. Service APIs 更名为 Gateway API 并推进到 v1alpha2：这一更名标志着 API 定位从"Service 的补充"升级为官方认可的入口流量标准，且已有十余个实现落地支持。

从仓库现状看，KPNG 的探索价值得到了历史验证：sig-network/README.md 的 Archive 一节记载，KPNG 项目规模庞大，社区在 2024 年达成一致后将其归档，但它仍是未来任何 kube-proxy 重构尝试的重要先例（prior art）。

2021 年 KEP 工作全景

年度报告按成熟度阶段完整列出了 2021 年 SIG Network 推进的 KEP，按 Stable / Beta / Alpha 分类如下：

进入 Stable 的 KEP

其中 EndpointSlices 与 Dual stack 直接对应 charter 中"端点抽象 API"与"集群连通性"的职责范围，是当年最重的两个稳定化成果。

进入 Beta 的 KEP

进入 Alpha 的 KEP

这批 KEP 覆盖了 Service 负载均衡、NetworkPolicy、DNS 等核心职责面，可以看出 SIG Network 2021 年同时在"稳定性收敛"（EndpointSlices、Dual stack GA）与"新能力探索"（端口范围、拓扑感知、混合协议 LB）两个方向上并行推进。

Gateway API 的 2021：更名、v1alpha2 与 GEP 机制

Gateway API（原 Service APIs）是 2021 年 SIG Network 投入最大的非 KEP 跟踪项目。报告明确指出，Gateway API 建立了自己的GEP（Gateway Enhancement Proposal）流程来跟踪增强项，而非使用 Kubernetes 标准 KEP 流程。2021 年的核心里程碑集中在 v1alpha2 版本：

• 迁移到新的gateway.networking.k8s.ioAPI 组：以官方 Kubernetes API 的身份呈现，这是 v1alpha2 最重要的结构性变化，为后续 v1beta1 及正式版奠定了 API 组基础。
• GEP-724：更简单的 Route-Gateway 绑定：简化了 HTTPRoute/TCPRoute 等 Route 资源与 Gateway 的绑定语义。
• GEP-709：安全的跨命名空间引用：定义了 Route 如何跨命名空间安全地引用后端服务。
• GEP-713：策略挂载（Policy attachment）：设计了将策略（如超时、重试、TLS 配置）挂载到 Gateway API 资源上的统一模型。

此外还有两项与工程化直接相关的 GEP：

• GEP-917：Gateway API 一致性测试：建立官方的 conformance testing 套件，验证不同实现是否遵守 API 语义。
• GEP-922：一致性测试的版本化：为一致性测试定义版本管理机制，使测试结果可在实现版本间追溯。
• Validating admission webhook：通过准入校验 Webhook 在资源创建/更新时提前拦截非法配置。

在 v1alpha2 落地后，团队随即瞄准v1beta1 里程碑继续推进。年度报告中"Service APIs 更名为 Gateway API，推进到 v1alpha2，并被十余个实现支持"的表述，说明了该项目在当时已具备相当的实施生态。

项目健康：ingress-nginx 的隐忧与社区治理现状

ingress-nginx 的健康度评估

报告用较大篇幅评估了 ingress-nginx 子项目的健康状况，这也是当年最受关注的项目治理话题：

• 社区建设有所起色：包括 F5 在内的多家公司人员在 Slack 和 issue 中提供支持；
• 建立了每两周一次的 issue/PR 优先级讨论例会，常规参与 6 人；
• 但开发节奏缓慢：实际维护代码的开发者仅 2～3 人，主要担忧在于 Gateway API 发布后，作为官方子项目的 ingress-nginx 无法及时支持；
• 过去一年发现并修复了3 个 CVE，凸显了拆分控制面与数据面的紧迫性；
• 团队计划先做首次控制面/数据面拆分以便支持 Gateway API，之后再与 KPNG 联合，在 ingress-nginx 中采用类似思路。

这段评估完整保留了报告原文的所有信息点，是理解当年 Kubernetes 入口流量生态格局（Ingress 与 Gateway API 的交接）的重要一手材料。

社区参与与度量

• 是否监控社区健康指标：未监控指标或健康统计；
• 是否有 SIG 专属 CONTRIBUTING.md：没有，依赖社区通用 CONTRIBUTING.md 与 contributors/guide；
• 是否有特殊审查/批准要求：无特殊要求；
• 是否有多公司贡献者：是，既有长期贡献者也有一次性贡献者，来自多家公司；
• 端用户/公司的额外贡献方式：始终需要额外的代码与 KEP 审查者，以及上文所述人手不足子项目的维护者。

成员规模数据

报告给出了 2021 年的量化数据：

这些数据可对照 sigs.yaml 中 SIG Network 的 leadership 配置（chairs、tech leads、emeritus leads）交叉阅读，理解 SIG 的治理结构与实际运营规模。

子项目与工作组的组织结构变化

2021 年新增子项目

• kpng：下一代 kube-proxy 探索项目，详见 sig-network/README.md 的 Subprojects 章节（#kpng）；
• gateway-api：Gateway API 项目正式成为 SIG Network 子项目，README 的#gateway-api一节列出了其 leads（Ricardo Katz、Rob Scott、Nick Young）及 owners（conformance-images、gwctl、ingress2gateway 等仓库），并与 sigs.yaml 中的登记保持一致。

持续运营的子项目

2021 年继续运营的子项目共 7 个，均可在 sig-network/README.md 中查到对应的 OWNERS 与描述：

• cluster-proportional-autoscaler（报告原文误标为 cluster-proportional-vertical-autoscaler 的链接，实际两者分别登记）
• cluster-proportional-vertical-autoscaler
• external-dns
• ingress
• iptables-wrappers
• kube-dns
• network-policy
• pod-networking

从 sigs.yaml 的当前登记看，SIG Network 的子项目版图较 2021 年已显著扩张（新增 kindnet、knftables、multi-network、gateway-api-inference-extension、node-ipam-controller 等），且 kube-dns 在 README 中被标注为已弃用（仅到 Kubernetes 1.40 前仍可能发布 CVE 修复版本，多数集群已转向 CoreDNS）——这些后续演化均可在仓库中直接核实。

2021 年新增的工作组

• WG IoT Edge：见 archive/wg-iot-edge/；
• WG Multitenancy：见 archive/wg-multitenancy/；
• WG Policy：见 archive/wg-policy/；
• WG Structured Logging：该工作组保留了完整的年度报告链，2021 年报告见 archive/wg-structured-logging/annual-report-2021.md。

值得注意的是，这四者在当前仓库中均已进入archive/目录，这与 Kubernetes 社区"工作组完成使命后归档"的生命周期机制一致，也印证了年度报告中工作组条目作为组织结构史料的参考价值。

年度运营清单（Operational）

报告末尾按 committee-steering/governance/sig-governance.md 定义的运营职责逐项自查：

• sig-network/README.md 已核对准确性并按需更新；
• CONTRIBUTING.md 已核对（SIG 无专属版本，沿用社区通用贡献指南）；
• sigs.yaml 中的子项目列表及关联 OWNERS 文件待核对更新；
• sigs.yaml 中的 SIG 领导（chairs、tech leads、子项目 owners）准确且活跃；
• 2021 年会议纪要与录像已从 sig-network/README.md 链接并更新；
• 2021 年社区级更新（KubeCon NA 2021、KubeCon EU 2021 的 SIG Network 更新录播等）。

这份自查清单展示了 Kubernetes SIG 年度运营的标准动作——README、CONTRIBUTING、sigs.yaml、会议纪要四类资产必须在每年年底复核一遍，这也是社区治理透明化的具体体现。相关治理模板与要求可进一步参阅 committee-steering/governance/sig-governance.md 与 governance.md。

小结

回顾 sig-network/annual-report-2021.md，2021 年是 Kubernetes 网络能力"新旧交替"的关键一年：双栈网络与 EndpointSlices 完成稳定化收尾，Gateway API 完成更名并确立 v1alpha2 与 GEP 机制，AdminNetworkPolicy 开启管理员级策略的探索，同时 KPNG 为 kube-proxy 的未来形态积累了重要先例。而 ingress-nginx 的维护人力与 CVE 压力、子项目健康度评估、成员规模数据等治理信息，则让这份报告不仅是功能清单，更是观察 SIG Network 工程投入与社区生态的窗口。读者可将本文与仓库中的 sig-network/charter.md、sig-network/README.md 以及 sigs.yaml 对照阅读，还原 2021 年 Kubernetes 网络的完整图景。

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