Kubernetes部署的最佳CD策略

Question

我们当前的CI部署阶段的工作方式如下：

1. 构建容器。
2. 将镜像标记为“latest”和“< commit hash >”。
3. 将镜像推送到仓库。
4. 在适当的RC上调用滚动更新。

这对于基于RC的部署效果很好，但现在由于Deployment对象变得更加稳定并成为底层功能，我们希望利用这种抽象方式来改善当前的部署方案和开发阶段。

我遇到的问题是找到一种合理的方式来自动更新CI工作流中的Deployment。 我一直在尝试分割git repo并尝试以下步骤：

1. [应用程序构建] 构建容器。
2. [应用程序构建] 将镜像标记为“latest”和“< commit hash >”。
3. [应用程序构建] 将镜像推送到仓库。
4. [应用程序构建] 调用应用程序的“Deployment” repo的构建，并传递当前的commit hash。
5. [部署构建] 插值替换（目前仅使用传递的提交哈希，例如 image: app-%%COMMIT_HASH%%）。
6. [部署构建] 将更新后的部署清单应用于适当的“Deployment”资源。

但肯定还有更好的方法来处理这个问题。如果Deployment监视图像的“latest”标签的哈希值变化，那么就太棒了...也许它已经实现了？我尝试过，但没有成功。 如果您对如何更好地处理Deployment的部署有任何想法或见解，将不胜感激 :)

- Leetbulb

Answer 1

部署（Deployment）仅监视 Pod 模板 (.spec.template) 的更改。如果镜像名称未更改，则不会更新 Deployment。您可以通过更改 Pod 模板来触发滚动更新（使用 Deployment），例如，将其标记为提交哈希。此外，您需要设置 .spec.template.spec.containers.imagePullPolicy 为 Always（如果指定了 :latest 标签且无法更新，则默认设置为 Always），否则镜像将被重复使用。

- janetkuo

---

明白了。感谢您的回复，很抱歉我没有早点看到它。最终，我通过实现问题中的第二个工作流来解决了这个问题。我编写了一个包装器，围绕 kubectl apply 进行了封装，以便插入环境变量令牌。使用这个包装器，我可以构建镜像，将其标记为构建 ID，并触发关联的 Deployment 存储库的后续构建/部署，在那里它将获取传递的镜像构建 ID 并填充适当的令牌，例如 image: app:{{ IMAGE_BUILD_REF }}。 - Leetbulb

然而，我建议不要使用:latest标签，原因在于：http://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers/ - 参见“6）不要仅使用“latest”标签”。 - janetkuo

Answer 2

我们已经实践了一段时间所谓的GitOps。

我们拥有一个reconciliation operator，它将集群连接到配置存储库，并确保在该存储库中找到的任何Kubernetes资源（包括CRD）都应用于集群。它允许进行特别部署，但对于在git中定义的任何特别更改将在下一个协调周期中被撤消。此操作员还能够观察任何图像注册表以获取新标签，然后更新Deployment、DaemonSet和StatefulSet类型对象的图像属性。它首先在git中进行更改，然后将其应用于集群。

因此，在CI中，您需要执行以下操作：

1. 构建容器。
2. 将镜像标记为<commit_hash>。
3. 将镜像推送到存储库。

只要您将代理连接到正确的配置存储库，应用程序Deployment对象就可以由代理负责处理剩余工作。

有关高级概述，请参阅：

• Google Cloud平台和Kubernetes
• 部署应用程序和管理发布

---

声明：我是 Kubernetes 贡献者和 Weaveworks 员工。我们构建开源和商业工具，帮助人们更快地将 Kubernetes 推向生产。

- errordeveloper

---

GitOps是一种反模式。它与持续交付不兼容 - 在持续交付中，您希望部署镜像并在集群中运行集成测试。 - Jonas

这是不正确的，GitOps并不会阻止您在集群中运行集成测试。 - errordeveloper