为什么它不会对已经访问过的节点进行

Question

我正在使用kubectl kustomize命令部署具有类似配置的多个应用程序(解析器和接收器(，并且我在kustomization.yaml文件的层次结构方面遇到了问题(不了解什么是可能的，什么是不可能的(。

我在自定义目录中运行kustoize命令，如下所示：$ kubectl kustomize overlay/pipeline/parsers/commercial/dev-这很好，它根据需要生成kustomization.yaml#1中定义的预期输出。不起作用的是，它不会自动执行#2 kustomation，它位于(已经遍历的(目录路径2级以上。#2 kustomization.yaml包含所有解析器环境通用的configMap创建。我不想在每个env中重复这些。当我试图从#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
│

这是我的第一个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

Answer 1

问题在于您的结构中。基本中的每个条目都应解析为一个包含一个kustomization.yaml文件的目录。叠加也是如此。现在，我认为在一个例子上解释会更容易(我将使用$来显示去往哪里(：

├── base $1
│   ├── deployment.yaml
│   ├── kustomization.yaml $1
│   └── service.yaml
└── overlays
├── dev $2
│   ├── kustomization.yaml $2
│   └── patch.yaml
├── prod #3
│   ├── kustomization.yaml $3
│   └── patch.yaml
└── staging #4
├── kustomization.yaml $4
└── patch.yaml

每个条目都解析为相应的kustomization.yaml文件。Base $1解析为kustomization.yaml $1，dev $2解析为kustomization.yaml $2，依此类推

然而，在您的用例中：

├── base $1
|   ├── kustomization.yaml $1
│   ├── logstash-config.yaml
│   └── successful-vanilla-ls7.8.yaml
├── install_notes.txt
├── overlay
│   └── pipeline
│       ├── logstash-config.yaml
│       ├── parsers
│       │   ├── commercial
│       │   │   ├── dev $2
│       │   │   │   ├── dev-patches.yaml
│       │   │   │   ├── kustomization.yaml $2 
│       │   │   │   ├── logstash-config.yaml
│       │   │   │   └── parser-config.yaml
│       │   │   ├── prod $3
│       │   │   ├── stage $4
│       │   ├── kustomization.yaml $???
│       │   ├── logstash-config.yaml
│       │   ├── parser-config.yaml
│

没有什么能解决你的第二个kustomization.yaml。

因此，为了使其发挥作用，您应该将这些文件分别放在每个环境下。下面你可以找到更多的例子来展示tipic目录结构应该是什么样子的来源：

• 组件

• 目录布局

• GitHub