容器化和 Kubernetes 为计算世界带来了一种新的一致性范式，可以提高工程团队的速度和敏捷性。由通用声明性语言提供的用于描述应用程序和操作任务的融合使 Kubernetes 成为运行分布式工作负载的流行平台。
尽管拥有 Kubernetes 的所有好处，但拥有良好的CI/CD 实践是关键。
CI的Kubernetes（CI with Kubernetes） 最佳实践
持续集成 (CI)是构建自动化的过程。
例如，需要将 JAVA 应用程序构建到 JAR 中，然后如果要使用 Kubernetes，则需要进行 Docker 化，并可能以 Helm Chart 等格式进行打包/描述。
在容器化的世界中，由于容器是不可变的，任何需要的改变都会产生一个新的镜像，因此你的 CI 过程将被大量调用来构建和打包新的镜像。
在 Kubernetes 上运行你的持续集成过程是一个谨慎的举动。
构建和打包软件可能会占用大量计算资源。使用每次提交都启动构建的现代方法，它可能对基础设施造成很大负担——尤其是容器化构建。利用 Kubernetes 来构建和打包软件是一个很好的用例，因为现代 CI 工具专注于在 Kubernetes 中创建临时构建运行器/节点。当构建请求到来时，启动一个新实例来创建构建工件，然后在作业完成时停止实例。
可以在临时容器中轻松运行的持续集成建立信任步骤是单元测试、集成测试和安全扫描步骤。尤其是镜像/容器扫描步骤在分解和验证 Docker 层时可能需要大量计算，类似于运行计算量大的构建任务。由于每次构建都可能引入新的依赖项或新版本的依赖项，因此每次构建新镜像时运行容器扫描都很重要。
持续集成的一个完成步骤是：将创建的工件/包发布到工件存储库；或将清单发布到相应的源代码管理/包管理器解决方案。在 Kubernetes 世界中，这也可以是创建 Kubernetes 需要部署的清单。还例如Helm Charts 或 Kustomize/JSONNET 资源。CI with Kubernetes 的一个目标是生成一个易于部署的工件，并且包/配置/模板管理器允许这样做。
除非Kubernetes集群上的工作负载可以使用高可用性/持久性存储，否则以SaaS或K8s集群运行工件/脚手架的存储库是有意义的。阿喀琉斯之踵是，人工脚手架存储库在设计上过于繁重。
CD和Kubernetes 的最佳实践
持续交付 (CD)的目标是以安全的方式将您的更改投入生产。
Kubernetes 具有非常快速的部署能力，特别是如果使用“重新创建策略”，其中所有 Pod 都被杀死并替换为滚动策略增量；但这会导致停机。尽管我们中的大多数人都在处理一直在运行的工作负载，但停机时间会是不利的。
在Kubernetes之前应用程序进行的建立信任练习并没有随着Kubernetes神奇地消失。测试和覆盖要求并没有消失。有了Kubernetes，出现了更多担忧的可能性。在 Kubernetes 本身上运行某些持续交付步骤是谨慎的。在 Kubernetes 集群上可以轻松地建立测试基础设施，但是需要停止测试基础设施。根据建立信任步骤的时间长短，编排可能需要长期的工作流程方面。在 Kubernetes 上或从 Kubernetes 运行长期/有状态工作负载的相同设计原则和决策适用于编排。
Kubernetes 非常适合蓝绿或金丝雀发布等发布策略。虽然可以手工使用几个精心设计的 Kubernetes 清单并及时应用这些清单，但涵盖这些发布策略的工具正在增加。
构建适当的运行状况检查（例如活动性和就绪性探测器）以支持增量部署继续进行是关键。