PVCが実際にバインドされるのを見る

TT Labで続きを見る

このラボは本物のプロビジョナーがあるクラスター上で動きます

VM内のk3sでは、local-path動的プロビジョナーが実際に動いています。PVCを作成するとPVが自動で作られ、ファイルを書き込むと、Podを削除しても残ります。

CKAコースのほかのストレージのラボが動く偽のクラスターには、プロビジョナーがなく、PVCが永遠にPendingです。そのため、YAMLを書く練習までが、すべてでした。

最初の起動に2分ほどかかります。

目標

StorageClass・PVC・PVの3層がどのように噛み合うかを、状態の変化で確認し、WaitForFirstConsumerがなぜあるのかを、自分で見ます。

なぜ重要なのか

ストレージでは、「YAMLを正しく書いたか」よりも、「今なぜこの状態なのか」を読むことのほうが、はるかに多くあります。その中で最もよく誤解されるのが、Pendingです。

WaitForFirstConsumerのStorageClassでPVCを作成すると、わざとPendingのままになります。欠陥ではなく、設計です。ボリュームをどのノードに作るかは、そのボリュームを使うPodがどのノードに配置されるかによって決まりますが、Podがなければわからないからです。

先にボリュームを作ってしまうと、スケジューラーはPodをそのノードにしか配置できなくなり、空きがないときに、Podが永遠に起動しません。順序を逆にして、この問題をなくしたのが、WaitForFirstConsumerです。

これを知らないと、「PVCがPendingなのに、プロビジョナーが故障したのか」と、しばらく調べ回すことになります。

ステップ

すべて、cstネームスペースに作成します。

local-pathStorageClassのプロビジョナーとバインドモードを確認して記録してください(保存先: /root/cst/sc.txt)。
dataという名前のPVC(1Gi、ReadWriteOnce)を作成し、Podを付ける前の状態を記録してください(保存先: /root/cst/pending.txt)。なぜその状態なのかも書きます。
writerというPodを作成して、そのPVCをマウントし、PVCがBoundに変わることと、自動で作られたPV名を記録してください(保存先: /root/cst/bound.txt)。
ボリュームにファイルを書き込み、Podを削除して作り直して、データが残るかを確認して記録してください(保存先: /root/cst/persist.txt)。
ReadWriteOnceが何を制限するかを確認して記録してください(保存先: /root/cst/accessmode.txt)。
tempPVCをもう1つ作成して削除し、そのPVがどうなるかを記録してください(保存先: /root/cst/reclaim.txt)。
webStatefulSet(レプリカ2)をvolumeClaimTemplates付きで作成し、PVCがいくつ作られるかを記録してください(保存先: /root/cst/sts.txt)。
次の3行と、3つの層の関係を書いてください(保存先: /root/cst/report.md)。binding_mode=、reclaim_policy=、sts_pvcs=の3行です。

参考

PVCの状態は、kubectl -n cst get pvcで見ます。Pendingの理由は、describeのEventsにあります。
自動で作られたPV名は、kubectl -n cst get pvc data -o jsonpath='{.spec.volumeName}'です。
ReadWriteOnceはノード単位です。同じノードの複数のPodは一緒に使えますが、別のノードからはつなげません。「Pod1つだけ」ではありません。
StatefulSetのPVC名は、<볼륨이름>-<스테이트풀셋이름>-<번호>です(プレースホルダーは順に、ボリューム名、StatefulSet名、番号です)。
よくあるミス1: 2で、先にPodを付けてから状態を見ることです。すぐにBoundになるので、学ぼうとしていたことが消えます。
よくあるミス2: StatefulSetを削除すれば、PVCも削除されると思い込むことです。PVCは残ります。データを守るための設計で、片付けは手で行う必要があります。

誰がボリュームを作るのか

local-pathStorageClassのプロビジョナーとバインドモードを確認して記録してください(保存先: /root/cst/sc.txt)。

kubectl get sc local-path -o yamlに、プロビジョナーとバインドモードがあります。

Pendingが正常な場合

dataという名前のPVC(1Gi、ReadWriteOnce)を作成し、Podを付ける前の状態を記録してください(保存先: /root/cst/pending.txt)。なぜその状態なのかも書きます。

PVCだけを作成して、Podはまだ作成しないでください。その状態が、このステップの観察対象です。

Podを付けるとボリュームができる

writerというPodを作成して、そのPVCをマウントし、PVCがBoundに変わることと、自動で作られたPV名を記録してください(保存先: /root/cst/bound.txt)。

PVCをマウントするPodを作成すると、プロビジョナーがPVを新しく作ります。その名前を確認してください。

Podを削除してもデータは残る

ボリュームにファイルを書き込み、Podを削除して作り直して、データが残るかを確認して記録してください(保存先: /root/cst/persist.txt)。

ファイルを書き込み、Podを削除し、同じPVCでPodを作り直して、読んでみてください。

ReadWriteOnceはノード単位

ReadWriteOnceが何を制限するかを確認して記録してください(保存先: /root/cst/accessmode.txt)。

「Pod1つだけ」ではありません。同じノードの複数のPodは、一緒に使えます。

PVCを削除するとPVはどうなるか

tempPVCをもう1つ作成して削除し、そのPVがどうなるかを記録してください(保存先: /root/cst/reclaim.txt)。

一時的なPVCを1つ作成して、Podを付けてバインドさせたあと、削除して、PVを確認してください。

Podごとにボリュームを別々に与える

webStatefulSet(レプリカ2)をvolumeClaimTemplates付きで作成し、PVCがいくつ作られるかを記録してください(保存先: /root/cst/sts.txt)。

volumeClaimTemplatesは、Podごとに、PVCを1つずつ作成します。名前のルールを確認してください。

何を学んだか

次の3行と、3つの層の関係を書いてください(保存先: /root/cst/report.md)。binding_mode=、reclaim_policy=、sts_pvcs=の3行です。

binding_mode=、reclaim_policy=、sts_pvcs=の3行と一緒に、3つの層の関係を書いてください。