Kubernetes LTS并不存在   

每三个月发布一个“vanilla”上游Kubernetes的1.xx“minor”版本，这种节奏可能会永远持续下去。你必须跟上，同时也要密切关注Kubernetes API对象版本控制。这种坚定的步伐是Kubernetes统治分布式基础设施领域的关键因素。

何为Kubernetes发布周期？

我们与那些希望利用Kubernetes（特别是DIY部署）的人交谈时遇到的问题之一，就是“你们如何保持同步？”

这带来了对以下问题的好奇：

谁在管理Kubernetes社区项目？
它们的发布周期和质量有多一致？
像Debian、Ubuntu或RHEL一样，Kubernetes是否有长期支持版本，即Kubernetes LTS？
每次发布新的Kubernetes版本时，集群维护人员或产品负责人需要做什么才能跟上？
集群不用最新版本时会发生什么？
它们是继承管理Kubernetes的任务的合理替代吗？
如果答案仅仅是“云”，那么使用“认证”Kubernetes平台可以安全而不被锁定吗？

让我们深入了解Kubernetes和这个项目背后的故事。

Kubernetes的由来

谷歌内部Kubernetes最早的管理人员围绕该项目建立了一个强大的开放社区，从Linux内核项目、Mozilla、Openstack、Chrome甚至node.js分支中汲取了足够多的经验教训。

commit 2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56
Author: Joe Beda <joe.github@bedafamily.com>Date: Fri Jun 6 16:40:48 2014 -0700

First commit

如果你进入这一领域较晚，你可以查看近三年Techcrunch上关于Kubernetes 1.0版本的文章。

领导Linux基金会的开源社区构建积极分子Jim Zemlin是名副其实的硅谷算命先生，“我预测，这项技术好得让人无法抗拒，现在没有参与的人以后会改变主意。”

即使Bryan Cantrill（Joyent首席技术官和unix天才），在见证了Kubernetes的诞生之后，也承认自己之前的开源观点有失偏颇。

Kubernetes成功的另一个秘密和主要原因是CNCF在Apache-2.0下发布它，这是一个有争议的开源许可（有人说它是长久以来科技巨头之间商业软件专利冷战的解药）。

如果你直接问Jim Zemlin这一切有什么特别之处，他会谈到让Alphabet贡献出Kubernetes的惊人法律壮举——一切都在受专利保护的开源许可之下！

伴随着Kubernetes的发展，CNCF和Kubernetes的贡献者们维持着一个以协作、开放和自我反思著称的社区。该说说SIG（Special Interest Group）了。

Kubernetes Special Interest Group

除了谷歌Brog十多年的积累和CNCF的带领之外，驱动Kubernetes发展的另一股力量是它的SIG模式。SIG是由技术上有共识的人组成的特别小组。它们采用与领先软件公司中最好的团队相同的模式。最关键的，SIG负责管理端到端测试和CI / CD系统（这些系统严格执行Kubernetes发布程序）。对边缘的或更深奥的部分感兴趣的SIG随工作进展而增减，在特定区域出现。甚至还有一个整体的产品管理SIG，由顶尖的PM负责。

在理解Kubernetes发布周期的背景下，SIG和他们的工作组很有意思，因为领导力、节奏和长期质量等关键属性都是SIG结构的成果。想了解SIG如何与更广泛的企业利益生态系统相互作用，可以听一下技术项目经理兼SIG产品负责人Caleb Miles的New Stack访谈。

SIG最棒的一点是，参与者和领导力的多样性。然而，与别的流行的新兴技术一样，总有巩固权力和影响路线图的需要。收购CoreOS后，红帽现在“骄傲的是，红帽工程师能够主导或共同主导12个SIG。”目前还不清楚这是好是坏，但其后果值得观察。

Kubernetes版本控制

Kubernetes发布的基本节奏是预期每三到四个月一次重要发布。Kubernetes Release Versioning设计文档有一些非常好的细节。虽然最初的动力来自谷歌，但现在核心发布团队中的数十家科技公司轮番发力。

很多人会挑剔“vanilla”Kubernetes的质量，因此任何发布目标的共同管理者都有很大的自由度来改变日期或推迟未被相关SIG认为就绪的pull请求。认真看了版本控制文件的人会注意到，“目前没有发布2.0.0的标准”，并且Kubernetes对外一直是1.XY——其中X每季度增加一次，Y由社区的集体性突发奇想决定。请牢记：被贡献者社区称为“minor”的发布可能会对运维和使用集群的体验产生巨大的（通常是积极的）影响。

Kubernetes历史版本

自2015年夏天，Kubernetes已经发布了九个“minor”版本。

通过查看新闻稿和git标签，你会发现发布基本遵守每季度或大约每一百天的节奏。
Kubernetes Release Date Cadence
Christening of 1.0 10th July 2015 ~one year from inception
From 1.0 to 1.1 9th November 2015 122 days
From 1.1 to 1.2 16th March 2016 128 days
From 1.2 to 1.3 1st July 2016 107 days
From 1.3 to 1.4 26th September 2016 87 days
From 1.4 to 1.5 12th December 2016 77 days
From 1.5 to 1.6 28th March 2017 106 days
From 1.6 to 1.7 30th June 2017 94 days
From 1.7 to 1.8 28th September 2017 90 days
From 1.8 to 1.9 15th December 2017 78 days
From 1.9 to 1.10 ETA mid-March 2018 ~100 days

Kubernetes功能开发流程

Kubernetes二进制组件的发布本身没什么意思。真正有意思的是它的RESTful API代表的“基础结构”。

Kubernetes的每个部分都使用定义良好的API与其他部分进行通信。把这个API想成Kubernetes的心脏，它被“不断跳动”的一系列组件包起来，将“氧气”输送到声明式配置模式中。 “核心”所做的是协调集群当前状态与所需状态。

