使用 Kubernetes 和 Helm 进行配置管理

Question

我是 Kubernetes 和 Helm 的新手。我来自一个普通的 Docker/docker-compose 世界。

我有一些运行多个 Docker 容器的复杂服务，这些服务需要大量的配置参数和逻辑。 docker 化的服务在启动时需要很多不同的配置文件、键和命令行参数。我还需要一些只能在容器内部执行的运行时配置逻辑（必须生成一些配置元素）。

我最终做的是编写一个 shell 脚本（用作 CMD），它需要环境变量、定义默认值、将这些环境变量转换为命令参数和配置文件。

---

这是一个关于我如何构建它的非工作示例，没有考虑 Kubernetes 和 Helm。

Dockerfile

...
CMD [ "./bootstrap.sh" ]

bootstrap.sh（打包在镜像中）

# Define default values, if no environment variables provided on
# on "docker run"
export CONFIG_VALUE_A=${CONFIG_VALUE_A:="a"} 
export CONFIG_VALUE_B=${CONFIG_VALUE_B:="b"}
export CONFIG_VALUE_C=${CONFIG_VALUE_C:="c"}

# write CONFIG_VALUE_A to file
echo ${CONFIG_VALUE_A} > ./some-config-file-a.cfg

ARGS="--config-file-a ./some-config-file-a.cfg --config-value-b ${CONFIG_VALUE_B} --config-value-c ${CONFIG_VALUE_C}"
exec ./my-app ${ARGS}

这样做的好处是使用环境变量，我有一个标准的配置接口，不需要处理配置文件的卷。

---

现在，我正在 Helm 中加入 Kubernetes。 Helm 有自己的参数概念，使用 values.yaml。要将其与上面已有的内容结合起来，我只需将 values.yaml 中的值与这些环境变量进行映射。

deployment.yaml

...
 spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: my-app
        ...
        env:
        - name: "CONFIG_VALUE_A"
          value: {{ .Values.config.value_a }}
        - name: "CONFIG_VALUE_B"
          value: {{ .Values.config.value_b }}
        - name: "CONFIG_VALUE_C"
          value: {{ .Values.config.value_c }}

values.yaml

config:
  value_a: a
  value_b: b
  value_c: c

但是，我在三个配置层中来回映射值（helm 模板 => 容器环境变量 => 配置文件/CLI 参数）违反了 DRY 原则，并增加了很多潜在的拼写错误/错误以后再找。

---

理想情况下，

• 我只需在 deployment.yaml 中定义我的配置结构，在 Helm 的 default.yaml 中定义一次默认值
• 我会将这些值直接传递给容器，让某种配置脚本构建命令行参数和配置文件，而不使用环境变量作为中间层
• 使用某种类型安全的配置格式
• 尽量减少总行数
• 保持配置文件的可读性，不要混淆不同的语言（即在 YAML 文件中定义的 JSON）

您如何使用 Kubernetes、Helm 和 Docker 解决复杂的配置管理问题？

Answer 1

在 Kubernetes 世界中，配置通常由 ConfigMap 管理，它是配置的主要存储。

在你的情况下，我认为你可以这样做（至少如果我会这样做，我会那样做）：

1. 在 Helm 中使用种类 ConfigMap 创建另一个模板，并在那里为应用程序创建一个 .cfg 文件的结构。 Helm 使用 GoTemplate 格式，因此很容易在那里创建任何结构，包括迭代等。
2. 将所有默认值添加到values.yaml 文件。
3. 编辑deployment.yaml。将.cfg 文件的挂载添加到容器中的路径并将应用程序指向它。
4. 使用带有值的附加文件（或多个文件一次）并将默认值覆盖写入其中。

所以，就是这样。我们有：

• 应用格式静态配置的ConfigMap，我们可以随时查看。
• 我们只能在一个地方编辑它 - 在我们的默认值中并覆盖 yamls。
• 可读的key: value YAML 格式。
• 配置文件生成和排序的所有逻辑都在一个容器中，所以我们不需要构建一个新版本只是为了改变选项的顺序。