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 是什么使命与定位SIGSpecial 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 流程。二、ScopeSIG Network 的管辖范围2.1 管辖主题In scope章程将 SIG Network 的管辖范围归纳为以下主题这些主题共同构成了 Kubernetes 网络能力的全部横向切面主题含义Networking control plane and data paths网络控制面与数据面路径Network service abstractions网络服务抽象如 ServiceService discovery (DNS)服务发现DNSService load balancing (L4, L7)四层与七层服务负载均衡Network security and identity网络安全与身份如 NetworkPolicyCluster connectivity集群连通性Cross-cutting concerns such as scalability可扩展性等横切关注点Metrics and monitoring associated with networking components网络组件的指标与监控Multi-cluster networking多集群网络与 sig-multicluster 共担值得注意的是两个细节可扩展性被列为横切关注点网络是集群中最早遭遇规模瓶颈的子系统之一如 Service 数量、Endpoint 数量、iptables 规则膨胀因此章程明确将 scalability 纳入 SIG Network 的职责。多集群网络是与 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 月底停止维护并退役InGateIngress 与 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 pointsCNIContainer Network InterfaceKubernetes 网络模型与第三方网络插件Calico、Cilium 等的集成点。CRIContainer Runtime Interface与 sig-node 共担。CRI 本身定义容器运行时接口网络命名空间与 Pod 网络的生命周期管理横跨 kubeletsig-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 Management3.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 的通用定义Chair2 人以上组织与协调者负责 SIG 运营与对外沟通。具体职责包括组织例会并确保 sigs.yaml 中的子项目与会议信息最新、与 Tech Leads 共同识别并跟踪当前版本的增强项元数据并作为发布团队的联络人、组织 KubeCon 的 Intro 与 Deep Dive 内容、录制会议、协调赞助的工作组向 SIG 与社区汇报、撰写年度报告等。Tech Lead2 人以上技术决策者必须批准与促成新子项目的创建、批准与促成现有子项目的退役、解决跨子项目与跨 SIG 的技术问题、审查与批准 SIG 增强提案。当前 sigs.yaml 中记录的 SIG Network 领导层为ChairsBowei DuGoogle、Guilherme CassolatoRed Hat、Michael ZappaMicrosoftTech LeadsAntonio OjeaGoogle、Dan WinshipRed Hat、Tim HockinGoogleEmeritus Leads名誉离任Casey Davenport、Dan Williams、Shane Utt3.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 中的子项目清单则是实然。将两者对照可以看到章程中的每一项技术资产在现实中都有明确的子项目承载章程中的管辖类别对应子项目见 sigs.yaml 与 README.mdServices / kube-proxygateway-api含 kubernetes/pkg/proxy、endpoint controller、node-ipam-controllerIngressingressingress-nginx、ingress-gce、ingress-controller-conformance、gateway-apiNetwork Policynetwork-policykube-network-policies、network-policy-api 等Cluster DNSkube-dns、node-local-dns、external-dnsPod 网络 / CNI 集成pod-networkingcni-dra-driver、ip-masq-agent、nat64、kindnet、kubernetes-network-drivers、multi-network网络工具链iptables-wrappers、knftables、cluster-proportional-autoscaler、cluster-proportional-vertical-autoscalerAI/Agent 网络gateway-api-inference-extension、kube-agentic-networking、wg-ai-gatewaySIG Network 还赞助了三个工作组Working Groupwg-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 社区的治理体系中具有实际的约束与路由价值Issue/PR 路由依据任何打上sig/network标签的问题都会进入 SIG Network 的 triage 流程对应 GitHub Teams 中的 sig-network-bugs、sig-network-pr-reviews 等团队见 README.md。KEP 归属判定章程的 Scope 是判断这个增强提案该交给哪个 SIG 审查的第一依据。例如 2025 年 SIG Network 的 KEP 工作覆盖 v1.33Multiple Service CIDRs、Topology Aware Hints、nftables 后端 kube-proxy、Traffic Distribution、v1.34Relaxed Service 名称校验、Relaxed DNS 搜索串校验与 v1.35Pod hostname FQDN、PreferSameZone/PreferSameNode 流量分布详见 annual-report-2025.md。年度健康检查根据 committee-steering/governance/annual-reports.mdSIG 每年需完成年度报告供指导委员会进行健康检查章程则是年度报告中回顾与更新治理依据的基准。子项目创建/退役的决策权章程明确规定子项目的创建决策权在 Tech Leads这保证了网络领域新增代码资产如 2025 年新增的 kindnet、kube-agentic-networking、kubernetes-network-drivers都有清晰的归属与技术把关。六、与其他治理文档的关系要完整理解 SIG Network 章程可以将其放入 Kubernetes 治理文档的体系中对照阅读文档作用相对路径SIG Network Charter定义 SIG Network 的管辖范围与角色安排本文主体sig-network/charter.mdSIG 治理通用规范定义所有 SIG 的 Chair/Tech Lead/Subproject Lead 角色与运作要求committee-steering/governance/sig-governance.mdSIG 治理要求清单角色、组织管理、项目管理、技术流程的 MUST/SHOULD/MAY 检查清单committee-steering/governance/sig-governance-requirements.mdSIG Charter 模板各 SIG 章程的统一编写模板SIG Network 章程即依此结构撰写committee-steering/governance/sig-charter-template.mdSIG 元数据所有 SIG/WG 的子项目、领导层、会议、联系人权威清单sigs.yamlSIG Network 落地信息会议安排、领导层、联系人、子项目与职责领域sig-network/README.md对照 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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 是什么使命与定位SIGSpecial 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 流程。二、ScopeSIG Network 的管辖范围2.1 管辖主题In scope章程将 SIG Network 的管辖范围归纳为以下主题这些主题共同构成了 Kubernetes 网络能力的全部横向切面主题含义Networking control plane and data paths网络控制面与数据面路径Network service abstractions网络服务抽象如 ServiceService discovery (DNS)服务发现DNSService load balancing (L4, L7)四层与七层服务负载均衡Network security and identity网络安全与身份如 NetworkPolicyCluster connectivity集群连通性Cross-cutting concerns such as scalability可扩展性等横切关注点Metrics and monitoring associated with networking components网络组件的指标与监控Multi-cluster networking多集群网络与 sig-multicluster 共担值得注意的是两个细节可扩展性被列为横切关注点网络是集群中最早遭遇规模瓶颈的子系统之一如 Service 数量、Endpoint 数量、iptables 规则膨胀因此章程明确将 scalability 纳入 SIG Network 的职责。多集群网络是与 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 月底停止维护并退役InGateIngress 与 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 pointsCNIContainer Network InterfaceKubernetes 网络模型与第三方网络插件Calico、Cilium 等的集成点。CRIContainer Runtime Interface与 sig-node 共担。CRI 本身定义容器运行时接口网络命名空间与 Pod 网络的生命周期管理横跨 kubeletsig-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 Management3.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 的通用定义Chair2 人以上组织与协调者负责 SIG 运营与对外沟通。具体职责包括组织例会并确保 sigs.yaml 中的子项目与会议信息最新、与 Tech Leads 共同识别并跟踪当前版本的增强项元数据并作为发布团队的联络人、组织 KubeCon 的 Intro 与 Deep Dive 内容、录制会议、协调赞助的工作组向 SIG 与社区汇报、撰写年度报告等。Tech Lead2 人以上技术决策者必须批准与促成新子项目的创建、批准与促成现有子项目的退役、解决跨子项目与跨 SIG 的技术问题、审查与批准 SIG 增强提案。当前 sigs.yaml 中记录的 SIG Network 领导层为ChairsBowei DuGoogle、Guilherme CassolatoRed Hat、Michael ZappaMicrosoftTech LeadsAntonio OjeaGoogle、Dan WinshipRed Hat、Tim HockinGoogleEmeritus Leads名誉离任Casey Davenport、Dan Williams、Shane Utt3.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 中的子项目清单则是实然。将两者对照可以看到章程中的每一项技术资产在现实中都有明确的子项目承载章程中的管辖类别对应子项目见 sigs.yaml 与 README.mdServices / kube-proxygateway-api含 kubernetes/pkg/proxy、endpoint controller、node-ipam-controllerIngressingressingress-nginx、ingress-gce、ingress-controller-conformance、gateway-apiNetwork Policynetwork-policykube-network-policies、network-policy-api 等Cluster DNSkube-dns、node-local-dns、external-dnsPod 网络 / CNI 集成pod-networkingcni-dra-driver、ip-masq-agent、nat64、kindnet、kubernetes-network-drivers、multi-network网络工具链iptables-wrappers、knftables、cluster-proportional-autoscaler、cluster-proportional-vertical-autoscalerAI/Agent 网络gateway-api-inference-extension、kube-agentic-networking、wg-ai-gatewaySIG Network 还赞助了三个工作组Working Groupwg-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 社区的治理体系中具有实际的约束与路由价值Issue/PR 路由依据任何打上sig/network标签的问题都会进入 SIG Network 的 triage 流程对应 GitHub Teams 中的 sig-network-bugs、sig-network-pr-reviews 等团队见 README.md。KEP 归属判定章程的 Scope 是判断这个增强提案该交给哪个 SIG 审查的第一依据。例如 2025 年 SIG Network 的 KEP 工作覆盖 v1.33Multiple Service CIDRs、Topology Aware Hints、nftables 后端 kube-proxy、Traffic Distribution、v1.34Relaxed Service 名称校验、Relaxed DNS 搜索串校验与 v1.35Pod hostname FQDN、PreferSameZone/PreferSameNode 流量分布详见 annual-report-2025.md。年度健康检查根据 committee-steering/governance/annual-reports.mdSIG 每年需完成年度报告供指导委员会进行健康检查章程则是年度报告中回顾与更新治理依据的基准。子项目创建/退役的决策权章程明确规定子项目的创建决策权在 Tech Leads这保证了网络领域新增代码资产如 2025 年新增的 kindnet、kube-agentic-networking、kubernetes-network-drivers都有清晰的归属与技术把关。六、与其他治理文档的关系要完整理解 SIG Network 章程可以将其放入 Kubernetes 治理文档的体系中对照阅读文档作用相对路径SIG Network Charter定义 SIG Network 的管辖范围与角色安排本文主体sig-network/charter.mdSIG 治理通用规范定义所有 SIG 的 Chair/Tech Lead/Subproject Lead 角色与运作要求committee-steering/governance/sig-governance.mdSIG 治理要求清单角色、组织管理、项目管理、技术流程的 MUST/SHOULD/MAY 检查清单committee-steering/governance/sig-governance-requirements.mdSIG Charter 模板各 SIG 章程的统一编写模板SIG Network 章程即依此结构撰写committee-steering/governance/sig-charter-template.mdSIG 元数据所有 SIG/WG 的子项目、领导层、会议、联系人权威清单sigs.yamlSIG Network 落地信息会议安排、领导层、联系人、子项目与职责领域sig-network/README.md对照 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
