【问题标题】:Create variable in kustomize manifest在 kustomize 清单中创建变量
【发布时间】:2021-09-28 15:33:38
【问题描述】:

我有一个我认为常见的用例,但我真的很难找到解决方案:

我想在我们的部署中重用Kustomize 补丁中的变量。具体来说,我们使用提交 ID 来引用图像标签(用例 A)和与部署相关的 k8s 作业(用例 B)。

我们使用一种设置,其中每个 ArgoCD 应用程序都有一个 /base/ 文件夹和 /overlays/[environment-name],此基础使用 kustomization.yaml 进行修补。

用例 A:

一个非常简单的用法 - 在 /overlays/[environment-name] 我们有一个 kustomization.yaml 它使用:

images:
- name: our-aws-repo-url
  newName: our-aws-repo-url
  newTag: commit-id

工作就像一个魅力,因为我们可以将其重新用于部署本身以及它的相关作业,所有这些都只需一个提交参考。

用例 B:

问题:

我们使用 N 个 Jobs 来例如为 0 次停机部署执行迁移,我们运行运行迁移的 alembic 容器,并且我们有一个 waitforit initContainer 来监听作业以完成,即当迁移成功以便部署时。

现在的问题是我需要在一个服务的覆盖层中触摸 4 个文件来修补各处的 id(我们用它来识别作业):

  • deployment.yaml 像这样:
- image: groundnuty/k8s-wait-for:v1.4
  imagePullPolicy: IfNotPresent
  args: 
   - "job"
   - "job-commit-id"
  • job.yaml 本身更改 Job 的重新触发以进行新部署/潜在迁移:
apiVersion: batch/v1
kind: Job
metadata:
  name: job-commit-id

  • kustomization.yaml,如用例 A 中所述。

我认为应该可行的是:

  1. 在 kustomization.yaml 中以某种方式定义变量 commit-id
  2. 对于用例 A 和 B,请执行以下操作:
apiVersion: batch/v1
kind: Job
metadata:
  name: job-${commit-id}

- image: groundnuty/k8s-wait-for:v1.4
  imagePullPolicy: IfNotPresent
  args: 
   - "job"
   - "job-${commit-id}"
images:
- name: our-aws-repo-url
  newName: our-aws-repo-url
  newTag: ${commit-id}

目标:当开发人员为发布做 PR 时,他们应该只触摸一个对提交 ID 的引用以防止拼写错误等(也更容易审查,而不是在 N 个地方检查提交 ID)

警告:我相信还有另一种方法可以代替 Jobs 进行迁移,但这通常是常见的:如何在 kustomize 中重用变量。

我知道我可以在 kustomize 中引用 ENV 变量,但我想在清单中重用一个变量。

【问题讨论】:

  • 为什么不使用带值的舵图?这样,您可以使用新值“修补”(升级)掌舵,并将所需的变量用作值
  • 我专门针对 kustomize 提出一个问题,因为这是我们选择的。我知道 Helm 可以做到这一点,但我宁愿先问这个问题,而不是仅仅因为这个原因重构我们所有的部署。 Helm 有很多其他的复杂性,我真的不需要。
  • 您也可以使用 Kustomization 编辑来更新您的 Kustomization 资源,这会导致您将拥有一个用于更新的脚本
  • @CodeWizard 你能更具体一点吗?你的意思是一个CLI命令?请记住,我们使用的是实际部署清单的 ArgoCD
  • 我知道你在使用 ArgoCD,在这里阅读:argoproj.github.io/argo-cd/user-guide/parameters,你应该使用.argocd-source.yaml

标签: kubernetes kustomize argocd gitops


【解决方案1】:

但我想在清单中重用一个变量。

这不是您通常使用 Kustomize 的方式。使用 Kustomize 时,声明性显式是一件好事。

当开发人员为发布做 PR 时,他们应该只触摸一个对提交 ID 的引用以防止拼写错误等(也更容易查看,而不是在 N 个地方检查提交 ID)

是和不是。

在我看来,四个地方的变化不应被视为问题。更新四个地方需要人工是问题

解决人工劳累的方法通常是自动化。通过在自动化管道(例如 Jenkins - 或 shellscript)中使用 yq,您可以自动执行清单更新以采用单个参数 - 在您拥有可用的 git“提交 ID”后,可以选择直接为每个构建自动执行此操作。管道需要运行四个yq-command 来更新四个 Yaml 字段。参见例如assign operationgithub action - pipeline example。不需要其他变量。

【讨论】:

  • 我喜欢这种方法,也喜欢 yq 背后的想法 - 只需要找到一种方法让我的服务仓库检查清单仓库并更新字段并制作 PR,但我想这是一个单独的问题:) 我会看看我能不能把它缝在一起
  • 更新:我们按照您的建议解决了问题!花了我们一分钟,但我们现在已经使用了一个星期,我们已经节省了很多时间,非常感谢!我们还决定将其打包到 GH 工作流程中(GH Action 即将推出),因此具有类似设置的人也可以从该方法中受益。 github.com/kranushealth/gitops-release-pr
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-06-15
  • 2020-05-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多