企业官网建设流程全解析

Kubernetes SIG Network 章程深度解读：网络组件管辖范围、API 边界与治理机制

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

本文以 Kubernetes 社区仓库中的 SIG Network Charter 为骨架，结合 SIG Network README、sigs.yaml 与 SIG 治理文档 等仓库资料，系统梳理 SIG Network 负责的组件、接口、API 边界、跨 SIG 协作关系以及角色治理机制，帮助读者快速定位"某个网络能力该由谁负责、归口到哪个子项目、如何参与治理"。

一、SIG Network 是什么：使命与定位

SIG（Special Interest Group）是 Kubernetes 社区按主题划分的核心协作单元。根据仓库根目录的 governance.md，"每个可识别的项目子部分（GitHub 组织、仓库、子目录、API、测试、Issue、PR）都应由某个 SIG 拥有"，而 SIG Network 正是网络这个垂直领域的归属方——它与 Storage、Node、Scheduling 一样属于垂直型 SIG，与横向的 Scalability、Architecture 形成互补。

SIG Network Charter 开篇即明确了该 SIG 的核心使命：

SIG Network 负责向 Kubernetes 用户和工作负载暴露网络能力的组件、接口与 API，并为其提供部分参考实现——例如 kube-proxy 就是 Service API 的参考实现。

这句话点出了 SIG Network 的双重身份：它既是网络能力标准（API/接口）的制定者，也是参考实现（reference implementations）的维护者。kube-proxy 被特别点名作为"Service API 参考实现"，说明该 SIG 的职责贯穿从控制面（API 定义）到数据面（实际转发）的完整链路。

在 sigs.yaml 中，SIG Network 的 mission statement 被简洁地定义为 "Covers networking in Kubernetes"，并关联了 charter_link: charter.md 与标签label: network——所有打上sig/network标签的 Issue/PR 都会自动路由到该 SIG 的 triage 流程。

二、Scope：SIG Network 的管辖范围

2.1 管辖主题（In scope）

章程将 SIG Network 的管辖范围归纳为以下主题，这些主题共同构成了 Kubernetes 网络能力的全部横向切面：

值得注意的是两个细节：

1. 可扩展性被列为横切关注点：网络是集群中最早遭遇规模瓶颈的子系统之一（如 Service 数量、Endpoint 数量、iptables 规则膨胀），因此章程明确将 scalability 纳入 SIG Network 的职责。
2. 多集群网络是与 sig-multicluster 共担的：章程使用"shared responsibility with sig-multicluster"的表述，对应 sig-multicluster/README.md 中"管理多个 Kubernetes 集群及其中应用"的使命。这意味着多集群领域的 API（如 mcs-api、work-api）由 sig-multicluster 主导，而底层网络数据路径仍由 SIG Network 负责，二者以协作而非竞争的方式划分边界。

2.2 代码、二进制与服务（Code, Binaries and Services）

章程对管辖范围内的具体代码资产做了结构化归类，这是整个章程中技术含量最高的部分，几乎覆盖了 Kubernetes 网络的全部核心 API 与实现：

Services（服务抽象与负载均衡）

• 端点分组 API：[EndpointSlices] 与更早期的 [Endpoints] API。根据 SIG Network 2025 年度报告，Endpoints API 正在进入弃用流程（2025 年官方博客发布了 "Endpoints Deprecation"），社区正在向 EndpointSlices 迁移。
• L3/4 负载均衡 API：[Service] 与 [Gateway API]。Gateway API 是新一代的、面向角色的服务网络 API 家族，其子项目由 kubernetes-sigs/gateway-api 维护。
• 参考实现：kube-proxy。正如章程所言，kube-proxy 是 Service API 的参考实现，负责将 Service 的虚拟 IP/端口映射到实际 Pod 端点。

Ingress（七层入口负载均衡）

• API 定义：经典 [Ingress] 资源，以及作为演进方向的 [Gateway API]；此外还有面向 AI 推理负载的 [Gateway API Inference Extension]，后者在 2025 年达到 v1.0 里程碑并发布了 v1.3.1。
• API 实现：ingress-nginx 与 InGate。需要说明的是，根据 2025 年度报告，ingress-nginx 因安全漏洞与维护力量不足，计划于 2026 年 3 月底停止维护并退役；InGate（Ingress 与 Gateway API 控制器）也已在 2025 年归档。这些事实表明：SIG Network 的 API 定义是长期稳定的，而具体实现则在持续演进与汰换。

Network Policy（网络安全策略）