API不断发展和改进，因为基础设施编码人员无休止地要求将越来越多的传统数据中心构建块抽象为可用的Kubernetes API端点。这些附加的Kubernetes功能（API）受贡献者的热情和更大的社区利益驱动，从alpha成长为beta。

Kubernetes的创始人专门设计了API版本控制和弃用标准来处理这种持续性的演变。与发布的版本控制文档类似，关于开发人员和最终用户应该期待的功能有更长期的策略。

这就是说，每个Kubernetes发布中重要的不是发布本身，而是API从“alpha”到“beta”到“stable”的细节。你甚至可以查看更改日志，找到哪些参数字段被添加或删除等详细信息。

虽然在Kubernetes进化过程中出现了一些明显的错误，并且等待API对象从alpha或beta阶段毕业很漫长，但稳定的API坚如磐石。

与Ubuntu LTS或RHEL相比

RedHat Enterprise Linux有着十年的长期支持保证。Ubuntu是五年。CoreOS的口号是“自动更新”。

主要云提供商及其“托管Kubernetes平台”，会负责为用户控制更新。因此，Kubernetes平台供应商神奇地处理了向后不兼容的迁移或在上游Kubernetes API中的强制迁移。Kubernetes即服务产品，特别是Google Cloud的Kubernetes引擎（GKE），是目前最稳定和最适合生产环境的Kubernetes版本的领头羊。

Kubernetes社区支持模式

前面所说的发布版本控制设计提案指出，用户需要保持“其在生产中使用的Kubernetes版本的合理更新”。另一个关键点是上游Kubernetes社区一次支持最多三个“minor” Kubernetes版本。实际上，1.X中的X很重要，三个minor的策略意味着在1.8发布后，Kubernetes 1.5就不在SIG发布的范围之内了。也就是说，如果你在去年3月份Kubernetes 1.6推出后不久就部署了Kubernetes 1.6集群，那么在大约九个月内也就是十二月中旬1.9发布时你得升级到1.7。

Kubernetes的发布节奏和短暂的上游支持窗口会不会对项目造成伤害？老实说，从最终用户的角度来看，并没有很大的影响。如果你深入了解SIG会议记录、Github事项、设计建议和邮件列表，你会发现社区对长期支持的共识仍在不断变化。而且，也许正是如此，尽可能长期地保持上游项目的灵活性是非常有意义的。当已经发布的核心API原语大部分保持不变，或者很少出现向后不兼容的更改时，为什么要对“vanilla”Kubernetes版本进行人为约束呢？

从实践和实际情况来看，对较早Kubernetes版本的支持，真正重要的是端到端测试管道的持续可用性和使用。

更新Kubernetes集群

关于编排器的一个神奇的事情是它们（或它们的配置文件）不可避免地变得几乎图灵完备。如果你有大的、有不同类型工作负载的Kubernetes集群，那么你会想要一个拥有Alan Turing级别Kubernetes智能的SRE，以确保更新顺利进行。

自主托管Kubernetes集群想法的支持者将图灵策略更进一步，并且正朝着集群可以自主管理的概念发展。

虽然Kubernetes可靠提供的基本API正在成为各种分布式系统问题解决方案的关键构建模块，有人对“自主驱动，自主托管”集群的概念表示质疑。

即使是社区认可的管理工具和安装程序，也尚未实现企业级、高可用性的Kubernetes部署。Google Cloud本身将其GKE Kubernetes即服务控制面板与实时迁移的外部虚拟化VM一起运行，以避免组件故障（而不是集群控制面板中的“自主驱动”）。

一个可行的策略是部署后就不管Kubernetes了，祈祷底层操作系统或Docker本身的bug不用你插手。对于面向内部的集群，“延期维护”策略对许多早期采用者来说完全有效。

将Kubernetes工作负载迁移到新的集群而不是更新

因此，更新集群最可靠的策略是：如果你无法逐步更新Kubernetes控制面板（及其各种组件），你可以用外部负载路由逐步将旧集群的负载迁移到新集群。或者，即使你逐步就地更新，也要在尝试阶跃式迁移之前在新集群上运行旧负载以确保更新的可靠性。

DIY Kubernetes的最佳替代

运行Kubernetes应用程序的最安全的地方仍然是谷歌的GKE。谷歌创造了Kubernetes，谷歌的SRE文化证明了它可以成功运行大型分布式系统。

如果你在GKE尚未存在的地方需要集群（如rpi3），怎么办？

这可能是Kubernetes社区，特别是供应商最令人着迷的地方。现在至少有二十多个可行的Kubernetes发行版。就像Uber或InstaCart的复本一样，它们是为了迎合细分市场而设计的。

那么在你意识到kops集群中的每个pod都具有对控制面板有root访问权限后，你会怎么做？找到你最喜欢的VAR，并以任何形式要求vanilla Kubernetes，这是合理的跟上节奏和处理更新的方法。然后你要做的就是专注于构建产品。

关于Kubernetes发布的最后思考

Kubernetes和分布式系统的“民主化”会持续下去。尽管跟上变化的步伐是困难的，但你还是得努力去做。

如果SIG停摆，谷歌的工程团队被欧盟监管机构的反垄断摧毁，我们仍然会在很长的时间内使用并热爱Kubernetes v1.X。贡献者和领导团体一直在讨论稳定与速度之间的平衡。如果你还有什么疑问，可以去看看最近的Kubecon上Brendan Burn（https://www.youtube.com/watch?v=gCQfFXSHSxw）的主题演讲。

本文转移K8S技术社区-Kubernetes新版本又来了 如何跟上变化“合理更新”？