使用共享 ConfigMap 时自定义覆盖

Question

我有一个由 Pod 组成的环境，它根据一个名为 、 或 的环境变量来处理CONF_ENV其test目标stage环境prod。

\n

Pod 内运行的应用程序跨环境具有相同的源代码，配置文件是根据CONF_ENV环境变量选择的。

\n

我将其封装CONF_ENV在*.properties文件中只是因为稍后我可能需要添加更多环境变量，但我确保每个属性文件包含预期的CONF_ENV例如：

\n

\n
• test.properites有CONF_ENV=test，
\n
• prod.properties有CONF_ENV=prod, 等等...
\n

\n

我很难使用 Kustomize 覆盖来完成这项工作，因为我想将 a 定义ConfigMap为同一覆盖内所有 Pod 的共享资源，例如test（每个 Pod 都在自己的目录中，需要时与其他内容一起）。

\n

所以想法是：

\n

\n
• base/（共享）与 的定义Namespace，ConfigMap（以及潜在的其他共享资源
\n
• base/pod1/定义 pod1 从共享中挑选ConfigMap（默认为test，但原则上可能不同）
\n

\n

然后是叠加：

\n

\n
• overlay/testCONF_ENV=test用（例如 foroverlay/test/pod1/等）修补基础
\n
• overlay/prod/CONF_ENV=prod用（例如 foroverlay/prod/pod1/等）修补基础
\n

\n

每个目录都有自己的kustomize.yaml.

\n

上面的方法不起作用，因为当进入 egoverlay/test/pod1/并调用命令kubectl kustomize .来检查输出 YAML 时，我会收到各种错误，具体取决于我如何定义 YAML 键bases:或resources:.

\n

我试图ConfigMap在整个CONF_ENV环境中共享，试图通过利用 Kustomize 的修补模式来最小化样板 YAML 。

\n

Kubernetes / Kustomize YAML 目录结构的工作方式如下：

\n

\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 base\n\xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 configuration.yaml # I am trying to share this!\n\xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n\xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 my_namespace.yaml # I am trying to share this!\n\xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 my-scheduleset-etl-misc\n\xe2\x94\x82   \xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n\xe2\x94\x82   \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 my_scheduleset_etl_misc.yaml\n\xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 my-scheduleset-etl-reporting\n\xe2\x94\x82   \xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n\xe2\x94\x82   \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 my_scheduleset_etl_reporting.yaml\n\xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 test.properties # I am trying to share this!\n\xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 overlay\n    \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 test\n        \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 kustomization.yaml # here I want tell "go and pick up the shared resources in the base dir"\n        \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 my-scheduleset-etl-misc\n        \xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n        \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 test.properties # I\'ve tried to share this one level above, but also to add this inside the "leaf" level for a given pod\n        \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 my-scheduleset-etl-reporting\n            \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n

\n

使用 Kustomize 的命令kubectl：

\n

\n
• 有时会抱怨共享命名空间不存在：
\n

\n

error: merging from generator &{0xc001d99530 {  map[] map[]} {{ my-schedule-set-props merge {[CONF_ENV=test] [] [] } <nil>}}}: \nid resid.ResId{Gvk:resid.Gvk{Group:"", Version:"v1", Kind:"ConfigMap", isClusterScoped:false}, Name:"my-schedule-set-props", Namespace:""} \ndoes not exist; cannot merge or replace\n

\n

\n
• 有时不允许在覆盖层内共享资源：
\n

\n

error: loading KV pairs: env source files: [../test.properties]: \nsecurity; file \'/my/path/to/yaml/overlay/test/test.properties\' \nis not in or below \'/my/path/to/yaml/overlay/test/my-scheduleset-etl-misc\'\n

\n

\n
• 当我尝试拥有多个基础时，有时不允许循环 - 共享资源和原始 Pod 定义：
\n

\n

error: accumulating resources: accumulation err=\'accumulating resources from \'../\': \n\'/my/path/to/yaml/overlay/test\' must resolve to a file\': \ncycle detected: candidate root \'/my/path/to/yaml/overlay/test\' \ncontains visited root \'/my/path/to/yaml/overlay/test/my-scheduleset-etl-misc\'\n

\n

kustomization.yamlpod 目录内的覆盖文件有：

\n

