Kubernetesのリソースタイプを体系的に学ぶ - Config & Storage

【連載】

Kubernetes入門

【第7回】Kubernetesのリソースタイプを体系的に学ぶ - Config & Storage

[2019/07/11 07:00]正野 勇嗣 ブックマーク ブックマーク

開発ソフトウェア

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を使ってストレージの性能を定義したりします。

PVC、PV、SCとPodの関係性

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等の「基盤自動化」の魅力に惹かれている。開発自動化技術に関する雑誌・記事執筆も行う。2児のパパ。

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

一覧はこちら

連載目次

もっと知りたい!こちらもオススメ

【連載】AWSで作るクラウドネイティブアプリケーションの基本

【連載】AWSで作るクラウドネイティブアプリケーションの基本

前回は、「Spring Cloud Function」でサーバレスアプリケーションを実装しました。今回は、作成したアプリケーションを「AWS Lambda」へ登録してみましょう。

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします

会員登録(無料)

注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
[解説動画] 個人の業務効率化術 - 短時間集中はこうして作る
知りたい! カナコさん 皆で話そうAIのコト
教えてカナコさん! これならわかるAI入門
対話システムをつくろう! Python超入門
Kubernetes入門
AWSで作るクラウドネイティブアプリケーションの基本
PowerShell Core入門
徹底研究! ハイブリッドクラウド
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

ページの先頭に戻る