为什么它不会 kustomize 已经访问过的节点
Why won't it kustomize the node already visited
我正在使用 kubectl kustomize
命令部署具有相似配置的多个应用程序(解析器和接收器),我在 kustomization.yaml 文件的层次结构方面遇到问题(不了解什么是可能的,什么不是).
我运行 自定义目录中的kustomize命令如下:
$ kubectl kustomize overlay/pipeline/parsers/commercial/dev
- 这工作正常,它根据需要产生在 kustomization.yaml #1 中定义的预期输出。不起作用的是它不会自动执行 #2 kustomization,它位于上面 2 级的(已经遍历的)目录路径中。 #2 kustomization.yaml 包含所有解析器环境通用的 configMap 创建。我不想在每个环境中重复这些。当我尝试从 #2 引用 #1 时,我收到有关循环引用的错误,但它无法 运行 配置创建。
我有如下目录结构树:
custom
├── base
| ├── kustomization.yaml
│ ├── logstash-config.yaml
│ └── successful-vanilla-ls7.8.yaml
├── install_notes.txt
├── overlay
│ └── pipeline
│ ├── logstash-config.yaml
│ ├── parsers
│ │ ├── commercial
│ │ │ ├── dev
│ │ │ │ ├── dev-patches.yaml
│ │ │ │ ├── kustomization.yaml <====== #1 this works
│ │ │ │ ├── logstash-config.yaml
│ │ │ │ └── parser-config.yaml
│ │ │ ├── prod
│ │ │ ├── stage
│ │ ├── kustomization.yaml <============= #2 why won't this run automatically?
│ │ ├── logstash-config.yaml
│ │ ├── parser-config.yaml
│
这是我的#1 kustomization.yaml:
bases:
- ../../../../../base
namePrefix: dev-
commonLabels:
app: "ls-7.8-logstash"
chart: "logstash"
heritage: "Helm"
release: "ls-7.8"
patchesStrategicMerge:
- dev-patches.yaml
这是我的 #2 kustomization.yaml 文件:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
# generate a ConfigMap named my-generated-configmap-<some-hash> where each file
# in the list appears as a data entry (keyed by base filename).
- name: logstashpipeline-parser
behavior: create
files:
- parser-config.yaml
- name: logstashconfig
behavior: create
files:
- logstash-config.yaml
问题出在您的结构中。 base should resolve to a directory containing one kustomization.yaml
file. The same goes with overlay 中的每个条目。现在,我认为用一个例子来解释会更容易(我将使用 $ 来显示什么去哪里):
├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── dev
│ ├── kustomization.yaml
│ └── patch.yaml
├── prod #3
│ ├── kustomization.yaml
│ └── patch.yaml
└── staging #4
├── kustomization.yaml
└── patch.yaml
每个条目都解析为对应的 kustomization.yaml
文件。 Base
解析为 kustomization.yaml
,dev
解析为 kustomization.yaml
等等。
但是在您的用例中:
├── base
| ├── kustomization.yaml
│ ├── logstash-config.yaml
│ └── successful-vanilla-ls7.8.yaml
├── install_notes.txt
├── overlay
│ └── pipeline
│ ├── logstash-config.yaml
│ ├── parsers
│ │ ├── commercial
│ │ │ ├── dev
│ │ │ │ ├── dev-patches.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ ├── logstash-config.yaml
│ │ │ │ └── parser-config.yaml
│ │ │ ├── prod
│ │ │ ├── stage
│ │ ├── kustomization.yaml $???
│ │ ├── logstash-config.yaml
│ │ ├── parser-config.yaml
│
您的第二个 kustomization.yaml
没有任何结果。
因此,要使其正常工作,您应该将这些文件分别放在每个环境下。
您可以在下面找到带有更多示例的资源,这些示例显示了典型的目录结构应该是什么样子:
我正在使用 kubectl kustomize
命令部署具有相似配置的多个应用程序(解析器和接收器),我在 kustomization.yaml 文件的层次结构方面遇到问题(不了解什么是可能的,什么不是).
我运行 自定义目录中的kustomize命令如下:
$ kubectl kustomize overlay/pipeline/parsers/commercial/dev
- 这工作正常,它根据需要产生在 kustomization.yaml #1 中定义的预期输出。不起作用的是它不会自动执行 #2 kustomization,它位于上面 2 级的(已经遍历的)目录路径中。 #2 kustomization.yaml 包含所有解析器环境通用的 configMap 创建。我不想在每个环境中重复这些。当我尝试从 #2 引用 #1 时,我收到有关循环引用的错误,但它无法 运行 配置创建。
我有如下目录结构树:
custom
├── base
| ├── kustomization.yaml
│ ├── logstash-config.yaml
│ └── successful-vanilla-ls7.8.yaml
├── install_notes.txt
├── overlay
│ └── pipeline
│ ├── logstash-config.yaml
│ ├── parsers
│ │ ├── commercial
│ │ │ ├── dev
│ │ │ │ ├── dev-patches.yaml
│ │ │ │ ├── kustomization.yaml <====== #1 this works
│ │ │ │ ├── logstash-config.yaml
│ │ │ │ └── parser-config.yaml
│ │ │ ├── prod
│ │ │ ├── stage
│ │ ├── kustomization.yaml <============= #2 why won't this run automatically?
│ │ ├── logstash-config.yaml
│ │ ├── parser-config.yaml
│
这是我的#1 kustomization.yaml:
bases:
- ../../../../../base
namePrefix: dev-
commonLabels:
app: "ls-7.8-logstash"
chart: "logstash"
heritage: "Helm"
release: "ls-7.8"
patchesStrategicMerge:
- dev-patches.yaml
这是我的 #2 kustomization.yaml 文件:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
# generate a ConfigMap named my-generated-configmap-<some-hash> where each file
# in the list appears as a data entry (keyed by base filename).
- name: logstashpipeline-parser
behavior: create
files:
- parser-config.yaml
- name: logstashconfig
behavior: create
files:
- logstash-config.yaml
问题出在您的结构中。 base should resolve to a directory containing one kustomization.yaml
file. The same goes with overlay 中的每个条目。现在,我认为用一个例子来解释会更容易(我将使用 $ 来显示什么去哪里):
├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── dev
│ ├── kustomization.yaml
│ └── patch.yaml
├── prod #3
│ ├── kustomization.yaml
│ └── patch.yaml
└── staging #4
├── kustomization.yaml
└── patch.yaml
每个条目都解析为对应的 kustomization.yaml
文件。 Base
解析为 kustomization.yaml
,dev
解析为 kustomization.yaml
等等。
但是在您的用例中:
├── base
| ├── kustomization.yaml
│ ├── logstash-config.yaml
│ └── successful-vanilla-ls7.8.yaml
├── install_notes.txt
├── overlay
│ └── pipeline
│ ├── logstash-config.yaml
│ ├── parsers
│ │ ├── commercial
│ │ │ ├── dev
│ │ │ │ ├── dev-patches.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ ├── logstash-config.yaml
│ │ │ │ └── parser-config.yaml
│ │ │ ├── prod
│ │ │ ├── stage
│ │ ├── kustomization.yaml $???
│ │ ├── logstash-config.yaml
│ │ ├── parser-config.yaml
│
您的第二个 kustomization.yaml
没有任何结果。
因此,要使其正常工作,您应该将这些文件分别放在每个环境下。 您可以在下面找到带有更多示例的资源,这些示例显示了典型的目录结构应该是什么样子: