KubernetesのConfig＆Storageリソース（その1）

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

仮想化／コンテナ

技術解説

連載 [第8回] :

今こそ始めよう！　Kubernetes入門

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[].envのvalueFrom.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リソースを解説します。


青山真也　著価格：3,800円＋税発売日：2018年9月21日発売 ISBN：978-4-295-00480-6 発行：インプレス	Kubernetes完全ガイドこの連載が書籍になりました！本書は、インプレスの“オープンソース技術の実践活用メディア”Think ITの連載記事『今こそ始めよう！Kubernetes入門』の内容を元に、大幅加筆して書籍化したものです。 Kubernetesを触ったことがない方でも、そのコンセプトを理解し、実際にアプリケーションをコンテナ化して実行できるようになることを目標にしています。

青山真也　著
価格：3,800円＋税
発売日：2018年9月21日発売
ISBN：978-4-295-00480-6
発行：インプレス

Kubernetes完全ガイド

この連載が書籍になりました！

本書は、インプレスの“オープンソース技術の実践活用メディア”Think ITの連載記事『今こそ始めよう！Kubernetes入門』の内容を元に、大幅加筆して書籍化したものです。 Kubernetesを触ったことがない方でも、そのコンセプトを理解し、実際にアプリケーションをコンテナ化して実行できるようになることを目標にしています。

著者

青山真也

この著者の記事一覧この著者の
記事一覧

株式会社サイバーエージェントアドテク本部 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の運営などコミュニティ活動にも従事している。