Watch a PVC Actually Bind

This lab runs on a cluster with a real provisioner

The k3s in the VM actually runs the local-path dynamic provisioner. When you create a PVC, a PV is created automatically, and if you write a file, it remains even if you delete the Pod.

On the fake cluster where the other storage labs in the CKA course run, there is no provisioner, so a PVC stays Pending forever. So writing YAML was as far as the practice went.

It takes about 2 minutes to start up the first time.

Goal

You confirm through state changes how the three layers, StorageClass, PVC, and PV, mesh together, and you see for yourself why WaitForFirstConsumer exists.

Why it matters

With storage, much more of the work is reading "why is it in this state right now" than "did I write the YAML correctly." The most commonly misunderstood of these is Pending.

If you create a PVC on a StorageClass with WaitForFirstConsumer, it stays Pending on purpose. It is not a defect but a design. Which node the volume is created on depends on which node the Pod that will use it is placed on, and without a Pod you cannot know.

If the volume were created first, the scheduler could place the Pod only on that node, and when there is no room there, the Pod would never come up. WaitForFirstConsumer removes this problem by reversing the order.

If you do not know this, you will spend a long time digging into "the PVC is Pending, so is the provisioner broken?"

Steps

Create everything in the cst namespace.

1. Check the provisioner and binding mode of the local-path StorageClass and put them in /root/cst/sc.txt.
2. Create a PVC named data (1Gi, ReadWriteOnce) and put its state before attaching a Pod in /root/cst/pending.txt. Also write why it is in that state.
3. Create a writer Pod that mounts that PVC, and record the PVC changing to Bound and the name of the automatically created PV in /root/cst/bound.txt.
4. Write a file to the volume, then delete the Pod and recreate it to check whether the data remains, and put the result in /root/cst/persist.txt.
5. Check what ReadWriteOnce restricts and put it in /root/cst/accessmode.txt.
6. Create one more temp PVC and delete it, and put what happens to its PV in /root/cst/reclaim.txt.
7. Create a web StatefulSet (2 replicas) with volumeClaimTemplates, and put how many PVCs are created in /root/cst/sts.txt.
8. In /root/cst/report.md, write three lines, binding_mode=, reclaim_policy=, and sts_pvcs=, and the relationship among the three layers.

Reference

• You view PVC status with kubectl -n cst get pvc. The reason for Pending is in the Events of describe.
• The automatically created PV name is kubectl -n cst get pvc data -o jsonpath='{.spec.volumeName}'.
• ReadWriteOnce is per node. Several Pods on the same node can use it together, but it cannot be attached from a different node. It does not mean "only one Pod."
• A StatefulSet's PVC name is <볼륨이름>-<스테이트풀셋이름>-<번호> (volume name, StatefulSet name, ordinal).
• Common mistake 1: attaching the Pod first in step 2 and then looking at the state. Then it is Bound immediately, and what you meant to learn disappears.
• Common mistake 2: thinking that deleting the StatefulSet also deletes the PVCs. The PVCs remain. It is a design to protect data, and cleanup has to be done by hand.

Who creates the volume

Check the provisioner and binding mode of the local-path StorageClass and put them in /root/cst/sc.txt.

The provisioner and binding mode are in kubectl get sc local-path -o yaml.

When Pending is normal

Create a PVC named data (1Gi, ReadWriteOnce) and put its state before attaching a Pod in /root/cst/pending.txt. Also write why it is in that state.

Create only the PVC and do not create the Pod yet. That state is what this step observes.

Attach a Pod and the volume appears

Create a writer Pod that mounts that PVC, and record the PVC changing to Bound and the name of the automatically created PV in /root/cst/bound.txt.

When you create a Pod that mounts the PVC, the provisioner creates a new PV. Check its name.

The data remains even if you delete the Pod

Write a file to the volume, then delete the Pod and recreate it to check whether the data remains, and put the result in /root/cst/persist.txt.

Write a file, delete the Pod, recreate the Pod with the same PVC, and read the file.

ReadWriteOnce is per node

Check what ReadWriteOnce restricts and put it in /root/cst/accessmode.txt.

It does not mean 'only one Pod'. Several Pods on the same node can use it together.

What happens to the PV when you delete the PVC

Create one more temp PVC and delete it, and put what happens to its PV in /root/cst/reclaim.txt.

Create a temporary PVC, attach a Pod to bind it, then delete it and check the PV.

Give each Pod its own volume

Create a web StatefulSet (2 replicas) with volumeClaimTemplates, and put how many PVCs are created in /root/cst/sts.txt.

volumeClaimTemplates creates one PVC per Pod. Check the naming rule.

What you learned

In /root/cst/report.md, write three lines, binding_mode=, reclaim_policy=, and sts_pvcs=, and the relationship among the three layers.

Write the relationship among the three layers together with the three lines binding_mode=, reclaim_policy=, and sts_pvcs=.