Skip to content

Latest commit

 

History

History
132 lines (96 loc) · 7.06 KB

StatefulSet-volumeClaimTemplate.md

File metadata and controls

132 lines (96 loc) · 7.06 KB

前: StatefulSet


StatefulSet volumeClaimTemplate

PVC指定の場合

volumeClaimTemplateはPodごとにPVCおよびPVを作成する、StatefulSetで使える機能です。 この機能を理解するため、まずはDeploymentでのボリュームプロビジョニングの特徴をおさらいします。

ℹ️
この演習はAWS EKSでの実施を前提としています。 AWS以外のクラウドを使用する際は、内容を適宜読み替えてください。

ℹ️
本演習を実施するにあたり、ワーカーノードを2台以上にしてください。

  1. 以下を満たすマニフェストを作成しデプロイしてください。

    • 要件
      • Deployment
        • 名前はnginx-dp
        • labelはすべてapp: nginx-dp
        • replicasは 3
        • Pod
          • 名前はnginx
          • イメージはnginx:1.12
          • volumeプラグインでPVC:nginx-dp-pvcを指定
          • 上記で定義したボリュームをコンテナの/usr/share/nginx/htmlにマウント
          • lifecycleのpostStartで["/bin/sh","-c","echo $HOSTNAME >> /usr/share/nginx/html/index.html"]を実行
      • PVC
        • 名前はnginx-dp-pvc
        • storageClassNameは指定しない(デフォルトのStorageClassを使用する)
        • accessModesはReadWriteOnce
        • ストレージ容量は1Gi
  2. PVCおよびPVリソースのオブジェクト一覧を表示し、nginx-dp-pvcを含むものがそれぞれ1つ作成されていることを確認してください。

  3. Podリソースのオブジェクト一覧を表示し、3つのPodの名前および稼働するワーカーノードを確認してください。

  4. いずれか1つのPodにログインし、次のコマンドを発行してください。

    echo $HOSTNAME > /usr/share/nginx/html/index.html
    cat /usr/share/nginx/html/index.html
  5. 先ほどとは別のPodにログインし、次のコマンドを発行してください。表示されるホスト名が最初にログインしたPod名が表示されることを確認してください。

    cat /usr/share/nginx/html/index.html
  6. Deployment:nginx-dp、PVC:nginx-dp-pvcを削除してください。

ここまでがDeploymentでのボリュームプロビジョニングのおさらいです。 注目するポイントとしては展開したPodすべてで同じボリュームを共有する点です。 そのため、PVCおよびPVは1つしか作られません。ボリュームの中身もすべてのPodで共有します。 ですので、例えばWEBサーバなどのワークロードでセッション情報をPod間で共有したいなどと言った場合にはこの構成が有効です。 一方で、DBなどのワークロードで各Podが専用のボリュームを確保したい場合には適しません。 また、今回はPVCでstorageClassNameを指定しなかったためデフォルトのStorageClassであるEBSのtype:gp2(EKSの場合)で実際のボリュームは作られています。 EBSは単一のEC2インスタンスにしかボリュームをアタッチできません。 そのため、replica数が増えても単一のワーカーノード(EC2)にしかPodがスケジュールできません。複数のワーカーノードに分散させるには、EBSではなくEFSなどRead/Write Anyできるボリュームが使えるStorageClassを使用する必要があります。

volumeClaimTemplateの場合

つぎに、StatefulSetでvolumeClaimTemplateを使用した場合の挙動を確認します。

  1. 以下を満たすマニフェストを作成しデプロイしてください。volumeClaimTemplateについては公式ドキュメントを参考にしてください。

    • 要件
      • StatefulSet
        • 名前はnginx-vct-sts
        • labelはすべてapp: nginx
        • replicasは 3
        • serviceNameはnginx-vct-svc
        • Pod
          • 名前はnginx-vct
          • イメージはnginx:1.12
          • volumeプラグインでPVC:nginx-vct-pvcを指定
          • 上記で定義したボリュームをコンテナの/usr/share/nginx/htmlにマウント
          • lifecycleのpostStartで["/bin/sh","-c","echo $HOSTNAME >> /usr/share/nginx/html/index.html"]を実行
        • volumeClaimTemplates
          • 名前はindex
          • storageClassNameは指定しない(デフォルトのStorageClassを使用する)
          • accessModesはReadWriteOnce
          • ストレージ容量は1Gi
  2. PVCおよびPVリソースのオブジェクト一覧を表示し、それぞれ3つ作成されていることを確認してください。

  3. Podリソースのオブジェクト一覧を表示し、3つのPodの名前および稼働するワーカーノードを確認してください

  4. 1つのPodにログインし、次のコマンドを発行してください。

    echo $HOSTNAME > /usr/share/nginx/html/index.html
    cat /usr/share/nginx/html/index.html
  5. 先ほどとは別のPodにログインし、次のコマンドを発行してください。index.htmlの内容が異なることを確認してください。

    cat /usr/share/nginx/html/index.html
  6. StatefulSet:nginx-vct-stsを削除してください。

  7. PVCおよびPVリソースのオブジェクト一覧を表示し、削除されていないことを確認してください。

  8. PVCおよびPVリソースを削除してください。

以上がvolumeClaimTemplateを使用したボリュームプロビジョニングです。 Deploymentの時とは違い、各PodそれぞれにPVCおよびPVが作成されました。 また、StorageClassはデフォルトのEBSですが、Podのスケジュール先も分散されました。 この様にPodごとに専用のボリュームを確保したい時にvolumeClaimTemplateは有効です。 また、Podがセルフ・ヒーリングで再作成された場合はそのPodに対応したボリュームが引き続き使用されます。 なお、volumeClaimTemplateで作成されたPVCおよびPVはStatefulSetを削除しても消えません。(データを残すためにあえてこのような仕様になっていると思われます。) この特性を利用してreplica1でもあえてStatefulSetを使用することもありますが、ボリュームが不要になった時は手動で消すのを忘れないようにしましょう。

なお、StatefulSetでもDeploymentと同じようにPVCを指定すれば1つのボリュームを複数Podで共有することもできます。

以上で本演習は終了です。

具体的な操作およびその結果に関する回答例はこちらにあります。 具体的な操作方法がわからなかった場合や、想定した結果にならなかった場合などに参照してください。


次: ConfigMap(env)