Kubernetes SIG Network 贡献指南从代码提交到 KEP 增强提案的完整路径【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communitySIG Network 是 Kubernetes 社区中负责集群内外全部网络能力的特别兴趣小组覆盖 Service、Ingress、Network Policy、DNS、CNI 等核心子系统。本文以仓库内 sig-network/CONTRIBUTING.md 为骨架结合 charter、README 与 sigs.yaml 等治理文件系统讲解进入 SIG Network 的正确姿势普通代码贡献走哪条路、增强功能必须走哪条路以及该 SIG 反复强调的What / Why / Who三问方法论。读完本文你将能准确判断自己的改动属于代码提交还是 KEP 增强提案并掌握在大型开源社区中把想法推进到落地的协作节奏。SIG Network 负责什么先认清边界再动手贡献之前先明确 SIG Network 的职责范围这直接决定你的议题该不该投递到这里。根据 sig-network/charter.md 的 Scope 定义SIG Network 负责向 Kubernetes 用户与工作负载暴露网络能力的组件、接口和 API并提供部分参考实现例如 kube-proxy 就是 Service API 的参考实现。In scopeSIG 拥有权的主题网络控制面与数据路径Networking control plane and data paths网络服务抽象Network service abstractions服务发现DNS服务负载均衡L4、L7网络安全与身份Network security and identity集群连通性Cluster connectivity可扩展性等横切关注点与网络组件相关的指标与监控多集群网络与 sig-multicluster 共同负责在代码、二进制与服务工作层面charter 进一步细分为四组Services定义与分组网络端点的 API如 EndpointSlices、传统 Endpoints 的 [Service] 相关 APIL3/L4 负载均衡 APIService、Gateway API及其参考实现kube-proxyIngressIngress、Gateway API、Gateway API Inference Extension 等入口负载均衡 API以及 ingress-nginx、InGate 等 API 实现Network PolicyNetworkPolicy、AdminNetworkPolicy、BaselineAdminNetworkPolicy 等策略 API 及其参考实现 kube-network-policiesCluster DNS集群域名解析与 CNI、CRI与 [sig-node] 协作、云厂商网络集成与 [sig-cloud-provider] 协作的对接点Out of scope明确不属于 SIG NetworkCNI 规范本身由 Kubernetes 项目之外维护CNI 规范的具体实现不属于本 SIG 的所有权范围判断议题归属时charter 的 in/out of scope 就是第一道过滤器。议题若落在 Out of scope应在投入大量精力前先确认是否找错了组织。找到组织沟通渠道与求助方式SIG Network 的 README 与 CONTRIBUTING.md 都强调卡住时不要独自硬扛随时到 Kubernetes Slack 的#sig-network频道求助。围绕该 SIG 的日常沟通矩阵包括Slack#sig-network主频道以及各子项目频道如#sig-network-gateway-api、#sig-network-policy-api邮件列表SIG Network Mailing List用于公告、季度汇报与异步讨论例会SIG Network Meeting双周、Gateway API Meeting美洲/欧洲、Network Policy API Meeting、SIG Network Multi-Network Meeting、Ingress NGINX Meeting 等全部公开并留有会议纪要与录制GitHub Teams按职责分流的自动化团队包括 API 评审sig-network-api-reviews、Bug 分诊sig-network-bugs、功能请求sig-network-feature-requests、PR 评审sig-network-pr-reviews、设计提案sig-network-proposals、测试失败分诊sig-network-test-failures这些团队信息并非手写维护。从仓库结构看sig-network/README.md 文件头明确标注本文件为自动生成请勿直接编辑应修改项目根目录的 sigs.yaml——SIG 的例会、领导层、GitHub 团队、子项目清单全部集中定义在 sigs.yaml 的dir: sig-network段约 2281 行起再由 generator 渲染出 README。这意味着你看到的一切联系方式都以数据源形式可追溯。另外sig-network/OWNERS 定义了本目录的评审权限reviewers 与 approvers 均为sig-network-leads即 SIG 的 Chair 与 Tech Lead 集合并统一打上sig/network标签。向该 SIG 相关仓库提交 PR 时机器人会据此自动分配评审人并打标签。普通代码贡献走 Kubernetes Contributor Guide 标准路径如果你的目标是为 Kubernetes 提交普通代码改动CONTRIBUTING.md 明确指引直接查阅 Kubernetes Contributor Guide仓库内即 contributors/guide/README.md这是整个 Kubernetes 项目如何贡献代码的单一事实来源。前置条件首次提交前务必完成注册 GitHub 账号所有贡献都基于 GitHub PR 流程展开签署 CLA未签署 CLA 是新手 PR 最常见的问题之一签署与排障细节见 CLA.md遵守行为准则阅读并遵守 code-of-conduct.md 与社区价值观PR 流程要点从 contributors/guide/contributing.md 可以梳理出完整链路GitHub workflowfork 分支 PR→ 机器人自动打标签 → 代码评审 → 测试与合入。新手常踩的坑包括CLA 未提前签署见 CLA.md 排障找不到正确的 SIG 或 reviewer——解决方法是遵循 SIG 各自的 CONTRIBUTING 指南本文正是 SIG Network 的那一份PR 上出现与改动无关的测试失败test flakes见 contributors/devel/sig-testing 下的相关文档未遵循 scalability-good-practices.md增强功能必须先走 KEP 提案流程代码改动之外的新功能enhancement走的是另一条完全不同的路。CONTRIBUTING.md 给出的判断方法是先确认你的东西到底算不算 enhancement——例如引入新的 API、改变现有 API 语义、需要新的 feature gate、影响集群升级兼容性等通常都算。确认后遵循标准的 Kubernetes Enhancement ProposalKEP流程提交提案。文档对这条路径给出了一条醒目的忠告注意这个流程可能投入巨大动手前务必深思。取决于内容它可能需要耗费数年才能落地。这不是危言耸听。一个 KEP 从孵化、alpha、beta 到 GA要经历设计评审、API 评审Kubernetes 有专门的 sig-architecture/api-review-process.md 规范、跨 SIG 共识、多版本迭代。因此文档强烈建议不要在初期纠结How怎么实现而是先围绕What / Why / Who三个问题达成共识。核心方法论先问What / Why / Who再谈How这是 CONTRIBUTING.md 中最具 SIG Network 特色、也最值得任何开源贡献者反复咀嚼的部分。SIG Network 高度建议在早期阶段刻意回避How will this be implemented?把精力依次放在三件事上问题要回答的内容产出What?高层面上这是什么不涉及实现细节它达成了什么目标是什么清晰的提案定位与目标陈述Why?为什么需要它动机是什么是否具有普遍适用性令人信服的必要性论证Who?社区里还有谁需要它谁愿意加入我们一起把它做成功提案的共建者网络为什么Who?如此重要文档特别强调Who? 是极端重要的问题。如果你能拉到 1 位以上理想情况是至少 2 位志同道合的社区成员愿意与你并肩推进 KEP那将是巨大的助力。原因很现实网络功能往往横跨 kube-proxy、CNI 插件、API 服务器、控制器等多个组件单人难以完成全链路实现与评审多个维护者的背书能显著提升提案在 SIG 例会、API 评审中的可信度提案的长期演进数月乃至数年的迭代需要有人接力维护共识优先的顺序正确顺序是先围绕 What、Why、Who 取得广泛共识确认目标与动机都成立之后再讨论 How可行的实现方式。反过来如果一上来就争论技术选型比如用 iptables 还是 eBPF、放在哪个控制器里很容易在目标未定、动机未明时陷入无效内耗。文档的建议是提前加入社区Slack 频道、SIG Network 例会把想法拿到台面上讨论而不是等提案写完了才第一次亮相。在 SIG Network 内持续协作子项目负责人的额外责任如果你的提案最终落地为 SIG Network 的一个子项目README 的 Custom Content 部分还定义了子项目负责人Subproject Leads超出通用子项目定义见 governance.md的额外责任这些是提案通过后持续贡献阶段的行为准则透明规划与维护通过 GitHub project board、KEP 或自定义增强提案如 Gateway API 的 GEP、Network Policy API 的 NPEP公开历史与未来计划公共沟通渠道创建并维护命名易找的#sig-network-子项目Slack 频道并定期在 SIG Network 日历上开设公开 Zoom 同步会项目健康度定期做 issue 分诊、PR 评审、CI 健康监控与 TestGrid 检查可委托社区其他成员API 评审合规拥有k8s.io组 CRD 的项目必须走 sig-architecture/api-review-process.md定期汇报按季度或按需向 SIG Network 邮件列表汇报项目状态、重要发布与事件并在社区例会中同步一张贡献路径决策表你的改动类型路径关键动作主要参考修 bug、小改动、已有代码改进普通代码贡献签 CLA → 提 PR → 等机器人分配 reviewer → 评审合入contributors/guide/README.md新功能、新 API、语义变更、feature gateKEP 增强提案判断是否 enhancement → 写 KEP → 先共识 What/Why/Who → 再谈 How → 多版本迭代KEP 流程 本文三问方法论提案落地为子项目子项目治理建频道、开例会、季度汇报、API 评审sig-network/README.md总结进入 SIG Network 贡献本质上是一道路径选择 节奏控制的题代码贡献有标准化的 Contributor Guide 可循增强功能则必须拥抱周期漫长的 KEP 流程。而无论走哪条路SIG Network 最希望你记住的都是那句核心方法论——先对齐What与Why拉上至少两位同行者确认Who最后才轮到How。带着清晰的目标、充分的动机和一支小团队走进#sig-network频道你的提案就已经成功了一半。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考