【.comExpress翻译】容器和Kubernetes在计算世界中引入了一种新的一致性范例，提高了工程团队的速度和敏捷性。一种通用的声明性语言提供了描述应用程序和操作任务的融合，使Kubernetes成为运行分布式工作负载的流行平台。在声明式YAML中指定所需状态后，Kubernetes继续解析和实现声明的状态，例如应用程序的副本数。如果有任何偏差，Kubernetes将尝试解决实际状态与声明状态之间的差异，例如死亡和重新启动pod/容器。对于初次部署到Kubernetes的用户来说，感觉非常快。编写最小部署YAML意味着一旦向kubectl发出go[apply]命令就可以启动并运行。当需要更改时，Kubernetes会利用其优势之一：滚动更新、增量更改。观察滚动更新的发生，如果您习惯了具有手写滚动更新规则的平台，这会让Kubernetes看起来轻而易举。对于Kubernetes的所有好处，拥有良好的CI/CD（持续集成/持续部署）实践是关键。借助Kubernetes的优势推进您的CI/CD之旅。CI和Kubernetes的最佳实践持续集成(CI)是构建自动化的过程。比如一个Java应用需要打成JAR，然后如果进入Kubernetes，需要Docker化，可能用Helmchart等格式打包/描述。在容器世界中，由于容器是不可变的，任何需要的改变都会产生一个新的镜像，因此会频繁调用CI流程来构建和打包新镜像。在Kubernetes上运行持续集成过程是一个谨慎的举动，因为构建和打包软件可能是计算密集型的。每次提交都启动构建的现代方法实际上会对基础设施造成负担，尤其是对于容器化构建。使用Kubernetes构建和打包软件是一个很好的用例，因为现代CI工具专注于在Kubernetes中创建临时构建运行器/节点。随着构建请求的到来，只需启动新实例来创建构建工件，然后在作业完成后关闭实例。可以在暂存容器中轻松运行的持续集成信任构建步骤包括单元测试、集成测试和安全扫描等步骤。图像/容器扫描步骤可能会分解和验证Docker层，计算量特别大，类似于运行计算密集型构建任务。由于每次构建都可能引入新的依赖项或依赖项的新版本，因此每次构建新映像时运行容器扫描非常重要。然而，一些组件需要比临时容器更持久，并且需要更持久的存储。持续集成的退出步骤是将创建的工件/包发布到工件存储库和/或将清单文件发布到适当的源代码控制/包管理器解决方案。在Kubernetes世界中，这也可能是创建Kubernetes部署所需的清单文件，例如Helm图表或Kustomize/JSONNET资源。CI与Kubernetes的目标是生成易于部署的工件，包/配置/模板管理器允许这样做。除非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之前的原则或哲学的情况下接受这些新范例是明智的。原标题：KubernetesCI/CDBestPractices，作者：RaviLachhman
