4

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

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

我们使用一个设置，其中对于每个 ArgoCD 应用程序我们都有一个/base/文件夹，并且/overlays/[environment-name]这个基础使用kustomization.yaml.

用例 A：

一个非常简单的用法 -/overlays/[environment-name]我们有一个kustomization.yamlwhich 使用：

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

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

用例 B：

问题：

我们使用 N 个 Job 来为 0 次停机部署进行迁移，我们运行运行迁移的 alembic 容器，并且我们有一个waitforit initContainer监听 Job 以完成即当迁移成功以便部署。

现在的问题是，我需要在一个服务的覆盖中触摸 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. commit-id在 kustomization.yaml 中以某种方式定义变量和
  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 变量，但我想在清单中重用一个变量。

4

1 回答 1

1

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

这不是您通常使用 Kustomize 的方式。使用 Kustomize 时，事情是声明性和明确的，这是一件好事。

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

是和不是。

在我看来，四个地方的变化不应该被视为问题。更新四个地方还有人费力才是问题所在。

解决人力的方法通常是自动化。通过在自动化管道（例如 Jenkins - 或 shellscript）中使用yq，您可以自动执行清单更新以采用单个参数 - 在您拥有可用的 git“commit id”后，可以选择直接为每个构建自动化。管道需要运行四个yq命令来更新四个 Yaml 字段。请参阅分配操作和github 操作管道示例。不需要其他变量。

于 2021-09-28T16:50:52.280 回答