こんにちは。SREの菅原です。
突然ですがKustomize便利ですよね。
弊社ではKubernetesのManifest管理にKustomizeを使っています。Kustomizeの機能は複数ありどれも便利なのですが、今回はその中でもComponentsという機能を使って便利なのかどうなのかという話をしたいと思います。
KustomizeのComponentsについて
※KustomizeのComponentsについて話したいので、Kustomize自体の説明は省きます。
Kustomize Componentsはv3.7.0から使えるようになった機能です。
どのような機能かというと、componentsというディレクトリにManifestを配置します。それを各環境のkustomization.yamlから指定してあげることでそのManifestを各環境にapplyすることができます。
例えば、DatadogのManifestをcomponentsディレクトリに配置してproduction環境だけにapplyするようにしてみます。
以下のようにcomponents/datadogというディレクトリと各環境用ディレクトリを作ります。(※わかりやすさのために、Manifestは一部割愛しています。)
├── base │ └── kustomization.yaml ├── components │ └── datadog │ ├── datadog.yaml │ └── kustomization.yaml └── overlays ├── staging │ └── kustomization.yaml ├── local │ └── kustomization.yaml └── production └── kustomization.yaml
そして以下のようにkustomization.yamlを作成します。
- components/datadog/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1 kind: Component resources: - datadog.yaml
- overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization commonLabels: env: production resources: - ../../base components: - ../../components/datadog
これでproduction環境だけにDatadogのリソースをapplyすることができました。つまり、Componentsは必要な環境にだけManifestをapplyするということができます。
Componentsの便利なところ
Componentsは簡単にManifestを追加できるので、各環境すべてに入れたくは無いけれどスポットで使いたいというケースで便利だと感じます。
例えば普段はDatadogをproduction環境だけで使っているけれど、検証のため一時的にstaging環境へ入れたいというパターンで便利になります。
以下のようにcomponentsをstagingのkustomization.yamlに追加してapplyするだけで簡単に配置できます。
- overlays/staging/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization commonLabels: env: staging resources: - ../../base # datadogをstagingに追加 components: - ../../components/datadog
ご存知の通りKustomizeにはpatchesStrategicMergeというものがあります。これはbaseにある変更元のファイルにoverlayで用意したpatchファイルをマージして、環境毎の差分を吸収する方法です。もちろんこの方法でもやり方によっては必要な環境にだけ配置できるのですが、Componentsを使ったほうが少ない修正で済みます。
Componentsで躓いたところ
便利なComponents機能ですがnamespaceの設定で躓いたところがありましたので注意が必要です。 何をしたかというとDatadogにnamespaceを一括で設定したかったので以下のような設定をしてみました。
├── base │ └── kustomization.yaml ├── components │ ├── datadog │ │ ├── datadog.yaml │ │ ├── namespace.yaml │ │ └── kustomization.yaml │ ├── cluster-autoscaler │ │ ├── cluster-autoscaler.yaml │ │ └── kustomization.yaml │ └── metrics-server │ ├── metrics-server.yaml │ └── kustomization.yaml └── overlays ├── staging │ └── kustomization.yaml ├── local │ └── kustomization.yaml └── production └── kustomization.yaml
- components/datadog/namespace.yaml
apiVersion: v1 kind: Namespace metadata: name: datadog
- components/datadog/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1 kind: Component # namespaceを追加 namespace: datadog resources: - datadog.yaml - namespace.yaml
- overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization commonLabels: env: production resources: - ../../base components: - ../../components/cluster-autoscaler - ../../components/datadog - ../../components/metrics-server
この設定でapplyするとdatadogだけではなく、cluster-autoscalerやmetrics-serverもdatadog namespaceに配置されてしまいます。つまり、componentsディレクトリ配下に配置している他のManifestにも影響が及んでしまいます。
この挙動に関してはこちらのコメントで詳しく説明されており、Componentsではなく通常のKustomizationで行うことを勧められています。
なのでnamespaceを設定したい場合は以下のような通常のKustomizationで設定をするか、datadog.yaml自体にnamespaceを設定する方が良さそうです。
├── base │ └── kustomization.yaml ├── components │ ├── cluster-autoscaler │ │ ├── cluster-autoscaler.yaml │ │ └── kustomization.yaml │ └── metrics-server │ ├── metrics-server.yaml │ └── kustomization.yaml └── overlays ├── staging │ └── kustomization.yaml ├── local │ └── kustomization.yaml └── production ├── datadog │ ├── datadog.yaml │ ├── kustomization.yaml │ └── namespace.yaml └── kustomization.yaml
まとめ
今回はKustomize Componentsを使ってみて便利だったところ、躓いたところを紹介してみました。Componentsは選択的に環境に配置することができて便利なのですが、通常のKustomizeとComponentsどちらを使うかというとその時の状況によるかなと思います。
Componentsを使ってみたいと考えている方の参考になれば、非常に嬉しい限りです。
