Kubernetes 社区峰会实录SIG Cluster Lifecycle 与 kubeadm 迈向 GA 的路线图、HA 与自托管之争【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文基于 Kubernetes Community 仓库中 2017 年 12 月 KubeCon/CloudNativeCon 贡献者峰会上 Whats Up with SIG-Cluster-Lifecycle 分会的现场笔记原文档系统还原当时社区围绕 kubeadm 从 Beta 走向 GA 的路线图讨论包括 kubeadm 的定位与范围、高可用HA的准确定义、自托管控制面的可行性、人与自动化两种使用场景的冲突以及生产级production grade究竟意味着什么。读完本文你将理解 kubeadm 早期设计决策背后的社区共识与分歧并结合仓库内的 SIG 章程、事故复盘与后续路线图文档看到这些讨论如何塑造了今天的集群生命周期工具链。一、背景一次面向未来的 SIG 全体讨论这场分会由当时 SIG Cluster Lifecycle 的核心成员 LuxasLucas Käldström仓库 SIG README 中列为 Emeritus Leads主持。开场他就定下了基调我可以回顾过去一年我们做了什么但我更想听听你们对未来方向的看法尤其是 hosting托管/自托管等话题。这场讨论发生在 Kubernetes 1.8/1.9 时代kubeadm 仍处于 Beta 前的关键阶段。当时社区的普遍共识见 2016 年开发者峰会笔记是kubeadm 不应做云资源供给cloud VM provisioning 超出范围而应成为一个工具箱覆盖集群生命周期中的公共部分并且能够拆出用户想要的单个组件。这个定位在一年后的本次讨论中得到了延续和深化。二、kubeadm 的定位与范围一个正式的范围声明讨论中有人直接提问能否有人为 kubeadm 写一份关于其目的与范围purpose scope的正式声明现场给出的回答如下kubeadm 的目标是安装一个最小可行、符合最佳实践的 Kubernetes 集群。网络插件CNI provider需要由用户自行安装。kubeadm 不会在任何层面基础设施、网络、存储等为任何 provider 背书。这句话事实上成为了 kubeadm 的官方定位宣言。对照仓库中 SIG Cluster Lifecycle 章程 的表述——SIG 的目标是简化 Kubernetes 集群及其组件的创建、配置、升级、降级与拆除——以及 SIG README 中 kubeadm 子项目定义A tool that performs the actions necessary to get a minimum viable, secure cluster up and running in a user friendly way可以看到这一范围声明被完整保留并延续至今。围绕这一声明现场还补充了几个关键边界保持范围狭窄是刻意为之有人希望 kubeadm 集成 Dashboard 的 UI 集成但团队明确表示为了成功必须把范围收得很窄UI 属于另一个项目对应章程中 Out of scope 的 sig-ui/sig-cli 划分。它是高层安装器的构建块kubeadm 的另一个目标是成为更高层安装工具的底层积木。现场提到正在与 Kubespray 团队沟通并以启用 webhooks作为上层工具需要 kubeadm 提供扩展能力的例子。这一目标后来被制度化——仓库中的 Kubeadm Adoption Working Group 明确写道kubeadm is a tool for creating new Kubernetes clusters easily for new users, but can also be used as a toolbox for higher-level deployment solutions并负责确保 kubeadm 满足这些高层安装器的可扩展性需求。生态位分工明确现场提到 GKE 团队可能在研究Kubeadm Cluster API的组合方案Amazon 不使用 kubeadm而 Docker 在使用——Docker for Mac/Windows 即将内置嵌入版 KubernetesBeta。三、迈向 Beta/GA 的两大硬骨头HA 与自托管讨论的核心议题是如何让 kubeadm 在下一年达到 Beta 乃至 GA。现场列出的主要工作方向方向具体内容高可用HAetcd 多主机etcd-multihostapiserver、controller 等控制面组件的多副本方案自托管Self-hosted让 kubeadm 支持自托管控制面self-hosted kubeadm3.1 子目标组件拆分与底层原理文档JoeJoe Beda提出一个不阻塞 GA 的子目标把 kubeadm 的各个组件拆分出来让用户能够只安装自己需要的特定部分。同时他希望有文档解释 kubeadm 在底层到底做了什么what kubeadm does under the covers。Josh 则进一步要求文档回答如何修改我的 kubeadm 安装how do I modify my kubeadm install并认为这是 GA 的必要条件——在场另一位与会者也持同样看法。这类可修改性 可理解性的需求与仓库中 集群部署路线图 强调的understandability易理解、易修改vs configurability可配置、覆盖更广光谱一脉相承kubeadm 被期望成为光谱上偏可理解、可组合的一端。3.2 HA 的定义之争三个节点还是两个关于 HA现场爆发了有趣的争论。最初的 HA 定义清单是etcd 应采用 quorum 高可用标准3 节点不止一个 master所有核心组件apiserver、scheduler、kube-controller-manager运行在每一个 master 上必须能够添加 master支持升级。随后有人提出更简化的表述我们希望能够在丢失一台主机/节点包括 master 节点的情况下存活——如果按这个标准只需要两个 master 就够了。争论由此展开那么恢复或替换场景怎么办新加入的 master 需要能够 join通过手动命令。紧接着的问题是HA 升级怎么办是否支持从单 master 扩展到三 master答案是必须支持。最终现场收敛为修订后的四条需求3 个 etcd 副本etcd replicas ≥ 3每个 master 上运行全部 master 组件apiserver、scheduler、kube-controller-manager所有 TLS 均受保护all TLS secured支持 HA 集群的升级upgrades for HA clusters。这四条是当时对kubeadm 的 HA 到底指什么最精炼的社区共识也是后续 kubeadm 高可用设计的基础骨架。四、kubeadm 困境给人类的工具与给机器的工具现场提出了一个至今仍具启发性的矛盾被称为kubeadm dilemma我们希望人类能够顺畅地运行 kubeadm 并拥有良好的体验同时也希望自动化automation能够驱动它。但这两者不太可能由同一个工具同时满足。当时的做法是把 kubeadm 定位为面向人的工具讨论中有人提出或许应该为机器做一个略有不同的界面。Josh 的反馈则提供了一个折中视角自动化运行 kubeadm 其实效果不错麻烦只在于错误输出error output难以被程序化捕获——也就是说问题不在执行流程而在输出格式的可解析性。这个人机分界面的问题在后来 kubeadm 的--config声明式配置、可解析的输出、以及kubeadm init/join/upgrade子命令体系中都能看到影子而从仓库中的 kubeadm 1.6 事故复盘 可以看到当时 kubeadm 的 init 流程中等待 master 节点 Ready 并部署一个 dummy deployment 来验证控制面健康这一面向人的校验逻辑恰恰是 1.6.0 卡死的根因——kubelet 在 CNI 未配置时上报 NotReady 导致 init 无限挂起修复方式是只等待节点注册、不再要求 Ready、去掉 dummy deploymentPR #43835。这说明面向人类的健康校验与自动化流程之间确实存在需要刻意设计才能两全的张力。五、自托管控制面CoreOS 的现场证词自托管self-hosting是本次讨论的另一大焦点。CoreOS 工程师带来了宝贵的生产实践证词自托管控制面本身运行得很好——他们所有客户都采用这种方式托管控制面但 etcd 是特殊的自托管 etcd 存在大量意想不到的脆弱时刻unexpected fragile moments上游对HA etcd 的测试本身就不充分——E2E 测试不足而自托管让问题雪上加霜etcd operator 需要大量工作需要多个团队共同投入即使 etcd operator 完美可用Kubernetes 使用 HA etcd 的方式本身也有问题不一定能说服用户采用。这段证词实质上把问题拆成了两层控制面组件apiserver/scheduler/controller-manager的自托管已经可行难点集中在etcd 的自托管与 HA 运维上。这也在一定程度上解释了为什么后续 etcd 管理外部 etcd、etcd operator成为 SIG Cluster Lifecycle 的长期关注点——直到今天仓库 SIG README 仍将 WG etcd Operator 列为该 SIG 赞助的工作组之一。5.1 自托管与安全、以及单/多 master 的差异讨论进一步指出单 master 与多 master 的自托管是两种不同情况不能要求所有用户都上 HA是否必须支持非自托管non-self-hosted现场理性地指出不可能测试所有路径维护是有成本的选择非自托管的一个正当理由是安全防止节点被颠覆subversion of nodes——即把控制面组件作为静态 Pod/宿主机进程托管比自托管更不易被恶意 workload 影响。这个测试成本 vs 功能面的权衡与 kubeadm 1.6 事故复盘 的核心教训完全一致1.6.0 之所以带着回归发布正是因为 kubeadm 的 E2E 测试只在 master 分支上存在、Conformance 测试因 CNI 生态滞后被禁用、且发布前没有人工 E2E 验证。测试路径覆盖不足正是无法支持所有路径这一判断的真实代价。六、稳定还是前沿GA 意味着什么另一个尖锐问题是kubeadm 应该专注于稳定安装还是追逐最前沿的特性现场承认kubeadm 到当时为止一直聚焦于前沿edge但走向 GA 意味着减速。随之而来的问题是是否需要一个外部角色来承担前瞻性工作还是通过feature flags在同一个工具内同时满足稳定与前沿两种诉求与此相关讨论还触及生产级production grade这个词的滥用每个人都声称我们要的是一个生产环境但生产级很难定义。我们应该停止使用这个词。真正重要的是它是否在被持续维护is it maintained。只要项目仍在被持续维护它就会随着时间的推移越来越好。这一务实观点后来也体现在 2018 特性路线图 中——2017 年主要特性清单里Cluster Lifecycle 一项写的是 kubeadm enhancements - road to GA in 2018?而听众对 2017 年稳定版发布承诺的质疑1.8/1.9 到底算不算稳定版也说明稳定性需要被量化、被当作 roadmap 项来对待。七、配套需求文档、资源建议与 kubelet 证书除了 HA 与自托管现场还提出了一批 GA 前的配套需求SIG 应文档化部署建议例如需要多少内存这类资源规划问题但与会者也承认这些需求经常变化需要更多数据以及 sig-scalability 的测试支撑。需要支持 CA 签名的 kubelet 证书——现场表示这一项基本已完成mostly done。这正是后来 kubelet TLS bootstrapping 的雏形与 2016 年峰会笔记 中反复出现的client cert bootstrap in KubeletPKI 轮换/吊销讨论一脉相承。升级路径的追问如果最终把 HA 留给外部控制器如 kOps 等去实现、让它们把 kubeadm 当作原语primitive使用那么kubeadm upgrade 到底该怎么工作就成了悬而未决的问题——现场以这句反问结束恰好点出了 kubeadm 作为构建块定位与内置升级能力之间需要持续协调的核心矛盾。八、结语这场讨论的历史坐标把这份峰会笔记放回仓库的文档时间线中可以清晰地看到它的历史坐标2016 年 11 月开发者峰会上社区已经定下 kubeadm 的工具箱定位与升级、HA、PKI、Conformance 等 wishlistcluster_lifecycle_notes.md2017 年 3 月的 kubeadm 1.6.0 事故暴露出测试覆盖与发布流程的严重缺口postmortems/kubeadm-1.6.md2017 年 12 月的本次讨论则是在 Beta/GA 门槛前的一次范围收敛与路线图校准——HA 的四条定义、自托管控制面可行、etcd 特殊的结论、面向人还是面向机器的 dilemma都在这里被摆上台面随后的 2018 特性路线图 和 SIG 章程、Kubeadm Adoption WG 则把这些讨论沉淀为正式的组织安排与范围边界。今天再读这份笔记最有价值的不是某个具体结论而是它所展示的工程决策方法范围要窄、边界要清晰、测试要覆盖、面向人的体验与面向机器的接口要分开设计、以及生产级要用持续维护来检验。对于任何研究 Kubernetes 集群生命周期工具演进、或正在设计类似集群引导工具的开发者这份实录都是一份难得的原始决策档案。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 社区峰会实录：SIG Cluster Lifecycle 与 kubeadm 迈向 GA 的路线图、HA 与自托管之争
Kubernetes 社区峰会实录SIG Cluster Lifecycle 与 kubeadm 迈向 GA 的路线图、HA 与自托管之争【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文基于 Kubernetes Community 仓库中 2017 年 12 月 KubeCon/CloudNativeCon 贡献者峰会上 Whats Up with SIG-Cluster-Lifecycle 分会的现场笔记原文档系统还原当时社区围绕 kubeadm 从 Beta 走向 GA 的路线图讨论包括 kubeadm 的定位与范围、高可用HA的准确定义、自托管控制面的可行性、人与自动化两种使用场景的冲突以及生产级production grade究竟意味着什么。读完本文你将理解 kubeadm 早期设计决策背后的社区共识与分歧并结合仓库内的 SIG 章程、事故复盘与后续路线图文档看到这些讨论如何塑造了今天的集群生命周期工具链。一、背景一次面向未来的 SIG 全体讨论这场分会由当时 SIG Cluster Lifecycle 的核心成员 LuxasLucas Käldström仓库 SIG README 中列为 Emeritus Leads主持。开场他就定下了基调我可以回顾过去一年我们做了什么但我更想听听你们对未来方向的看法尤其是 hosting托管/自托管等话题。这场讨论发生在 Kubernetes 1.8/1.9 时代kubeadm 仍处于 Beta 前的关键阶段。当时社区的普遍共识见 2016 年开发者峰会笔记是kubeadm 不应做云资源供给cloud VM provisioning 超出范围而应成为一个工具箱覆盖集群生命周期中的公共部分并且能够拆出用户想要的单个组件。这个定位在一年后的本次讨论中得到了延续和深化。二、kubeadm 的定位与范围一个正式的范围声明讨论中有人直接提问能否有人为 kubeadm 写一份关于其目的与范围purpose scope的正式声明现场给出的回答如下kubeadm 的目标是安装一个最小可行、符合最佳实践的 Kubernetes 集群。网络插件CNI provider需要由用户自行安装。kubeadm 不会在任何层面基础设施、网络、存储等为任何 provider 背书。这句话事实上成为了 kubeadm 的官方定位宣言。对照仓库中 SIG Cluster Lifecycle 章程 的表述——SIG 的目标是简化 Kubernetes 集群及其组件的创建、配置、升级、降级与拆除——以及 SIG README 中 kubeadm 子项目定义A tool that performs the actions necessary to get a minimum viable, secure cluster up and running in a user friendly way可以看到这一范围声明被完整保留并延续至今。围绕这一声明现场还补充了几个关键边界保持范围狭窄是刻意为之有人希望 kubeadm 集成 Dashboard 的 UI 集成但团队明确表示为了成功必须把范围收得很窄UI 属于另一个项目对应章程中 Out of scope 的 sig-ui/sig-cli 划分。它是高层安装器的构建块kubeadm 的另一个目标是成为更高层安装工具的底层积木。现场提到正在与 Kubespray 团队沟通并以启用 webhooks作为上层工具需要 kubeadm 提供扩展能力的例子。这一目标后来被制度化——仓库中的 Kubeadm Adoption Working Group 明确写道kubeadm is a tool for creating new Kubernetes clusters easily for new users, but can also be used as a toolbox for higher-level deployment solutions并负责确保 kubeadm 满足这些高层安装器的可扩展性需求。生态位分工明确现场提到 GKE 团队可能在研究Kubeadm Cluster API的组合方案Amazon 不使用 kubeadm而 Docker 在使用——Docker for Mac/Windows 即将内置嵌入版 KubernetesBeta。三、迈向 Beta/GA 的两大硬骨头HA 与自托管讨论的核心议题是如何让 kubeadm 在下一年达到 Beta 乃至 GA。现场列出的主要工作方向方向具体内容高可用HAetcd 多主机etcd-multihostapiserver、controller 等控制面组件的多副本方案自托管Self-hosted让 kubeadm 支持自托管控制面self-hosted kubeadm3.1 子目标组件拆分与底层原理文档JoeJoe Beda提出一个不阻塞 GA 的子目标把 kubeadm 的各个组件拆分出来让用户能够只安装自己需要的特定部分。同时他希望有文档解释 kubeadm 在底层到底做了什么what kubeadm does under the covers。Josh 则进一步要求文档回答如何修改我的 kubeadm 安装how do I modify my kubeadm install并认为这是 GA 的必要条件——在场另一位与会者也持同样看法。这类可修改性 可理解性的需求与仓库中 集群部署路线图 强调的understandability易理解、易修改vs configurability可配置、覆盖更广光谱一脉相承kubeadm 被期望成为光谱上偏可理解、可组合的一端。3.2 HA 的定义之争三个节点还是两个关于 HA现场爆发了有趣的争论。最初的 HA 定义清单是etcd 应采用 quorum 高可用标准3 节点不止一个 master所有核心组件apiserver、scheduler、kube-controller-manager运行在每一个 master 上必须能够添加 master支持升级。随后有人提出更简化的表述我们希望能够在丢失一台主机/节点包括 master 节点的情况下存活——如果按这个标准只需要两个 master 就够了。争论由此展开那么恢复或替换场景怎么办新加入的 master 需要能够 join通过手动命令。紧接着的问题是HA 升级怎么办是否支持从单 master 扩展到三 master答案是必须支持。最终现场收敛为修订后的四条需求3 个 etcd 副本etcd replicas ≥ 3每个 master 上运行全部 master 组件apiserver、scheduler、kube-controller-manager所有 TLS 均受保护all TLS secured支持 HA 集群的升级upgrades for HA clusters。这四条是当时对kubeadm 的 HA 到底指什么最精炼的社区共识也是后续 kubeadm 高可用设计的基础骨架。四、kubeadm 困境给人类的工具与给机器的工具现场提出了一个至今仍具启发性的矛盾被称为kubeadm dilemma我们希望人类能够顺畅地运行 kubeadm 并拥有良好的体验同时也希望自动化automation能够驱动它。但这两者不太可能由同一个工具同时满足。当时的做法是把 kubeadm 定位为面向人的工具讨论中有人提出或许应该为机器做一个略有不同的界面。Josh 的反馈则提供了一个折中视角自动化运行 kubeadm 其实效果不错麻烦只在于错误输出error output难以被程序化捕获——也就是说问题不在执行流程而在输出格式的可解析性。这个人机分界面的问题在后来 kubeadm 的--config声明式配置、可解析的输出、以及kubeadm init/join/upgrade子命令体系中都能看到影子而从仓库中的 kubeadm 1.6 事故复盘 可以看到当时 kubeadm 的 init 流程中等待 master 节点 Ready 并部署一个 dummy deployment 来验证控制面健康这一面向人的校验逻辑恰恰是 1.6.0 卡死的根因——kubelet 在 CNI 未配置时上报 NotReady 导致 init 无限挂起修复方式是只等待节点注册、不再要求 Ready、去掉 dummy deploymentPR #43835。这说明面向人类的健康校验与自动化流程之间确实存在需要刻意设计才能两全的张力。五、自托管控制面CoreOS 的现场证词自托管self-hosting是本次讨论的另一大焦点。CoreOS 工程师带来了宝贵的生产实践证词自托管控制面本身运行得很好——他们所有客户都采用这种方式托管控制面但 etcd 是特殊的自托管 etcd 存在大量意想不到的脆弱时刻unexpected fragile moments上游对HA etcd 的测试本身就不充分——E2E 测试不足而自托管让问题雪上加霜etcd operator 需要大量工作需要多个团队共同投入即使 etcd operator 完美可用Kubernetes 使用 HA etcd 的方式本身也有问题不一定能说服用户采用。这段证词实质上把问题拆成了两层控制面组件apiserver/scheduler/controller-manager的自托管已经可行难点集中在etcd 的自托管与 HA 运维上。这也在一定程度上解释了为什么后续 etcd 管理外部 etcd、etcd operator成为 SIG Cluster Lifecycle 的长期关注点——直到今天仓库 SIG README 仍将 WG etcd Operator 列为该 SIG 赞助的工作组之一。5.1 自托管与安全、以及单/多 master 的差异讨论进一步指出单 master 与多 master 的自托管是两种不同情况不能要求所有用户都上 HA是否必须支持非自托管non-self-hosted现场理性地指出不可能测试所有路径维护是有成本的选择非自托管的一个正当理由是安全防止节点被颠覆subversion of nodes——即把控制面组件作为静态 Pod/宿主机进程托管比自托管更不易被恶意 workload 影响。这个测试成本 vs 功能面的权衡与 kubeadm 1.6 事故复盘 的核心教训完全一致1.6.0 之所以带着回归发布正是因为 kubeadm 的 E2E 测试只在 master 分支上存在、Conformance 测试因 CNI 生态滞后被禁用、且发布前没有人工 E2E 验证。测试路径覆盖不足正是无法支持所有路径这一判断的真实代价。六、稳定还是前沿GA 意味着什么另一个尖锐问题是kubeadm 应该专注于稳定安装还是追逐最前沿的特性现场承认kubeadm 到当时为止一直聚焦于前沿edge但走向 GA 意味着减速。随之而来的问题是是否需要一个外部角色来承担前瞻性工作还是通过feature flags在同一个工具内同时满足稳定与前沿两种诉求与此相关讨论还触及生产级production grade这个词的滥用每个人都声称我们要的是一个生产环境但生产级很难定义。我们应该停止使用这个词。真正重要的是它是否在被持续维护is it maintained。只要项目仍在被持续维护它就会随着时间的推移越来越好。这一务实观点后来也体现在 2018 特性路线图 中——2017 年主要特性清单里Cluster Lifecycle 一项写的是 kubeadm enhancements - road to GA in 2018?而听众对 2017 年稳定版发布承诺的质疑1.8/1.9 到底算不算稳定版也说明稳定性需要被量化、被当作 roadmap 项来对待。七、配套需求文档、资源建议与 kubelet 证书除了 HA 与自托管现场还提出了一批 GA 前的配套需求SIG 应文档化部署建议例如需要多少内存这类资源规划问题但与会者也承认这些需求经常变化需要更多数据以及 sig-scalability 的测试支撑。需要支持 CA 签名的 kubelet 证书——现场表示这一项基本已完成mostly done。这正是后来 kubelet TLS bootstrapping 的雏形与 2016 年峰会笔记 中反复出现的client cert bootstrap in KubeletPKI 轮换/吊销讨论一脉相承。升级路径的追问如果最终把 HA 留给外部控制器如 kOps 等去实现、让它们把 kubeadm 当作原语primitive使用那么kubeadm upgrade 到底该怎么工作就成了悬而未决的问题——现场以这句反问结束恰好点出了 kubeadm 作为构建块定位与内置升级能力之间需要持续协调的核心矛盾。八、结语这场讨论的历史坐标把这份峰会笔记放回仓库的文档时间线中可以清晰地看到它的历史坐标2016 年 11 月开发者峰会上社区已经定下 kubeadm 的工具箱定位与升级、HA、PKI、Conformance 等 wishlistcluster_lifecycle_notes.md2017 年 3 月的 kubeadm 1.6.0 事故暴露出测试覆盖与发布流程的严重缺口postmortems/kubeadm-1.6.md2017 年 12 月的本次讨论则是在 Beta/GA 门槛前的一次范围收敛与路线图校准——HA 的四条定义、自托管控制面可行、etcd 特殊的结论、面向人还是面向机器的 dilemma都在这里被摆上台面随后的 2018 特性路线图 和 SIG 章程、Kubeadm Adoption WG 则把这些讨论沉淀为正式的组织安排与范围边界。今天再读这份笔记最有价值的不是某个具体结论而是它所展示的工程决策方法范围要窄、边界要清晰、测试要覆盖、面向人的体验与面向机器的接口要分开设计、以及生产级要用持续维护来检验。对于任何研究 Kubernetes 集群生命周期工具演进、或正在设计类似集群引导工具的开发者这份实录都是一份难得的原始决策档案。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考