error: merging from generator &{0xc001d99530 {  map[] map[]} {{ my-schedule-set-props merge {[CONF_ENV=test] [] [] } <nil>}}}: \nid resid.ResId{Gvk:resid.Gvk{Group:"", Version:"v1", Kind:"ConfigMap", isClusterScoped:false}, Name:"my-schedule-set-props", Namespace:""} \ndoes not exist; cannot merge or replace\n

\n

kustomization.yaml覆盖层的根部有：

\n

error: loading KV pairs: env source files: [../test.properties]: \nsecurity; file \'/my/path/to/yaml/overlay/test/test.properties\' \nis not in or below \'/my/path/to/yaml/overlay/test/my-scheduleset-etl-misc\'\n

\n

基本目录kustomization.yaml包含 ConfigMap 的配置：

\n

error: accumulating resources: accumulation err=\'accumulating resources from \'../\': \n\'/my/path/to/yaml/overlay/test\' must resolve to a file\': \ncycle detected: candidate root \'/my/path/to/yaml/overlay/test\' \ncontains visited root \'/my/path/to/yaml/overlay/test/my-scheduleset-etl-misc\'\n

\n

含有configuration.yaml：

\n

bases:\n  - ../ # tried with/without this to share the ConfigMap\n  - ../../../base/my-scheduleset-etl-misc/\n

\n

我该怎么做呢？

\n

ConfigMap如何通过尽可能多地共享所有内容和 Pod 定义来确保最大限度地减少 YAML 数量？

\n

Answer 1

如果我正确理解你的目标，我认为你可能把事情过于复杂化了。我认为您需要在基础中定义一个通用属性文件，但您希望覆盖覆盖层中的特定属性。这是这样做的一种方法。

\n

在基地，我有：

\n

$ cd base\n$ tree\n.\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 example.properties\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n\xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 pod1\n    \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n    \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 pod.yaml\n

\n

其中example.properties包含：

\n

SOME_OTHER_VAR=somevalue\nCONF_ENV=test\n

\n

并kustomization.yaml包含：

\n

resources:\n  - pod1\n\nconfigMapGenerator:\n  - name: example-props\n    envs:\n      - example.properties\n

\n

我定义了两个覆盖层，test并且prod：

\n

$ cd ../overlays\n$ tree\n.\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 prod\n\xe2\x94\x82\xc2\xa0\xc2\xa0 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 example.properties\n\xe2\x94\x82\xc2\xa0\xc2\xa0 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n\xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 test\n    \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n

\n

test/kustomization.yaml看起来像这样：

\n

resources:\n- ../../base\n

\n

它只是导入而不进行任何更改，因为目录中base的值为。CONF_ENVbasetest

\n

prod/kustomization.yaml看起来像这样：

\n

apiVersion: kustomize.config.k8s.io/v1beta1\nkind: Kustomization\nresources:\n- ../../base\n\nconfigMapGenerator:\n  - name: example-props\n    behavior: merge\n    envs:\n      - example.properties\n

\n

看起来prod/example.properties像：

\n

CONF_ENV=prod\n

\n

如果我运行kustomize build overlays/test，我会得到输出：

\n

apiVersion: v1\ndata:\n  CONF_ENV: test\n  SOME_OTHER_VAR: somevalue\nkind: ConfigMap\nmetadata:\n  name: example-props-7245222b9b\n---\napiVersion: v1\nkind: Pod\nmetadata:\n  name: example\nspec:\n  containers:\n  - command:\n    - sleep\n    - 1800\n    envFrom:\n    - configMapRef:\n        name: example-props-7245222b9b\n    image: docker.io/alpine\n    name: alpine\n

\n

如果我运行kustomize build overlays/prod，我会得到：

\n

apiVersion: v1\ndata:\n  CONF_ENV: prod\n  SOME_OTHER_VAR: somevalue\nkind: ConfigMap\nmetadata:\n  name: example-props-h4b5tc869g\n---\napiVersion: v1\nkind: Pod\nmetadata:\n  name: example\nspec:\n  containers:\n  - command:\n    - sleep\n    - 1800\n    envFrom:\n    - configMapRef:\n        name: example-props-h4b5tc869g\n    image: docker.io/alpine\n    name: alpine\n

\n

也就是说，一切看起来都如您所期望的，给定 中的配置base，但我们为 提供了一个新值CONF_ENV。

\n

您可以在这里找到所有这些文件。

\n