この連載が書籍になりました!『Kubernetes完全ガイド

KubernetesのConfig&Storageリソース(その1)

2018年5月31日(木)
青山 真也
今回と次回の2回に渡って、5種類に大別されるKubernetesのリソースのうち、Config&Storageリソースを解説する。

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
2{
3  "nginx.conf": "user nginx;\nworker_processes auto;\nerror_log /var/log/nginx/error.log;\npid /run/nginx.pid;\n"
4}

describeでも内容を確認できます。

リスト35:describeを用いてConfigMapの内容を確認

01$ kubectl describe configmap sample-configmap
02Name:           sample-configmap
03Namespace:      default
04Labels:         <none>
05Annotations:    <none>
06 
07Data
08====
09nginx.conf:
10----
11user nginx;
12worker_processes auto;
13error_log /var/log/nginx/error.log;
14pid /run/nginx.pid;
15...
16 
17Events: <none>

yamlファイルから作成する

yamlファイルから作成する場合、Secretとは異なりbase64でのエンコードはされずに埋め込まれます。Valueが複数行に渡る場合、Key: |などのようにして次の行から定義します。数値に関しては"で囲うようにして下さい。

リスト36:ConfigMapを作成するconfigmap-sample.yml

01apiVersion: v1
02kind: ConfigMap
03metadata:
04  name: sample-configmap
05data:
06  thread: "16"
07  connection.max: "100"
08  connection.min: "10"
09  sample.properties: |
10    property.1=value-1
11    property.2=value-2
12    property.3=value-3
13  nginx.conf: |
14    user nginx;
15    worker_processes auto;
16    error_log /var/log/nginx/error.log;
17    pid /run/nginx.pid;
18    
19 
20kubectl 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[].envvalueFrom.configMapKeyRefを使って指定します。

リスト38:ConfigMapを環境変数として渡すconfigmap_single_env_sample.yml

01apiVersion: v1
02kind: Pod
03metadata:
04  name: sample-configmap-single-env
05spec:
06  containers:
07    - name: configmap-container
08      image: nginx:1.12
09      env:
10        - name: CONNECTION_MAX
11          valueFrom:
12            configMapKeyRef:
13              name: sample-configmap
14              key: connection.max
15 
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
2CONNECTION_MAX=100

一方でConfigMapの全体を変数として展開することも可能です。Keyごとにそれぞれenvを設定する必要がないため、YAML configが冗長ではなくなりますが、ConfigMapにどのような値が保存されているかをPod Templateからは判断しづらくなるといったデメリットもあります。

リスト40:ConfigMap全体を環境変数として展開するconfigmap_multi_env_sample.yml

01apiVersion: v1
02kind: Pod
03metadata:
04  name: sample-configmap-multi-env
05spec:
06  containers:
07    - name: configmap-container
08      image: nginx:1.12
09      envFrom:
10      - configMapRef:
11          name: sample-configmap
12 
13$ kubectl apply -f configmap_multi_env_sample.yml

環境変数を確認すると、実際にはthread以外のConfigMapのキーが読まれていないことがわかります。

リスト41:ConfigMapのキーでthreadだけが読まれている

1$ kubectl exec -it sample-configmap-multi-env env
2
3thread=16
4

実は環境変数で下記の2パターンを表現することができないため、今回の例だとthreadだけしか読み込まれていないのです。

  • .が含まれる場合
  • 改行が含まれる場合(Key: |で定義されているもの)

Volumeとしてマウントする

Volumeとしてマウントする場合も、特定のKeyのみを渡すか、ConfigMap全体を渡すかの2通りの方法が用意されています。ConfigMapの特定のKeyを渡す場合には、spec.volumes[]configMap.items[]を使って指定します。

リスト42:Volumeとしてマウントするconfigmap_single_volume_sample.yml