• API 定义：[NetworkPolicy]（面向租户的命名空间级策略），以及面向集群管理员的 [AdminNetworkPolicy] 与 [BaselineAdminNetworkPolicy]。根据 2025 年度报告，AdminNetworkPolicy与BaselineNetworkPolicy正被合并为单一的ClusterNetworkPolicy资源，Beta 候选 API 已定稿，并有三个可运行的生态实现。
• 参考实现：kube-network-policies。

Cluster DNS（集群 DNS）

集群 DNS 是 Kubernetes 服务发现的基础设施。虽然章程正文只提了一句，但 sigs.yaml 的 kube-dns 子项目描述补充了关键背景：kube-dns 是最早的 Service DNS 实现，现已弃用（仅在有 CVE 修复时发布新版本，直至 Kubernetes 1.40），绝大多数集群已改用 CoreDNS；同时 node-local-dns 子项目负责在节点上缓存 DNS 查询以降低延迟。

集成点（Integration points）

• CNI（Container Network Interface）：Kubernetes 网络模型与第三方网络插件（Calico、Cilium 等）的集成点。
• CRI（Container Runtime Interface）：与 sig-node 共担。CRI 本身定义容器运行时接口，网络命名空间与 Pod 网络的生命周期管理横跨 kubelet（sig-node）与网络插件（SIG Network）。
• 云提供商网络集成：与 sig-cloud-provider 共担，涉及 LoadBalancer 类型的 Service 在各大云平台上的实现。

2.3 不在管辖范围（Out of scope）

章程用两个条目明确划定了边界：

• CNI 规范本身：由 Kubernetes 项目之外的独立组织维护；
• CNI 规范的特定实现：即具体的 CNI 插件（Calico、Cilium、Flannel 等）不属于 SIG Network 的管辖。

这是章程中最清晰的"负面清单"：SIG Network 负责集成点（如何让 Kubernetes 与 CNI 对接），但不拥有 CNI 协议规范，也不拥有任何具体插件。对开发者而言，这意味着"我的 CNI 插件出了问题"应该去找插件厂商而非 SIG Network，而"Kubernetes 调用 CNI 的方式出了问题"才属于 SIG Network。

三、角色与组织管理（Roles and Organization Management）

3.1 治理基础：遵循 sig-governance

章程声明 SIG Network 完全遵循 sig-governance.md 中定义的角色与组织管理约定，并**选择加入（opt-in）**对 sig-governance 的更新与修改。这意味着 SIG Network 不维护自己的一套治理规则，而是跟随社区统一的治理演进。

具体到角色层面，SIG Network 章程有三条明确的"None"声明：

• Chairs 的额外职责：无
• Tech Leads 的额外职责：无
• 对 sig-governance 的偏离：无

也就是说，SIG Network 的角色职责完全以 sig-governance.md 的通用定义为准。根据该文档，社区对 SIG 的核心要求包括：拥有已批准的章程、至少每 3 周开一次会（11、12 月除外）、维护公开的会议纪要、录制并公开会议、完成年度报告、参与发布计划会议与回顾、确保相关工作发生在项目拥有的 GitHub 组织与仓库中、使用公开论坛而非私下邮件协作、追踪并识别所有 KEP 等。

3.2 角色构成：Chairs 与 Tech Leads

对照 sig-governance.md 的通用定义：

• Chair（2 人以上）：组织与协调者，负责 SIG 运营与对外沟通。具体职责包括：组织例会并确保 sigs.yaml 中的子项目与会议信息最新、与 Tech Leads 共同识别并跟踪当前版本的增强项元数据并作为发布团队的联络人、组织 KubeCon 的 Intro 与 Deep Dive 内容、录制会议、协调赞助的工作组向 SIG 与社区汇报、撰写年度报告等。
• Tech Lead（2 人以上）：技术决策者，必须批准与促成新子项目的创建、批准与促成现有子项目的退役、解决跨子项目与跨 SIG 的技术问题、审查与批准 SIG 增强提案。

当前 sigs.yaml 中记录的 SIG Network 领导层为：

• Chairs：Bowei Du（Google）、Guilherme Cassolato（Red Hat）、Michael Zappa（Microsoft）
• Tech Leads：Antonio Ojea（Google）、Dan Winship（Red Hat）、Tim Hockin（Google）
• Emeritus Leads（名誉离任）：Casey Davenport、Dan Williams、Shane Utt

3.3 子项目创建（Subproject Creation）

