KubernetesのKustomizationの使い方まとめ
内容
KubernetesのKustomizationの使い方をまとめます。
Kubernetesでkustomizationを使う理由
yamlファイルはエンジニアなら誰しも読める共通のフォーマットですが、import機能がなく、for-eachやif文のようなプログラミング構文も使えないため、たくさんのyamlファイルを組み合わせてクラスターを構成するKubernetesの場合、どうしても使いづらさが目立ちます。
そんな使いづらさを解消してくれるのがKustomizationです。
複数yamlファイルをまとめることはもちろん、yamlの一部を修正したり上書きしたりする機能を提供しています。
サンプルソース
github上に今回解説するkustomizationのサンプルソースをあげています。
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.yaml
と pod.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等のテンプレートファイルを利用して効率的に管理したほうがいいでしょう。
note
勉強法やキャリア構築法など、エンジニアに役立つ記事をnoteで配信しています。
Discussion