01apiVersion: v1
02kind: Pod
03metadata:
04  name: sample-configmap-single-volume
05spec:
06  containers:
07    - name: configmap-container
08      image: nginx:1.12
09      volumeMounts:
10      - name: config-volume
11        mountPath: /config
12  volumes:
13    - name: config-volume
14      configMap:
15        name: sample-configmap
16        items:
17        - key: nginx.conf
18          path: nginx-sample.conf
19 
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
2user nginx;
3worker_processes auto;
4error_log /var/log/nginx/error.log;
5pid /run/nginx.pid;
6...

ConfigMapの全体を変数として展開することも可能です。こちらもYAML configが冗長ではなくなりますが、ConfigMapにどのような値が保存されているかを、Pod Templateからは判断しづらくなるといったデメリットもあります。

リスト44:ConfigMap全体をVolumeとしてマウントするconfigmap_multi_volume_sample.yml

01apiVersion: v1
02kind: Pod
03metadata:
04  name: sample-configmap-multi-volume
05spec:
06  containers:
07    - name: configmap-container
08      image: nginx:1.12
09      volumeMounts:
10      - name: config-volume
11        mountPath: /config
12  volumes:
13    - name: config-volume
14      configMap:
15        name: sample-configmap
16 
17$ kubectl apply -f configmap_multi_volume_sample.yml

リスト45:ConfigMap全体の値を確認

1$ kubectl exec -it sample-configmap-multi-volume ls /config
2connection.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
216
3$ kubectl get pod sample-configmap-multi-volume
4NAME                            READY     STATUS    RESTARTS   AGE
5sample-configmap-multi-volume   1/1       Running   0          17m

その後、ConfigMapの値を書き換えます。

リスト47:ConfigMapの値を書き換える

1$ cat << _EOF_ | kubectl apply -f -
2apiVersion: v1
3kind: ConfigMap
4metadata:
5  name: sample-configmap
6data:
7  thread: "32"
8_EOF_

一定期間が経過すると、Volumeにマウントされているファイルの値が書き換わっていることが確認できます。また、Podが再作成がされることもないため、瞬断も起きません。

リスト48:更新後のConfigMapの値を確認

1$ kubectl exec -it sample-configmap-multi-volume cat /config/thread
232
3$ kubectl get pod sample-configmap-multi-volume
4NAME                            READY     STATUS    RESTARTS   AGE
5sample-configmap-multi-volume   1/1       Running   0          17m

また、今回の例ではConfigMapの中身をthreadだけにしてapplyしているため、その他のファイルが削除されている点にも注意して下さい。

リスト49:ConfigMapの中身はthreadのみ

1$ kubectl exec -it sample-configmap-multi-volume ls /config
2thread

次回は、PersistentVolumeClaimリソースを解説します。

株式会社サイバーエージェント アドテク本部 Strategic Infrastructure Agency

2016年入社。OpenStackを使ったプライベートクラウドやGKE互換なコンテナプラットフォームをゼロから構築し、国内カンファレンスでのKeynoteに登壇。
その後、世界で2番目にCertified Kubernetes Application Developer、138番目にCertified Kubernetes Administratorの認定資格を取得。
現在はKubernetesやOpenStackなどOSSへのコントリビュート活動をはじめ、CNCF公式のCloud Native Meetup TokyoのOrganizerやJapan Container Daysの運営などコミュニティ活動にも従事している。

連載バックナンバー

仮想化/コンテナ技術解説
第9回

KubernetesのConfig&Storageリソース(その2)

2018/6/6
連載9回目となる今回は、Config&Storageリソースのうち、PersistentVolumeClaimについて解説する。
仮想化/コンテナ技術解説
第8回

KubernetesのConfig&Storageリソース(その1)

2018/5/31
今回と次回の2回に渡って、5種類に大別されるKubernetesのリソースのうち、Config&Storageリソースを解説する。
仮想化/コンテナ技術解説
第7回

KubernetesのDiscovery&LBリソース(その2)

2018/5/16
前回に引き続き、Discovery&LBリソースのServiceとIngressを紹介する。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています