kubernetes – ConfigMap

前回に続いて、今回はConfigMapについてご紹介します。

Config&Storageリソースの概要

Config & Storageリソースは、設定や機密データをコンテナに埋め込んだり、永続ボリュームを提供するリソースです。

以下のものがあります。

• Secret：機密情報保存用
• ConfigMap：設定値や共通設定などの保存用
• PersistentVolumeClaim：Podが永続化ディスク(ディスク)を利用するためのリソース

ConfigMap

manifestのリソース指定：
kind: ConfigMap

ConfigMapは、一般的な設定情報などをkey-value形式でデータを保持するためのリソースです。
内容は暗号化されていないため、機密情報には向きません。(保持できないわけではないです)

作成方法はSecretと同じで、以下の4つです。

• ファイルから値を参照して作成する：kubectl --from-file
• envfileから値を参照して作成する：kubectl --from-env-file
• 直接値を指定して、作成する：kubectl --from-literal
• manifestから作成する：kubectl apply -f

内容はSecretで説明したものと同じのため、ここでは割愛します。

ConfigMapも一つにつき、格納データの上限が1MBとなります。

ConfigMapのmanifest例

Secretと違って、平文でも問題なさそうなリソースなので、できるだけコード化するように、こちらもmanifestで作成するケースが多いかとおみます。

manifest例：
※一回で二つのConfigMapを作成する

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO

※公式ドキュメント例使用

ConfigMapの使用

ConfigMapの使用もSecretとほぼ同じで、指定のリソース引用が違うだけです。

• 環境変数として渡す
  • Secretの特定のKeyのみ：.env[].valueFrom.configMapKeyRef
  • SecretのすべてのKey：.env[].envFrom[].configMapKeyRef
• Volumeとしてマウントする
  • Secretの特定のKeyのみ：.volumes[].configMap.items[]
  • SecretのすべてのKey：.volumes[].configMap.name

例はSecretの該当部分を入れ変われば、そのまま使用可能です。

SecretとConfigMapの違い

裏の仕組みで、SecretとConfigMapの実装は違います。

Secretのデータは、Kubernetes Master(Master Node)が利用している分散KVS(key-value Store)のetcdに保存されています。
Secretを利用するPodがある場合のみ、etcdからKubernetes Node(Node)にデータを送信します。
しかも、データはNodeのtmpfs領域(一時領域-メモリー上)に保持されています。

※Kubernetes MasterからKubernetes Nodeへの送信はoverSSL/TLS(暗号化)で転送します。

PersistentVolumeClaim

PersistentVolumeClaimを説明する前に、VolumeとPersistentVolumeを前提としてしておかないといけませんので、今後順番に説明していくと思います。

最後に

今回はConfigMapを紹介しながら、前回ご紹介したSecretとの違いも纏めておきました。
k8sで共通の設定情報をこれらのリソースを使って保持します。
このリソースもk8sにおいて大事なリソースと言えます。

ここまで読んでいただいて、お疲れ様でした。