この連載が書籍になりました!『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の作成

$ kubectl create configmap sample-configmap --from-file=./nginx.conf

作成したConfigMapを確認するには、kubectl getでjsonかyamlフォーマットで出力し、dataの部分を確認します。

リスト34:ConfigMapの内容を確認

$ kubectl get configmap sample-configmap -o json | jq .data
{
  "nginx.conf": "user nginx;\nworker_processes auto;\nerror_log /var/log/nginx/error.log;\npid /run/nginx.pid;\n"
}

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

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

$ kubectl describe configmap sample-configmap
Name:           sample-configmap
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data
====
nginx.conf:
----
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
...

Events: <none>

yamlファイルから作成する

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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: sample-configmap
data:
  thread: "16"
  connection.max: "100"
  connection.min: "10"
  sample.properties: |
    property.1=value-1
    property.2=value-2
    property.3=value-3
  nginx.conf: |
    user nginx;
    worker_processes auto;
    error_log /var/log/nginx/error.log;
    pid /run/nginx.pid;
    …

kubectl apply -f configmap_sample.yml

kubectlから直接作成する(--from-literal)

kubectlから直接作成するには、--from-literalオプションを使って作成します。

リスト37:kubectlでConfigMapを直接作成する

$ kubectl create configmap web-config \
--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

apiVersion: v1
kind: Pod
metadata:
  name: sample-configmap-single-env
spec:
  containers:
    - name: configmap-container
      image: nginx:1.12
      env:
        - name: CONNECTION_MAX
          valueFrom:
            configMapKeyRef:
              name: sample-configmap
              key: connection.max

$ kubectl apply -f configmap_single_env_sample.yml

envとして1つずつ定義しているため、環境変数名を指定できる特徴があります。

リスト39:ConfigMapの内容を確認

$ kubectl exec -it sample-configmap-single-env env | grep CONNECTION_MAX
CONNECTION_MAX=100

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

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

apiVersion: v1
kind: Pod
metadata:
  name: sample-configmap-multi-env
spec:
  containers:
    - name: configmap-container
      image: nginx:1.12
      envFrom:
      - configMapRef:
          name: sample-configmap

$ kubectl apply -f configmap_multi_env_sample.yml

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

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

$ kubectl exec -it sample-configmap-multi-env env
…
thread=16
…

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

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

Volumeとしてマウントする

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

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

apiVersion: v1
kind: Pod
metadata:
  name: sample-configmap-single-volume
spec:
  containers:
    - name: configmap-container
      image: nginx:1.12
      volumeMounts:
      - name: config-volume
        mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: sample-configmap
        items:
        - key: nginx.conf
          path: nginx-sample.conf

$ kubectl apply -f configmap_single_volume_sample.yml

マウントするファイルを1つずつ定義しているため、ファイル名を指定できる特徴があります。

リスト43:ConfigMapの内容を確認

$ kubectl exec -it sample-configmap-single-volume cat /config/nginx-sample.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
...

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

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

apiVersion: v1
kind: Pod
metadata:
  name: sample-configmap-multi-volume
spec:
  containers:
    - name: configmap-container
      image: nginx:1.12
      volumeMounts:
      - name: config-volume
        mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: sample-configmap

$ kubectl apply -f configmap_multi_volume_sample.yml

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

$ kubectl exec -it sample-configmap-multi-volume ls /config
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の値を確認

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

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

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

$ cat << _EOF_ | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: sample-configmap
data:
  thread: "32"
_EOF_

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

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

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

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

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

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

次回は、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メルマガ会員のサービス内容を見る

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