0

在我的 CICD 中，我是：

生成具有唯一标签的新图像。foo:dev-1339 并将其推送到我的图像存储库 (ECR)。然后我使用滚动更新来更新我的部署。

kubectl rolling-update frontend --image=foo:dev-1339

但我在这里有一个冲突。

如果我还需要更新存储在 deployment.yaml 文件中的部署对象的某些部分，该怎么办。让我们说加强健康检查或添加参数？

然后，当我将apply我的部署对象作为一个整体时，它将与当前副本集不同步，标签将被还原，并且我将丢失该图像更新，因为它存在于集群中。

如何避免这种竞争条件？

4

4 回答 4

2

这里的一个典型解决方案是使用像Helm或Kustomize这样的模板层。

在 Helm 中，您可以将 Kubernetes YAML 规范保存在一个名为chart的目录结构中，但带有可选的模板。您可以指定诸如

image: myname/myapp:{{ .Values.tag | default "latest" }}

然后部署图表

helm install myapp --name myapp --set tag=20191211.01

Helm 会跟踪这些值（在集群中的 Secret 对象中），因此它们不会在源代码控制中被跟踪。您可以签入带有设置的 YAML 格式文件，并用于helm install -f引用该文件。

在 Kustomize 中，您的 CI 工具需要kustomize.yaml为每个部署设置创建一个文件，但随后可以设置

images:
  - name: myname/myapp
    newTag: 20191211.01

如果您信任您的 CI 工具提交到源代码控制，那么它可以检查这个修改后的文件作为其部署序列的一部分。

于 2019-12-12T01:48:32.590 回答
1

命令式与声明式工作流程

有两种基本方法可kubectl用于将更改应用到集群。当您执行命令时，命令式方式是实验和开发环境的好方法。是命令式命令的一个例子。请参阅使用命令式命令管理 Kubernetes。kubectl rolling-updated

对于生产环境，建议使用声明式工作流，通过编辑清单文件，将它们存储在 Git 存储库中。提交或合并时自动启动 CICD 工作。kubectl apply -f <file>或者更有趣kubectl apply -k <file>的是这个工作流程的一个例子。请参阅使用配置文件的声明式管理或更有趣的使用 Kustomize 的声明式管理

CICD 用于构建映像和部署

从源代码构建工件，包括容器映像，可以在 CICD 管道中完成。管理应用程序配置并将其应用到 Kubernetes 集群也可以在 CICD 管道中完成。您可能希望全部自动化，例如进行持续部署并将两个管道组合成一个长管道。这是一个更复杂的设置，并且没有关于如何做到这一点的单一答案。当 build-parts 完成后，它可能会触发app 配置库中image字段的更新以触发 configuration-pipeline。

于 2019-12-11T15:20:53.223 回答
0

不幸的是，无论是从命令行还是通过 yaml 文件，都没有解决方案

于 2019-12-11T14:58:11.053 回答
0

根据此处的文档，“...部署是一个更高级别的控制器，它以声明方式自动滚动更新应用程序，因此建议使用”而不是使用复制控制器和kubectl rolling-update. 更新Deployment 的镜像将触发 Deployment 的推出。

一种方法可能是在源 repo 中的版本控制下更新部署配置 yaml（或 json），apply并将更改的部署配置从版本控制更新到集群。

于 2019-12-11T15:14:54.857 回答