【51CTO.com快译】容器和Kubernetes已在计算界引入了一致性的新范式，为工程团队提高了速度和敏捷性。通用声明性语言提供了描述应用程序和操作任务的融合，使Kubernetes成为一种运行分布式工作负载的流行平台。
在声明性YAML中指定所需状态后，Kubernetes着手解决和实现已声明的状态，比如应用程序的副本数。若有任何偏差，Kubernetes会竭力解决实际状态与声明状态之间的差异，比如垂死和重新启动的pod/容器。
对于初次部署到Kubernetes的用户来说，感觉非常快速。一旦向kubectl发出了go [apply]命令，编写最简部署YAML意味着您启动并运行起来。需要更改时，Kubernetes会利用其优势之一：滚动更新，逐步更改。观看滚动更新进行，如果您习惯于手写滚动更新规则的平台，这使Kubernetes看起来轻而易举。
尽管Kubernetes有种种好处，但拥有良好的CI/CD(持续集成/持续部署)实践是关键。利用Kubernetes的优势推动您的CI/CD旅程。
CI和Kubernetes的优秀实践
持续集成(CI)是构建自动化的过程。比如说，Java应用程序需要内置到JAR中，然后如果进入到Kubernetes，需要进行Docker化处理，可能以Helm chart之类的格式进行打包/描述。在容器世界，由于容器不可变，需要的任何更改都将带来新的映像，因此将频繁调用CI过程来构建和打包新映像。
在Kubernetes上运行持续集成过程是谨慎的举动，因为构建和打包软件会占用大量的计算资源。每次提交启动构建的现代方法实际上对基础架构造成了负担，对于容器化构建而言更是如此。利用Kubernetes构建和打包软件是很好的用例，因为现代CI工具专注于在Kubernetes中创建临时构建runner/节点。随着构建请求进来，只需启动新实例以创建构建工件，然后作业完成后关闭实例。
可以在临时容器中轻松运行的持续集成信任建立步骤包括单元测试、集成测试和安全扫描等步骤。映像/容器扫描步骤可能是分解和验证Docker层，计算尤其密集型，类似运行计算密集型的构建任务。由于每个构建都可能引入新的依赖项或新版本的依赖项，每次您构建新映像时，运行容器扫描很重要。
不过有些组件需要比临时容器更持久，需要更持久的存储。持续集成的退出步骤是将创建的工件/程序包发布到工件存储库，及/或将清单文件发布到相应的源代码管理/程序包管理器解决方案。在Kubernetes界，这也可能是创建Kubernetes需要部署的所需清单文件，比如Helm chart或Kustomize/JSONNET资源。使用Kubernetes进行CI的目标是生成易于部署的工件，而程序包/配置/模板管理器允许这么做。
除非Kubernetes集群上的工作负载可以使用高可用性/持久存储，否则将工件存储库作为SaaS来运行或在K8s集群上运行很明智。致命弱点是工件存储库本身就是存储密集型。拥有可部署的工件/清单文件只是使您的想法落到最终用户手里的一部分。下一步是部署。
CD和Kubernetes的优秀实践
持续交付(CD)的目的是将变更安全地部署到生产环境。Kubernetes能够非常快速地部署，如果使用重建策略(所有pod被杀死并被替换)更是如此，而不是借助滚动策略增量部署。但是这会导致停机。我们大多数人处理一直运行的工作负载，因此停机将是不利因素。由于Kubernetes立即可用，忍住尽快部署的冲动似乎不合常理，却是建立信任所需要的。
在您开始使用Kubernetes之后，从应用程序在Kubernetes之前经历的建立信任演练入手仍然很重要。比如说，仍需要测试和覆盖需求。至于Kubernetes，可能会有更多的问题。出于可移植性的原因，运行一致性测试来验证要部署到的Kubernetes基础架构并不罕见。可移植性当初就是利用Kubernetes的一大卖点。
与在Kubernetes上运行持续集成步骤相似，在Kubernetes上运行某些持续交付步骤也是审慎的做法。在Kubernetes集群上可以轻松地搭建和关闭测试基础架构。视信任建立步骤的长短，可能会有编排所需的工作流程方面。是否在Kubernetes上运行长期/有状态的工作负载的相同设计原则和决策也适用于编排。
推进旅程
由于基础架构和应用程序之间的界限因Kubernetes而模糊，常见的系统设计悖论在Kubernetes中很容易上演。Kubernetes出现之前，开发工程师将程序直接部署到生产环境并非常态。通常，它以某种CI / CD平台作为门面，会有不同程度的自动化，批准后才可以进入到生产环境。
如果使用Kubernetes，您可以通过命名空间分离，轻松地在同一集群上面运行构建、信任建立步骤和部署，这取决于您在隔离与拥有单个集群方面走得多远。由于现代工具和GitOps潮流受到追捧，开发者可以强制执行标准，比如漂移检测和部署声明性状态的自我愈合。
Kubernetes能做出一般的反应，比如按控制器定义来做出反应。好的方法是从基准偏离情况，关注监控/可观察性系统。如今可以在Harness平台上以自动化的方式将这些工具编排成判断调用(比如，决定是否需要回滚)。随着更多组织进一步推进Kubernetes旅程，明智的做法是在拥抱这些新范式的同时，别忘记Kubernetes之前就有的准则或理念。
原文标题：Kubernetes CI/CD Best Practices，作者：Ravi Lachhman
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
