kubernetes - Kubernetes configmaps 中的自动子目录？

Question

(大约 2 年前提出了一个非常相似的问题，虽然它专门关于 secret ，但我怀疑配置映射的故事有什么不同......但至少，我可以介绍用例以及为什么现有的解决方法不是对我们来说可行。)

给定一个简单的缩减 deployment.yaml :

apiVersion: apps/v1beta1
kind: Deployment
metadata: 
  name: example
spec:
  template: 
    spec:
      containers:
      - name: example
        volumeMounts:
        - name: vol
          mountPath: /app/Configuration
      volumes:
        - name: vol
          configMap:
            name: configs

和匹配的configmap.yaml :

apiVersion: v1
kind: ConfigMap
metadata:
  name: configs
  labels:
    k8s-app: example
data:
    example1.json: |-
        {
            "key1": "value1"
        }

    example2.json: |-
        {
            "key2": "value2"
        }

configmap.yaml 中的键，无论它们是什么，都只是作为文件创建，没有 deployment.yaml需要修改或具有除 mountPath 之外的任何细节。

问题是实际结构具有子文件夹来处理覆盖根的特定于区域的值:

Configuration \ example1.json
Configuration \ example2.json
Configuration \ us \ example1.json
Configuration \ us \ ca \ example2.json

对于可以想象到的许多不同的国家和地区以及每个单独配置的模块，它们的数量和性质显然会有所不同。目的是为最终用户提供一个工具，允许他们设置和管理这些配置，这将在幕后自动生成 configmap.yaml并在 Kubernetes 中更新它。

但是，除非我还没有找到一个技巧，否则这似乎超出了 kubernetes 的能力，在几个方面。

首先，没有语法允许指定作为目录的 configmap 键，也不能在键中包含子目录路径:

data:
    # one possible approach (currently complains that it doesn't validate '[-._a-zA-Z0-9]+')
    /us/example1.json: |-
        {
            "key1": "value1"
        }

    # another idea; this obviously results in 'invalid type for io.k8s.api.core.v1.ConfigMap.data: got "map", expected "string"'
    us:
        example2.json: |-
            {
                "key2": "value2"
            }

那么是 我们的选择来实现这一点？

好吧，我们可以使用 items: -key: path: 将键映射到特定位置deployment.yaml 的 volumes: -configMap: 中的方法节点，

和/或在 deployment.yaml 的 volumeMounts: 中生成多个节点节点，

使用 subPath: (这与在 items: -key: -path: 中使用 volumes: configMap: 基本相同)，

或每个子目录的单独的配置映射，并将它们全部安装为不同的volumes在deployment.yaml 中。

所有这些方法都需要对 deployment.yaml 进行大量且极其冗长的更改，泄露它不应该有任何理由知道的知识，使其可变并不断重新生成而不是静态的，从而使部署的设置更新变得复杂 pod 等。等等。这只是不好。所有这一切只是为了映射一个目录，只是因为它包含子目录......

这肯定不是它应该工作的方式吗？我错过了什么？我应该如何进行？

Answer 1

从“容器原生”的角度来看，拥有一个由应用程序在启动时处理以达到其规范配置的配置文件的大型文件系统树是一种反模式。最好有一个生成单个文件的工作流，该文件可以存储在 ConfigMap 中并以最终形式轻松检查。例如，参见 nginx 入口。

但显然并不是每个人都在重写他们的应用程序以更好地与 kubernetes 方法保持一致。在部署时将配置文件的完整目录树放入容器中的最简单方法是使用 initContainers 和 emptyDir 挂载。

将配置文件树打包到一个容器中(有时称为“仅数据”容器)，并让容器启动脚本将配置树复制到 emptyDir 挂载中。然后应用程序可以按预期使用树。