《Kubernetes 最佳实践》第二版

第 6 章 版本管理 版本、发布和推广

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

人们对传统单体应用程序的主要抱怨之一是，随着时间的推移，它们开始变得过于庞大和笨重，无法以业务所需的速度进行适当的升级、版本升级或修改。许多人认为，这是导致 Agile 开发实践和微服务架构出现的关键因素之一。 能够快速迭代新代码、解决新问题或在隐患变成大问题之前将其修复，以及承诺零停机升级，这些都是开发团队努力追求的目标。 实际上，无论系统类型如何，只要有适当的流程和程序，这些问题都可以得到解决，但这通常需要付出更高的技术和人力资本成本来维护。

在设计系统时，隔离性和可组合性是重要的变量。 采用容器作为应用程序代码的运行时可以实现这一点，但对于大型系统来说，仍需要高度的人工自动化或系统管理，才能将系统维护在可靠的水平上。 随着时间的推移，系统不断增长，引入了更多的脆性，系统工程师开始构建复杂的自动化流程，以提供复杂的发布、升级和故障检测机制。Apache Mesos、HashiCorp Nomad 等服务编排器，甚至 Kubernetes 和 Docker Swarm 等基于容器的专业编排器，都将这些流程演化成了更原始的组件，直接进入了它们的运行时。 现在，系统工程师可以解决更复杂的系统问题，因为赌注已经提高到包括应用程序的版本、发布和部署到系统中。

版本控制

这一部分并不是要介绍软件版本化及其背后的历史；关于这一主题的文章和计算机科学课程书籍数不胜数。最重要的是选择一种模式并坚持使用。大多数软件公司和开发人员都认为，某种形式的语义版本管理是最有用的，尤其是在微服务架构中，编写某个微服务的团队将依赖于构成系统的其他微服务的 API 兼容性。

对于那些刚接触语义版本学的人来说，其基本原理是版本号由三部分组成，即主要版本、次要版本和补丁，通常用点号表示，如 1（主要版本）.2（次要版本）.3（补丁）。 补丁表示增量发布，其中包括错误修复或没有 API 变化的非常小的改动。次版本表示更新，可能有新的 API 变动，但向后兼容前一版本。对于使用其他微服务的开发人员来说，这是一个关键属性，因为他们可能没有参与开发。如果我知道我编写的服务可以与另一个微服务的 1.4.7 版本通信，而该微服务最近已升级到 1.5.7，这就意味着我可能不需要修改代码，除非我想利用任何新的 API 功能。主版本是代码的突破性变更增量。在大多数情况下，相同代码的主要版本之间不再兼容 API。这个过程有许多细微的修改，包括用 "4 "来表示软件在开发生命周期中所处的阶段，如 1.4.7.0 表示 alpha 代码，1.4.7.3 表示发布版本。最重要的是整个系统的一致性。

发布

事实上，Kubernetes 并没有真正的发布控制器，因此没有发布的原生概念。这通常会添加到部署metadata.labels 规范和/或pod.spec.template.metadata.label 规范中。何时加入这两项内容非常重要，而且根据 CD 如何用于更新部署变更，会产生不同的影响。当针对 Kubernetes 的 Helm 推出时，其主要概念之一是发布的概念，用于区分集群中同一 Helm 图表的运行实例。 这一概念在没有 Helm 的情况下也很容易复制；不过，Helm 本身会跟踪发布及其历史，因此许多 CD 工具将 Helm 集成到其管道中，成为实际的发布服务。同样，这里的关键在于版本控制的使用方式以及在集群系统状态中的位置是否一致。 ...