Kubernetes 单体仓库拆分史2017 贡献者峰会 Breaking Up The Monolith 讨论实录与技术复盘【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community2017 年 12 月 5 日KubeCon 前夜Kubernetes 贡献者峰会Contributor Summit在奥斯汀举行采用非结构化非会议unconference的开放式鱼缸讨论形式详见 ContribSummitInformation.md。其中一场由 Josh Berkusjberkus与 Aaron Crickenbergerspiffxp担任记录员的圆桌——breaking-up-the-monolith.md——围绕是否以及如何拆掉 kubernetes/kubernetes 单体仓库展开了针锋相对、信息密度极高的辩论。这场讨论记录了当时项目在代码组织上的核心痛点、候选拆分清单kubectl、client-go、kubeadm、云厂商驱动等、staging 机制、发布与测试基建的缺口也直接影响了后来 Kubernetes 多仓库治理格局的形成。读完本文你将完整还原这场关键讨论的各方论点、决策脉络并结合本仓库的后续文档理解其历史走向。一、背景为什么 2017 年底必须谈拆库彼时 Kubernetes 已经拥有约 90 个仓库bgrant 在会上的原话Were already in the land of 90 repos但核心代码库 kubernetes/kubernetes 仍然是一个巨型单体仓库monorepo。会议记录开篇即点明本次讨论的三大主题构建流程build process、Issue 跟踪issue tracking、工程后勤logistics。与会者反复强调的动机可以归纳为两条主线核心无法持续以同样速度增长erictuneas the project matures the core cant keep growing at the same rate项目成熟后核心代码库的膨胀速率必须被控制开发者体验恶化mattfarina单体仓库让新贡献者难以进入 Issue 队列、难以找到可贡献的切入点difficulty to contribute pushes people away from contributingIssue 无人问津thockin主仓库中超过 6 周无人处理的 Issue 比比皆是仅 network 相关就有 400500 个被废弃的 Issue大量目录没有 OWNERS 文件spiffxp数百个目录缺乏负责人导致通知泛滥、路由混乱。这些问题的本质是仓库规模增长与治理能力之间的失衡。二、第一个问题我们是否 100% 承诺拆分单体仓库会议第一轮交锋围绕拆分意愿展开结论是**承诺拆分但必须先定义拆分意味着什么**。长期尝试维护单体仓库太昂贵了Weve been trying the monolith for so long and its too expensive但支持与反对双方提出了截然不同的视角发言者立场核心观点erictune支持有限度生态可以增长但狭义定义的核心不应继续膨胀mattfarina支持贡献难度把潜在贡献者推走clayton谨慎kubectl 永远不会更简单也许写一个新的反而更容易为什么建一个东西而不是花两倍成本建两个指拆出一个高性能 client-go 一个面向人类、可复用的重写版 client-gobburns反对声音我们从不量化拆分的成本只因为更干净就喜欢拆却没有估算人力与复杂度代价lavalamp反驳 bburns我们已经估算过成本明知会很痛苦但别无选择timstclair质疑落地没有人回答过如何把一组二进制作为一次发布交付没有统一计划测试基建如何覆盖所有组件也是未知数bburns补充质疑e2e 失败时如何定位导致失败的 commitdims / matt提出清单应该列出四五个优先级最高的外移项其中 timstclair 提出的两个问题——多仓库下的发布交付计划与测试基建覆盖——成为贯穿整场讨论、乃至之后数年 Kubernetes 代码库治理的核心难题。lavalamp 则给出了一个关键的架构设想文内标注 TODO link主仓库main repo退化为集成点二进制产物由其他仓库生产。三、第二个问题拆分到底要解决什么问题会议第二环节尝试厘清目标而非手段。两个基本假设被摆上桌面贡献者速度与新贡献者体验正相关一大团纠缠的面条big tangled ball of pasta难以贡献。围绕是否必须拆成独立仓库出现了重要的分歧与深化模块化不一定等于多仓库jberkus其他大型项目经验表明关键在于模块化架构而不必然是多个仓库在仓库内部模拟多仓库thockin与其拆库不如移动代码直到仓库内部看起来像多个子仓库——例如把 kubelet 相关逻辑全部集中到一个目录除一个 util 目录外或许本身就是一种改进先拆云厂商驱动与会共识First thing: were breaking up cloud providers, it helps let the long tail of cloud providers go out。云厂商是第一个拆出去的对象存储提供商随后也应有清晰接口明确的接口边界dchen1107时任发布经理发布管理成本巨大作为发布经理我不知道另一个仓库里有什么但清晰的 API 与接口并不需要独立仓库——她举了 Docker 与 CRI 的例子不搬仓库也拿到了干净的 API决策机制缺失robertbailey提出本议题时以为大家已达成拆分共识但显然没有需要弄清谁是决策者 / 决策者群体自动化与通知spiffxp多仓库对 GitHub 通知更友好机器人改善了自动化但未解决通知分级也许该改进通知路由而不是拆库小仓库接入门槛solly如果拆分必须让小型仓库更容易接入自动化与工具链我不该自己摸索该问谁应该有文档不能出现 Heapster 那样掉进裂缝里的仓库。bgrant 的一锤定音值得注意Were already in the land of 90 repos. We dont need to debate splitting, were already split.——从治理现实看拆分早已发生incubator、kubernetes-client 等争论的焦点其实是如何把拆分做对尤其是让 API 类型、SDK 与通用工具链真正可复用We need SDKs to build kube-style APIs。四、候选拆分清单kubectl、client-go、kubeadm 与云厂商会上形成了初步的外移候选清单这份清单与同一峰会其他分会场如 cloud-provider.md以及 2017 年 5 月领导力峰会上的 Code Organization and Release Process Improvement 高度呼应候选组件会上讨论要点后续走向以本仓库文档为据kubectlclayton 认为 kubectl 本身太大值得围绕新东西重建社区lavalamp 形容其为拉入大量包、技术难以下手的意大利面代码已在拆分依赖的过程中拥有独立仓库并迁移 Issue见 0300-0345_CODEORGANIZATION.mdclient-go已独立发布属于另一个量级的问题需另开会讨论clayton 提出高性能版 面向人类重写版双轨思路对应 kubernetes-client 多语言客户端生态kubeadm留在主仓库是为了赶上发布列车release train曾尝试移出但失败luxasLucas Käldström时任 kubeadm 负责人提出 kubeadm 仓库必须权威并能纳入构建后续成立 Kubeadm Adoption 工作组推动采纳见 archive/wg-kubeadm-adoption/README.md云厂商驱动cloud providers首要拆分对象dims 举例 Google KMS provider 被移出、gRPC 接口 PR 未进 1.9说明在树外开发更灵活同峰会 cloud-provider.md 记录了 cloud-controller-manager 拆分进展kubelet / kube-proxythockin 提出疑问拆这些能带来具体收益吗还是会带来更多痛苦我们清楚这会拖慢节奏未在本次达成共识留待后续存储提供商若拆分应有清晰接口后续由 CSI 承接同峰会 cloud-provider 讨论中亦有提及会议还记录了已完成 / 进行中的拆分成果作为可行性参考API machinerystaging 化后解除了阻塞、cloud provider、kubernetes-client 组织。bgrant 总结称monorepo 中的velocity 是静态的the velocity of things in the monorepo are static。五、绕不开的三大工程挑战发布、测试、依赖5.1 发布管理多仓库如何拼出一次发布这是 timstclair 抛出的最尖锐问题没有人回答过我们如何把一组二进制作为一次发布交付没有统一计划。其难点在于发布经理无法掌握其他仓库内容dchen1107 作为时任发布经理的切身之痛安全更新必须快速送达Cloud Foundry 两周构建流程被引为反面案例多仓库需要组装发布各组件在各自仓库测试充分后由主仓库集成组装参见 0300-0345_CODEORGANIZATION.md 中Multi-repo requirements一节luxas 特别强调 kubeadm 的攻击计划需要为多仓库做一次发布kubeadm 仓库要权威且能纳入构建。5.2 测试基建谁来测、怎么定位回归与会者担忧拆分后的测试覆盖问题timstclairhow are you actually going to get test infra to test all the thingsbburnshow do you actually find the commit that causes a failure in e2e会议结论倾向用更小、更聚焦的测试取代过度依赖 e2e 的做法Need better, smaller tests overall不要在 e2e 上验证未经文档化的功能。5.3 依赖管理godeps 的噩梦timallclair 直言我担心依赖管理godeps 已经是噩梦多仓库只会更糟。 这一担忧在后续 Kubernetes 全面转向 Go modules 后才得到缓解。此外 dims 指出 monorepo 的连带污染问题vendor 会把不关心的 SDK如 AWS SDK拖进来——如果只做 OpenStack 相关工作在主仓库里很难获得合入批准但在自己的仓库里就容易得多。六、staging 机制在拆与不拆之间的第三条路本场讨论反复出现的staging概念值得单独说明。它是 Kubernetes 在仓库内部模拟多仓库的中间态代码仍留在主仓库但按 k8s.io 包路径组织成伪仓库通过符号链接进入 vendor 目录供 Go 工具链消费再由发布机器人用git filter-branch将各 staging 目录切分成真实仓库推送到外部详见本仓库文档 contributors/devel/sig-architecture/staging.md。会上围绕 staging 的价值与边界形成了几个重要判断staging 状态是解决了一半的状态lavalampAPI machinery 正是因为到达 staging 状态而被解除了阻塞thockin 则认为 staging 已经解决了问题因为你得先把纠缠的依赖解开才能 stagingstaging 可作为已拆分的观察窗口pwittrock可以从 staging 仓库的实例中看到拆分带来的收益或问题erictune 的呼吁请把已经开工但没拆完的分拆工作做完finish some of our started-but-not-finished breakaparts同峰会 cloud-native-design-refactoring-across-k8s.md 也列出了跨仓库重构的相关 Issue 与 util 目录整合工作可视作 staging 路径上的具体任务。根据 staging.md 的记载该机制最终演化为成熟的发布机器人publishing bot体系支持多分支发布master 及 release-1.28 至 release-1.31 等、为发布仓库自动打kubernetes-前缀标签、并自 v1.17.0 起同步生成与主仓库 tag 对应的语义化v0.x.y标签以无缝衔接 Go modules。七、没有结论的结论走向软件还是发行版之问这场讨论没有形成投票式的决议但沉淀了几点关键共识拆分已既成事实争论焦点是治理bgrant我们已经有 90 个仓库主仓库将演化为集成点二进制产物由其他仓库生产lavalamp必须量化成本bburns 的我们不测量成本之问与 lavalamp我们已经估算过的回答共同指向同一个行动——拆分必须基于成本收益而非审美偏好扩展点需要接口而非拆库CRIDocker 例、cloud provider、CRD、SDK 都是不搬仓库也能拿 API的证明对基础设施的依赖会加重spiffxp增加对集成工具的依赖会带来现在没有的开销与流程但多数 OSS 从业者期望多仓库且 GitHub 通知在多仓库下更易管理自动化接入要有文档与统一入口solly不能让小仓库掉进裂缝thockin 将终极问题抛给全场我们是一个软件还是一个发行版a piece of software or a distribution——这个问题的答案决定了 monorepo 的未来形态。回望本仓库的目录结构这场 2017 年会议所讨论的分拆蓝图——kubectl 归 SIG CLI、云厂商驱动外置、client-go 独立发布、kubeadm 拥有独立工作组的采纳计划、staging 目录与发布机器人常态化——都在后续 Kubernetes 社区治理文档中得到了印证。对于研究大型开源项目代码库治理的工程师而言这份会议记录是理解monorepo 拆分之痛的第一手史料它诚实地记录了成本、分歧、技术债务与长期投入而非一份粉饰过的决策白皮书。延伸阅读本场会议原始记录breaking-up-the-monolith.md2017 年 5 月领导力峰会同主题记录0300-0345_CODEORGANIZATION.mdstaging 目录与发布机制contributors/devel/sig-architecture/staging.md云厂商拆分进展events/2017/12-contributor-summit/cloud-provider.mdkubeadm 采纳工作组archive/wg-kubeadm-adoption/README.md峰会整体信息与议程events/2017/12-contributor-summit/ContribSummitInformation.md【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 单体仓库拆分史：2017 贡献者峰会 “Breaking Up The Monolith“ 讨论实录与技术复盘
Kubernetes 单体仓库拆分史2017 贡献者峰会 Breaking Up The Monolith 讨论实录与技术复盘【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community2017 年 12 月 5 日KubeCon 前夜Kubernetes 贡献者峰会Contributor Summit在奥斯汀举行采用非结构化非会议unconference的开放式鱼缸讨论形式详见 ContribSummitInformation.md。其中一场由 Josh Berkusjberkus与 Aaron Crickenbergerspiffxp担任记录员的圆桌——breaking-up-the-monolith.md——围绕是否以及如何拆掉 kubernetes/kubernetes 单体仓库展开了针锋相对、信息密度极高的辩论。这场讨论记录了当时项目在代码组织上的核心痛点、候选拆分清单kubectl、client-go、kubeadm、云厂商驱动等、staging 机制、发布与测试基建的缺口也直接影响了后来 Kubernetes 多仓库治理格局的形成。读完本文你将完整还原这场关键讨论的各方论点、决策脉络并结合本仓库的后续文档理解其历史走向。一、背景为什么 2017 年底必须谈拆库彼时 Kubernetes 已经拥有约 90 个仓库bgrant 在会上的原话Were already in the land of 90 repos但核心代码库 kubernetes/kubernetes 仍然是一个巨型单体仓库monorepo。会议记录开篇即点明本次讨论的三大主题构建流程build process、Issue 跟踪issue tracking、工程后勤logistics。与会者反复强调的动机可以归纳为两条主线核心无法持续以同样速度增长erictuneas the project matures the core cant keep growing at the same rate项目成熟后核心代码库的膨胀速率必须被控制开发者体验恶化mattfarina单体仓库让新贡献者难以进入 Issue 队列、难以找到可贡献的切入点difficulty to contribute pushes people away from contributingIssue 无人问津thockin主仓库中超过 6 周无人处理的 Issue 比比皆是仅 network 相关就有 400500 个被废弃的 Issue大量目录没有 OWNERS 文件spiffxp数百个目录缺乏负责人导致通知泛滥、路由混乱。这些问题的本质是仓库规模增长与治理能力之间的失衡。二、第一个问题我们是否 100% 承诺拆分单体仓库会议第一轮交锋围绕拆分意愿展开结论是**承诺拆分但必须先定义拆分意味着什么**。长期尝试维护单体仓库太昂贵了Weve been trying the monolith for so long and its too expensive但支持与反对双方提出了截然不同的视角发言者立场核心观点erictune支持有限度生态可以增长但狭义定义的核心不应继续膨胀mattfarina支持贡献难度把潜在贡献者推走clayton谨慎kubectl 永远不会更简单也许写一个新的反而更容易为什么建一个东西而不是花两倍成本建两个指拆出一个高性能 client-go 一个面向人类、可复用的重写版 client-gobburns反对声音我们从不量化拆分的成本只因为更干净就喜欢拆却没有估算人力与复杂度代价lavalamp反驳 bburns我们已经估算过成本明知会很痛苦但别无选择timstclair质疑落地没有人回答过如何把一组二进制作为一次发布交付没有统一计划测试基建如何覆盖所有组件也是未知数bburns补充质疑e2e 失败时如何定位导致失败的 commitdims / matt提出清单应该列出四五个优先级最高的外移项其中 timstclair 提出的两个问题——多仓库下的发布交付计划与测试基建覆盖——成为贯穿整场讨论、乃至之后数年 Kubernetes 代码库治理的核心难题。lavalamp 则给出了一个关键的架构设想文内标注 TODO link主仓库main repo退化为集成点二进制产物由其他仓库生产。三、第二个问题拆分到底要解决什么问题会议第二环节尝试厘清目标而非手段。两个基本假设被摆上桌面贡献者速度与新贡献者体验正相关一大团纠缠的面条big tangled ball of pasta难以贡献。围绕是否必须拆成独立仓库出现了重要的分歧与深化模块化不一定等于多仓库jberkus其他大型项目经验表明关键在于模块化架构而不必然是多个仓库在仓库内部模拟多仓库thockin与其拆库不如移动代码直到仓库内部看起来像多个子仓库——例如把 kubelet 相关逻辑全部集中到一个目录除一个 util 目录外或许本身就是一种改进先拆云厂商驱动与会共识First thing: were breaking up cloud providers, it helps let the long tail of cloud providers go out。云厂商是第一个拆出去的对象存储提供商随后也应有清晰接口明确的接口边界dchen1107时任发布经理发布管理成本巨大作为发布经理我不知道另一个仓库里有什么但清晰的 API 与接口并不需要独立仓库——她举了 Docker 与 CRI 的例子不搬仓库也拿到了干净的 API决策机制缺失robertbailey提出本议题时以为大家已达成拆分共识但显然没有需要弄清谁是决策者 / 决策者群体自动化与通知spiffxp多仓库对 GitHub 通知更友好机器人改善了自动化但未解决通知分级也许该改进通知路由而不是拆库小仓库接入门槛solly如果拆分必须让小型仓库更容易接入自动化与工具链我不该自己摸索该问谁应该有文档不能出现 Heapster 那样掉进裂缝里的仓库。bgrant 的一锤定音值得注意Were already in the land of 90 repos. We dont need to debate splitting, were already split.——从治理现实看拆分早已发生incubator、kubernetes-client 等争论的焦点其实是如何把拆分做对尤其是让 API 类型、SDK 与通用工具链真正可复用We need SDKs to build kube-style APIs。四、候选拆分清单kubectl、client-go、kubeadm 与云厂商会上形成了初步的外移候选清单这份清单与同一峰会其他分会场如 cloud-provider.md以及 2017 年 5 月领导力峰会上的 Code Organization and Release Process Improvement 高度呼应候选组件会上讨论要点后续走向以本仓库文档为据kubectlclayton 认为 kubectl 本身太大值得围绕新东西重建社区lavalamp 形容其为拉入大量包、技术难以下手的意大利面代码已在拆分依赖的过程中拥有独立仓库并迁移 Issue见 0300-0345_CODEORGANIZATION.mdclient-go已独立发布属于另一个量级的问题需另开会讨论clayton 提出高性能版 面向人类重写版双轨思路对应 kubernetes-client 多语言客户端生态kubeadm留在主仓库是为了赶上发布列车release train曾尝试移出但失败luxasLucas Käldström时任 kubeadm 负责人提出 kubeadm 仓库必须权威并能纳入构建后续成立 Kubeadm Adoption 工作组推动采纳见 archive/wg-kubeadm-adoption/README.md云厂商驱动cloud providers首要拆分对象dims 举例 Google KMS provider 被移出、gRPC 接口 PR 未进 1.9说明在树外开发更灵活同峰会 cloud-provider.md 记录了 cloud-controller-manager 拆分进展kubelet / kube-proxythockin 提出疑问拆这些能带来具体收益吗还是会带来更多痛苦我们清楚这会拖慢节奏未在本次达成共识留待后续存储提供商若拆分应有清晰接口后续由 CSI 承接同峰会 cloud-provider 讨论中亦有提及会议还记录了已完成 / 进行中的拆分成果作为可行性参考API machinerystaging 化后解除了阻塞、cloud provider、kubernetes-client 组织。bgrant 总结称monorepo 中的velocity 是静态的the velocity of things in the monorepo are static。五、绕不开的三大工程挑战发布、测试、依赖5.1 发布管理多仓库如何拼出一次发布这是 timstclair 抛出的最尖锐问题没有人回答过我们如何把一组二进制作为一次发布交付没有统一计划。其难点在于发布经理无法掌握其他仓库内容dchen1107 作为时任发布经理的切身之痛安全更新必须快速送达Cloud Foundry 两周构建流程被引为反面案例多仓库需要组装发布各组件在各自仓库测试充分后由主仓库集成组装参见 0300-0345_CODEORGANIZATION.md 中Multi-repo requirements一节luxas 特别强调 kubeadm 的攻击计划需要为多仓库做一次发布kubeadm 仓库要权威且能纳入构建。5.2 测试基建谁来测、怎么定位回归与会者担忧拆分后的测试覆盖问题timstclairhow are you actually going to get test infra to test all the thingsbburnshow do you actually find the commit that causes a failure in e2e会议结论倾向用更小、更聚焦的测试取代过度依赖 e2e 的做法Need better, smaller tests overall不要在 e2e 上验证未经文档化的功能。5.3 依赖管理godeps 的噩梦timallclair 直言我担心依赖管理godeps 已经是噩梦多仓库只会更糟。 这一担忧在后续 Kubernetes 全面转向 Go modules 后才得到缓解。此外 dims 指出 monorepo 的连带污染问题vendor 会把不关心的 SDK如 AWS SDK拖进来——如果只做 OpenStack 相关工作在主仓库里很难获得合入批准但在自己的仓库里就容易得多。六、staging 机制在拆与不拆之间的第三条路本场讨论反复出现的staging概念值得单独说明。它是 Kubernetes 在仓库内部模拟多仓库的中间态代码仍留在主仓库但按 k8s.io 包路径组织成伪仓库通过符号链接进入 vendor 目录供 Go 工具链消费再由发布机器人用git filter-branch将各 staging 目录切分成真实仓库推送到外部详见本仓库文档 contributors/devel/sig-architecture/staging.md。会上围绕 staging 的价值与边界形成了几个重要判断staging 状态是解决了一半的状态lavalampAPI machinery 正是因为到达 staging 状态而被解除了阻塞thockin 则认为 staging 已经解决了问题因为你得先把纠缠的依赖解开才能 stagingstaging 可作为已拆分的观察窗口pwittrock可以从 staging 仓库的实例中看到拆分带来的收益或问题erictune 的呼吁请把已经开工但没拆完的分拆工作做完finish some of our started-but-not-finished breakaparts同峰会 cloud-native-design-refactoring-across-k8s.md 也列出了跨仓库重构的相关 Issue 与 util 目录整合工作可视作 staging 路径上的具体任务。根据 staging.md 的记载该机制最终演化为成熟的发布机器人publishing bot体系支持多分支发布master 及 release-1.28 至 release-1.31 等、为发布仓库自动打kubernetes-前缀标签、并自 v1.17.0 起同步生成与主仓库 tag 对应的语义化v0.x.y标签以无缝衔接 Go modules。七、没有结论的结论走向软件还是发行版之问这场讨论没有形成投票式的决议但沉淀了几点关键共识拆分已既成事实争论焦点是治理bgrant我们已经有 90 个仓库主仓库将演化为集成点二进制产物由其他仓库生产lavalamp必须量化成本bburns 的我们不测量成本之问与 lavalamp我们已经估算过的回答共同指向同一个行动——拆分必须基于成本收益而非审美偏好扩展点需要接口而非拆库CRIDocker 例、cloud provider、CRD、SDK 都是不搬仓库也能拿 API的证明对基础设施的依赖会加重spiffxp增加对集成工具的依赖会带来现在没有的开销与流程但多数 OSS 从业者期望多仓库且 GitHub 通知在多仓库下更易管理自动化接入要有文档与统一入口solly不能让小仓库掉进裂缝thockin 将终极问题抛给全场我们是一个软件还是一个发行版a piece of software or a distribution——这个问题的答案决定了 monorepo 的未来形态。回望本仓库的目录结构这场 2017 年会议所讨论的分拆蓝图——kubectl 归 SIG CLI、云厂商驱动外置、client-go 独立发布、kubeadm 拥有独立工作组的采纳计划、staging 目录与发布机器人常态化——都在后续 Kubernetes 社区治理文档中得到了印证。对于研究大型开源项目代码库治理的工程师而言这份会议记录是理解monorepo 拆分之痛的第一手史料它诚实地记录了成本、分歧、技术债务与长期投入而非一份粉饰过的决策白皮书。延伸阅读本场会议原始记录breaking-up-the-monolith.md2017 年 5 月领导力峰会同主题记录0300-0345_CODEORGANIZATION.mdstaging 目录与发布机制contributors/devel/sig-architecture/staging.md云厂商拆分进展events/2017/12-contributor-summit/cloud-provider.mdkubeadm 采纳工作组archive/wg-kubeadm-adoption/README.md峰会整体信息与议程events/2017/12-contributor-summit/ContribSummitInformation.md【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考