章程在治理部分明确了子项目的创建权归属：由 SIG Technical Leads（技术负责人）决定，这与 sig-governance.md 中"子项目可通过 SIG Tech Leads 的简单多数投票创建"的通用规则完全一致。

创建子项目时必须更新 sigs.yaml 并维护对应的 OWNERS 文件。这一点在 SIG Network 的 OWNERS 文件中有直接体现——该文件声明 reviewers 与 approvers 均为sig-network-leads别名，并打上sig/network标签；sig-network-leads别名本身定义在仓库根目录的 OWNERS_ALIASES 中。

四、从章程到落地：子项目与代码归属

章程定义的 Scope 是"应然"，而 sigs.yaml 中的子项目清单则是"实然"。将两者对照，可以看到章程中的每一项技术资产在现实中都有明确的子项目承载：

SIG Network 还赞助了三个工作组（Working Group）：wg-ai-gateway、wg-device-management、wg-node-lifecycle——工作组的职责是围绕跨越多个 SIG 的短期议题进行协作，与子项目的长期代码归属不同。

对于子项目负责人，README.md 的 CUSTOM CONTENT 部分补充了 SIG Network 特有的额外职责要求，这些要求实际上是章程"Subproject Creation"条款的延伸执行细则：

• 透明的规划与沟通：必须通过 GitHub project boards、KEP 或增强提案（如 Gateway API 的 GEP、Network Policy API 的 NPEP）公开项目的历史与未来计划；必须创建并维护命名规则为#sig-network-<subproject>的公开 Slack 频道；建议在 SIG Network 日历上维护定期公开的 Zoom 同步会；通过定期 Issue 分类、PR 审查、CI 健康监控与 TestGrid 检查保持项目健康；拥有k8s.io组 CRD 的项目必须走 API 审查流程。
• 定期项目更新：子项目负责人必须每季度（或按需）通过 SIG Network 邮件列表向更广泛的社区汇报项目状态、重要发布与事件，并建议在 SIG Network 例会上同步汇报。

五、章程的约束力：为什么它值得被认真对待

SIG Network 章程并非一份装饰性文档，它在 Kubernetes 社区的治理体系中具有实际的约束与路由价值：

1. Issue/PR 路由依据：任何打上sig/network标签的问题都会进入 SIG Network 的 triage 流程（对应 GitHub Teams 中的 sig-network-bugs、sig-network-pr-reviews 等团队，见 README.md）。
2. KEP 归属判定：章程的 Scope 是判断"这个增强提案该交给哪个 SIG 审查"的第一依据。例如 2025 年 SIG Network 的 KEP 工作覆盖 v1.33（Multiple Service CIDRs、Topology Aware Hints、nftables 后端 kube-proxy、Traffic Distribution）、v1.34（Relaxed Service 名称校验、Relaxed DNS 搜索串校验）与 v1.35（Pod hostname FQDN、PreferSameZone/PreferSameNode 流量分布），详见 annual-report-2025.md。
3. 年度健康检查：根据 committee-steering/governance/annual-reports.md，SIG 每年需完成年度报告供指导委员会进行健康检查，章程则是年度报告中回顾与更新治理依据的基准。
4. 子项目创建/退役的决策权：章程明确规定子项目的创建决策权在 Tech Leads，这保证了网络领域新增代码资产（如 2025 年新增的 kindnet、kube-agentic-networking、kubernetes-network-drivers）都有清晰的归属与技术把关。

六、与其他治理文档的关系

要完整理解 SIG Network 章程，可以将其放入 Kubernetes 治理文档的体系中对照阅读：

对照 sig-charter-template.md 可以发现，SIG Network 章程严格遵循了模板的章节结构（Scope → In scope → Out of scope → Roles and Organization Management → Subproject Creation），并在模板基础上填充了真实的组件清单与"None"治理声明，是研究 Kubernetes SIG 章程编写范式的标准样本。

七、小结

SIG Network Charter 以极精炼的篇幅完成了三件关键事：划清管辖边界（哪些组件、API、实现归 SIG Network，哪些明确不归它管）、建立治理框架（完全遵循 sig-governance，无额外职责与偏离，子项目创建权归 Tech Leads）、衔接落地机制（通过 sigs.yaml 与 OWNERS 文件将 Scope 映射到具体子项目与代码仓库）。对于想理解 Kubernetes 网络生态的开发者，这份章程提供了最权威的"网络能力地图"；对于想在网络领域参与社区治理的贡献者，它是判断问题归属、选择贡献入口的第一份必读文档。

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