ConfigMap
ConfigMapとは、設定情報などのKey-Valueで保持できるデータを保存しておくリソースです。Key-Valueといっても、nginx.confやhttpd.confのような設定ファイルそのもの自体も保存可能です。
ConfigMapの作成
ConfigMapは、GenericタイプのSecretとほぼ同じ方法で作成します。ここでは3通りの作成方法を紹介します。
- ファイルから作成する(--from-file)
- yamlファイルから作成する
- kubectlから直接作成する(--from-literal)
ConfigMapでは、ConfigMapの名前の中に、複数のKey-Value値が保存されます。nginx.conf全体をConfigMapの中に入れてもいいですし、nginx.confの設定パラメータだけを入れても問題ありません。それぞれの設定の粒度に合わせて決定して下さい。
ファイルから作成する場合
ファイルから作成する場合には、--from-fileを指定します。通常はファイル名がそのままKeyとなります。Key名を変更したい場合は--from-file=nginx.conf=sample-nginx.confなどのように指定して下さい。
既存のファイルを元にConfigMapを作成します。
リスト33:ConfigMapの作成
1 | $ kubectl create configmap sample-configmap --from-file=./nginx.conf |
作成したConfigMapを確認するには、kubectl getでjsonかyamlフォーマットで出力し、dataの部分を確認します。
リスト34:ConfigMapの内容を確認
1 | $ kubectl get configmap sample-configmap -o json | jq .data |
3 | "nginx.conf": "user nginx;\nworker_processes auto;\nerror_log /var/log/nginx/error.log;\npid /run/nginx.pid;\n" |
describeでも内容を確認できます。
リスト35:describeを用いてConfigMapの内容を確認
01 | $ kubectl describe configmap sample-configmap |
13 | error_log /var/log/nginx/error.log; |
yamlファイルから作成する
yamlファイルから作成する場合、Secretとは異なりbase64でのエンコードはされずに埋め込まれます。Valueが複数行に渡る場合、Key: |などのようにして次の行から定義します。数値に関しては"で囲うようにして下さい。
リスト36:ConfigMapを作成するconfigmap-sample.yml
04 | name: sample-configmap |
15 | worker_processes auto; |
16 | error_log /var/log/nginx/error.log; |
20 | kubectl apply -f configmap_sample.yml |
kubectlから直接作成する(--from-literal)
kubectlから直接作成するには、--from-literalオプションを使って作成します。
リスト37:kubectlでConfigMapを直接作成する
1 | $ kubectl create configmap web-config \ |
2 | --from-literal=connection.max=100 --from-literal=connection.min=10 |
ConfigMapの利用
ConfigMapをコンテナから利用する場合にも、大きく分けて下記の2つのパターンがあります。
- 環境変数として渡す
- ConfigMapの特定のKeyのみ
- ConfigMapの全てのKey
- Volumeとしてマウントする
- ConfigMapの特定のKeyのみ
- ConfigMapの全てのKey
環境変数として渡す
環境変数として渡す場合、特定のKeyのみを渡すか、ConfigMap全体を渡すかの2通りの方法が用意されています。ConfigMapの特定のKeyを渡す場合には、spec.containers[].envのvalueFrom.configMapKeyRefを使って指定します。
リスト38:ConfigMapを環境変数として渡すconfigmap_single_env_sample.yml
04 | name: sample-configmap-single-env |
07 | - name: configmap-container |
10 | - name: CONNECTION_MAX |
13 | name: sample-configmap |
16 | $ kubectl apply -f configmap_single_env_sample.yml |
envとして1つずつ定義しているため、環境変数名を指定できる特徴があります。
リスト39:ConfigMapの内容を確認
1 | $ kubectl exec -it sample-configmap-single-env env | grep CONNECTION_MAX |
一方でConfigMapの全体を変数として展開することも可能です。Keyごとにそれぞれenvを設定する必要がないため、YAML configが冗長ではなくなりますが、ConfigMapにどのような値が保存されているかをPod Templateからは判断しづらくなるといったデメリットもあります。
リスト40:ConfigMap全体を環境変数として展開するconfigmap_multi_env_sample.yml
04 | name: sample-configmap-multi-env |
07 | - name: configmap-container |
11 | name: sample-configmap |
13 | $ kubectl apply -f configmap_multi_env_sample.yml |
環境変数を確認すると、実際にはthread以外のConfigMapのキーが読まれていないことがわかります。
リスト41:ConfigMapのキーでthreadだけが読まれている
1 | $ kubectl exec -it sample-configmap-multi-env env |
実は環境変数で下記の2パターンを表現することができないため、今回の例だとthreadだけしか読み込まれていないのです。
- .が含まれる場合
- 改行が含まれる場合(Key: |で定義されているもの)
Volumeとしてマウントする
Volumeとしてマウントする場合も、特定のKeyのみを渡すか、ConfigMap全体を渡すかの2通りの方法が用意されています。ConfigMapの特定のKeyを渡す場合には、spec.volumes[]のconfigMap.items[]を使って指定します。
リスト42:Volumeとしてマウントするconfigmap_single_volume_sample.yml
04 | name: sample-configmap-single-volume |
07 | - name: configmap-container |
15 | name: sample-configmap |
18 | path: nginx-sample.conf |
20 | $ kubectl apply -f configmap_single_volume_sample.yml |
マウントするファイルを1つずつ定義しているため、ファイル名を指定できる特徴があります。
リスト43:ConfigMapの内容を確認
1 | $ kubectl exec -it sample-configmap-single-volume cat /config/nginx-sample.conf |
4 | error_log /var/log/nginx/error.log; |
ConfigMapの全体を変数として展開することも可能です。こちらもYAML configが冗長ではなくなりますが、ConfigMapにどのような値が保存されているかを、Pod Templateからは判断しづらくなるといったデメリットもあります。
リスト44:ConfigMap全体をVolumeとしてマウントするconfigmap_multi_volume_sample.yml
04 | name: sample-configmap-multi-volume |
07 | - name: configmap-container |
15 | name: sample-configmap |
17 | $ kubectl apply -f configmap_multi_volume_sample.yml |
リスト45:ConfigMap全体の値を確認
1 | $ kubectl exec -it sample-configmap-multi-volume ls /config |
2 | connection.max connection.min nginx.conf sample.properties thread |
動的なConfigMapの更新
Volumeマウントを利用したConfigMapに限り、一定期間ごと(kubeletのSync Loopのタイミング)にkube-apiserverに変更を確認し、変更がある場合は入れ替えを行います。
デフォルトではSyncLoopの間隔は60秒に設定されています。この頻度を上げる場合には、kubeletのオプションとして--sync-frequencyを設定して下さい。また、環境変数を利用したConfigMapの場合、動的な更新はできません。
例えば、先ほどの例のPodではthreadの値は16で設定しています。
リスト46:更新前のConfigMapの値を確認
1 | $ kubectl exec -it sample-configmap-multi-volume cat /config/thread |
3 | $ kubectl get pod sample-configmap-multi-volume |
4 | NAME READY STATUS RESTARTS AGE |
5 | sample-configmap-multi-volume 1/1 Running 0 17m |
その後、ConfigMapの値を書き換えます。
リスト47:ConfigMapの値を書き換える
1 | $ cat << _EOF_ | kubectl apply -f - |
一定期間が経過すると、Volumeにマウントされているファイルの値が書き換わっていることが確認できます。また、Podが再作成がされることもないため、瞬断も起きません。
リスト48:更新後のConfigMapの値を確認
1 | $ kubectl exec -it sample-configmap-multi-volume cat /config/thread |
3 | $ kubectl get pod sample-configmap-multi-volume |
4 | NAME READY STATUS RESTARTS AGE |
5 | sample-configmap-multi-volume 1/1 Running 0 17m |
また、今回の例ではConfigMapの中身をthreadだけにしてapplyしているため、その他のファイルが削除されている点にも注意して下さい。
リスト49:ConfigMapの中身はthreadのみ
1 | $ kubectl exec -it sample-configmap-multi-volume ls /config |
次回は、PersistentVolumeClaimリソースを解説します。