Kubernetesの構築はYAMLベースです。
JavaやXMLなどさまざまな言語を利用する場合に必要なのは、やはり「変数」。Kubernetesでは、環境変数やコマンドライン引数などを使ってYAML内において「変数」を利用することができます。
Config & Storageリソースは、Podなどに対して、外部に「状態」や「変数」を持たせる口です。ConfigMapはKey-Valueで構成され、アプリケーションの設定値を管理するリソースです。Secretはパスワードなどの機密情報を管理するリソースです。
次節より、それぞれ説明します。なお、リソースを定義するYAMLの記述方法の詳細はAPIドキュメントを参照ください。
環境変数の利用
Podに環境変数SAMPLEを設定します。コンテナ内から覗くと、SAMPLEに値が設定されていることがわかります。
$vi env.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample-env
labels:
app: hello-pod
spec:
containers:
- name: hello
image: hello-node:v1
env:
- name: SAMPLE
value: "sample"
$kubectl apply -f env.yaml
pod/sample-env created
$kubectl exec -it sample-env env | grep SAMPLE
SAMPLE=sample
コマンドライン引数の利用
Podにコマンドライン引数を指定します。printenvの引数に[HOSTNAME]と[KUBERNETES_PORT]を指定しています。kubernetes logsにてコマンドの実行結果を確認することができます。
$vi arg.yaml
apiVersion: v1
kind: Pod
metadata:
name: command-demo
labels:
purpose: demonstrate-command
spec:
containers:
- name: command-demo-container
image: debian
command: ["printenv"]
args: ["HOSTNAME", "KUBERNETES_PORT"]
restartPolicy: OnFailure
$kubectl logs command-demo
command-demo
tcp://10.96.0.1:443
ConfigMap
ConfigMapリソースを作ってみましょう。[from-literal]オプションを使って[special.how]変数を定義し、Podにおける[configMapKeyRef]において変数を参照しています。
$kubectl create configmap special-config --from-literal=special.how=very
$cat dapi-test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
# Define the environment variable
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
restartPolicy: Never
$kubectl apply -f dapi-test-pod.yaml
また、[from-file]オプションを使って、プロパティファイルから読み込むことも可能です。
$cat sample.properties
color.safe=bule
color.danger=red
$kubectl create configmap sample-configmap --from-file=./
configmap/sample-configmap created
$kubectl describe configmaps sample-configmap
Name: sample-configmap
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
sample.properties:
----
color.safe=bule
color.danger=red
Events: <none>
Secret
Secretリソースを作ってみましょう。BASE64エンコーディングした文字列を使って[username][password]を指定します。
$echo -n 'myapp'|base64
bXlhcHA=
$echo -n 'abcde'|base64
YWJjZGU=
$cat secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: sample-secret
data:
username: bXlhcHA=
password: YWJjZGU=
$kubectl apply -f secret.yaml
secret/sample-secret created
作成したSecretリソースを利用するPodを作成します。作成したPodにログインして、内容を確認できます。
$cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
spec:
containers:
- name: sample-container
image: nginx
volumeMounts:
- name: secret-volume
mountPath: /etc/secret-volume
volumes:
- name: secret-volume
secret:
secretName: sample-secret
$kubectl apply -f pod.yaml
pod/sample-pod created
$kubectl exec -it sample-pod -- /bin/bash
root@secret-test-pod:/# cd /etc/secret-volume
root@secret-test-pod:/etc/secret-volume# ls
password username
root@secret-test-pod:/etc/secret-volume# cat password
abcde
root@secret-test-pod:/etc/secret-volume# cat username
myapp
PersistentVolumeClaim
Podは再起動や障害によりデータが揮発するため、永続化するための仕組みが必要です。永続化領域としてVolumeやPersistentVolumeが用意されています。
PersistentVolumeClaimは、Podに対してPersistentVolumeを割り当てるための仕組みです。その際、割り当てる容量を指定したり、StorageClassを使ってストレージの性能を定義したりします。
Minikubeでデフォルトで用意されているStorageClassを用いて、PersistentVolumeClaimを定義してみましょう。PersistentVolumeClaimに応じたPersistentVolumeが作成されています。
$kubectl get sc
NAME PROVISIONER AGE
standard (default) k8s.io/minikube-hostpath 7h31m
$cat pvc01.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc01
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: standard
$kubectl apply -f pvc01.yaml
persistentvolumeclaim/pvc01 created
$kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc01 Bound pvc-5fcbc9af-95c3-11e9-a297-080027b46c25 1Gi RWO standard 2m8s
$kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-5fcbc9af-95c3-11e9-a297-080027b46c25 1Gi RWO Delete Bound default/pvc01 standard 2m12s
* * *
今回は5つのリソースタイプの3つ目であるConfig & Storageを紹介しました。ConfigMapやSecretを用いてPodなどで利用する「変数」を定義したり、Volumeを用いてPodにおいて利用する情報を永続化したりすることができます。簡易に試したい場合や、本番環境で運用したい場合など利用シーンに応じて使い分けると良いでしょう。
連載第3回で紹介しましたが、マネージドサービスや構築ツールによってさまざまな特徴があります。例えば、マネージドサービス以外の場合、LoadBalancerなど利用環境が限定されるケースもあります。
使い始めてから制約を知るということがないよう、利用条件を確認しておくと良いでしょう。
著者紹介
![]() |
正野 勇嗣 (SHONO Yuji ) - NTTデータ 課長
2011年まで開発自動化技術のR&Dに従事。その後、開発プロジェクト支援やトラブルシューティング等に主戦場を移す。「ソースコード自動生成」に加えて、JenkinsやMaven等の「ビルド自動化」、JsTestDriverやSelenium等の「テスト自動化」を扱うようになり、多様化する開発自動化技術動向に興味。
最近は第四の自動化であるInfrastructure as Code等の「基盤自動化」の魅力に惹かれている。開発自動化技術に関する雑誌・記事執筆も行う。3児のパパ。