Question

我正在使用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

Answer 1

问题出在您的结构之内。 base中的每个条目都应解析到一个包含一个class JsonMiddleware { /** * Accept JSON only * * @param Request $request * @param Closure $next * @return mixed */ public function handle($request, Closure $next) { $header = $request->header('Accept'); if ($header != 'application/json') { return response(['message' => 'Only JSON requests are allowed'], 406); } if (!$request->isMethod('post')) return $next($request); $header = $request->header('Content-type'); if (!Str::contains($header, 'application/json')) { return response(['message' => 'Only JSON requests are allowed'], 406); } return $next($request); } }文件的目录。 overlay也是如此。现在，我认为在一个示例上进行解释会更容易（我将使用$来显示行进方向）：

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 │的问题。

因此，要使其正常工作，应将这些文件分别放在每种环境下。您可以在下面找到带有更多示例的源代码，这些示例显示了典型目录结构的外观：

为什么不将已访问的节点汇总为一个

1 个答案: