😎

KubernetesのKustomizationの使い方まとめ

2023/01/19に公開約6,600字

内容

KubernetesのKustomizationの使い方をまとめます。

Kubernetesでkustomizationを使う理由

yamlファイルはエンジニアなら誰しも読める共通のフォーマットですが、import機能がなく、for-eachやif文のようなプログラミング構文も使えないため、たくさんのyamlファイルを組み合わせてクラスターを構成するKubernetesの場合、どうしても使いづらさが目立ちます。
そんな使いづらさを解消してくれるのがKustomizationです。
複数yamlファイルをまとめることはもちろん、yamlの一部を修正したり上書きしたりする機能を提供しています。

サンプルソース

github上に今回解説するkustomizationのサンプルソースをあげています。

https://github.com/rara-tan/k8s-kustomization-demo

Kustomizationの使い方

複数yamlファイルをまとめる

複数のyamlファイルを同時applyしたい場合、以下のようにkustomizationを設定します。

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ./service.yaml
  - ./pod.yaml

上記ファイルがあるディレクトリに対して、

$ ls
kustomization.yaml      pod.yaml                service.yaml

$ kubectl apply -k .

を実行すると、service.yamlpod.yaml の内容がKubernetesクラスターにapplyされます。

また、以下のコマンドを実行することで、kustomizationが実行するyamlファイルを確認することができます。

$ ls
kustomization.yaml      pod.yaml                service.yaml

$ kustomize build .
apiVersion: v1
kind: Service
metadata:
  name: test-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: test-app
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-app
  name: test-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
      - image: nginx
        name: nginx

Deploymentのreplica数を変更する

複数ファイルをまとめてapplyできるだけではなく、一部のparameterをkustomizationファイルから変更することも可能です。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./service.yaml
- ./deployment.yaml
replicas:
- name: patch-replica
  count: 3

上記のような記述をすることで、patch-replica というnameのDeploymentのreplica数を3に変更することができます。

特定のparamsを変更する

replica数だけではなく、kustomizationで管理しているresourceの他のparamsも修正・追加・削除することが可能です。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
- ./namespace.yaml
patches:
  - target:
      version: v1
      group: apps
      kind: Deployment
      name: patch-other
    patch: |-
      - op: replace
        path: /metadata/namespace
        value: patch-other-parameters
      - op: add
        path: "/metadata/labels/patch"
        value: patched-value

上記は、patch-other というnameのDeploymentの

  • namespace を変更
  • label を追加

しているkustomizationファイルです。
patchesパラメーターのtargetにて対象のresourceを指定し、patchに修正内容を指定しています。

patchファイルを切り出す

先ほどの特定のparamsを変更する例は、yaml構文をファイルに埋め込んで記載していました。(patches.patch)
この部分を他ファイルに切り出すことも可能です。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
- ./namespace.yaml
patches:
  - target:
      version: v1
      group: apps
      kind: Deployment
      name: patch-by-file
    path: ./patch.yaml

patch.yaml

- op: replace
  path: /metadata/namespace
  value: patch-by-files

Strategic Merge Patch

Strategic Merge Patchという機能を使えば、不完全な(修正したい内容だけ記載した)yamlファイルをpatchとして使うことも可能です。

例えば、

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: strategic-merge-patch
  name: strategic-merge-patch
spec:
  replicas: 1
  selector:
    matchLabels:
      app: strategic-merge-patch
  template:
    metadata:
      labels:
        app: strategic-merge-patch
    spec:
      containers:
      - image: nginx
        name: nginx

このような、deploymentに対して、resource limitとrequestを追加したい場合、

patch.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: strategic-merge-patch
spec:
  template:
    spec:
      containers:
      - name: nginx
        resources:
          limits:
            cpu: "300m"
            memory: "512Mi"
          requests:
            cpu: "300m"
            memory: "512Mi"

上記のような、resourceに関する記載のみしたyamlファイルを作成し、以下のようなkutomizationファイルをapplyすれば、patchファイルで指定したresource情報をもったDeploymentが作成されます。

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
patchesStrategicMerge:
  - patch.yaml

試しに、上記の条件でどのようなyamlファイルがkustomizationによって作成されるのかを検証します。

$ kustomize build .
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: strategic-merge-patch
  name: strategic-merge-patch
spec:
  replicas: 1
  selector:
    matchLabels:
      app: strategic-merge-patch
  template:
    metadata:
      labels:
        app: strategic-merge-patch
    spec:
      containers:
      - image: nginx
        name: nginx
        resources:
          limits:
            cpu: 300m
            memory: 512Mi
          requests:
            cpu: 300m
            memory: 512Mi

patchファイルで指定したresources情報が追記されたDeploymentが作成されました。

Config Map Generator

kubernetesのConfigMapをKustomizationで管理することも可能です。

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: patch-other
  name: patch-other
spec:
  replicas: 1
  selector:
    matchLabels:
      app: patch-other
  template:
    metadata:
      labels:
        app: patch-other
    spec:
      containers:
      - image: nginx
        name: nginx
        env:   
        - name: ENV
          valueFrom:
            configMapKeyRef:
              name: test-cm
              key: env

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
configMapGenerator:
- name: test-cm
  literals:
  - env=prod

上記2ファイルが含まれたディレクトリで、kutomize build を実行すると

$ kustomize build .        
apiVersion: v1
data:
  env: prod
kind: ConfigMap
metadata:
  name: test-cm-b7k5b48kg7
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: patch-other
  name: patch-other
spec:
  replicas: 1
  selector:
    matchLabels:
      app: patch-other
  template:
    metadata:
      labels:
        app: patch-other
    spec:
      containers:
      - env:
        - name: ENV
          valueFrom:
            configMapKeyRef:
              key: env
              name: test-cm-b7k5b48kg7
        image: nginx
        name: nginx

といった具合に、kustomization.yamlファイルで定義したconfigmapの値がdeploymentに追記されます。  
そして、一点だけ注目するポイントは、ConfigMapのnameにhash化された文字列が追記されていることです。このhashはconfigmapのvalueが変更されるたびに変更されます。この挙動のおかげで、kustomizationで管理しているconfigmapの値が変更されるたびにその値を利用しているDeploymentのRolling Updateが実行され、Kubernetes環境にConfigmapの変更が即座に反映されます。  
通常のConfigmapを利用している場合、手動でDeploymentをUpdateしないとConfigmapの変更が反映されないため、kustomizationでconfigmapを管理するのはとてもよい方法です。

まとめ

Kusomizationを利用すると、同一のファイルを利用して、環境ごとにパラメーターを変更しながら複数環境を作ることができます。Kubernetesのmanifestファイルの管理は煩雑になりがちなので、Kustomization等のテンプレートファイルを利用して効率的に管理したほうがいいでしょう。

Discussion

ログインするとコメントできます