LabHub

CKA — 쿠버네티스 관리자 · 진짜 클러스터에서 확인하기 · 실습

PVC 가 실제로 바인딩되는 것을 본다

LabHub 에서 이어서 보기

이 실습은 진짜 프로비저너가 있는 클러스터에서 돕니다

VM 안의 k3s 에는 local-path 동적 프로비저너가 실제로 돕니다. PVC 를
만들면 PV 가 자동으로 생기고, 파일을 쓰면 파드를 지워도 남습니다.

CKA 과정의 다른 스토리지 실습이 도는 가짜 클러스터에는 프로비저너가 없어
PVC 가 영원히 Pending 입니다. 그래서 YAML 을 쓰는 연습까지가
전부였습니다.

처음 뜨는 데 2분쯤 걸립니다.

목표

StorageClass · PVC · PV 세 층이 어떻게 맞물리는지를 상태 변화로 확인하고,
WaitForFirstConsumer 가 왜 있는지를 직접 봅니다.

왜 중요한가

스토리지는 "YAML 을 맞게 썼는가" 보다 "지금 왜 이 상태인가" 를 읽는 일이
훨씬 많습니다. 그중 가장 자주 오해받는 것이 Pending 입니다.

WaitForFirstConsumer 인 StorageClass 에서 PVC 를 만들면 **일부러 Pending 에
머뭅니다.** 결함이 아니라 설계입니다. 볼륨을 어느 노드에 만들지는 그 볼륨을
쓸 파드가 어느 노드에 놓일지에 달렸는데, 파드가 없으면 알 수 없기 때문입니다.

먼저 볼륨을 만들어 버리면 스케줄러가 파드를 그 노드에만 놓을 수 있게 되어,
자리가 없을 때 파드가 영영 안 뜹니다. 순서를 뒤집어 이 문제를 없앤 것이
WaitForFirstConsumer 입니다.

이것을 모르면 "PVC 가 Pending 인데 프로비저너가 고장 났나" 를 한참 뒤지게
됩니다.

단계

모든 것은 cst 네임스페이스에 만듭니다.

1. local-path StorageClass 의 프로비저너바인딩 모드를 확인해 /root/cst/sc.txt 에 담으세요.
2. data 라는 PVC(1Gi, ReadWriteOnce)를 만들고 파드를 붙이기 전의 상태/root/cst/pending.txt 에 담으세요. 왜 그 상태인지도 적습니다.
3. writer 파드를 만들어 그 PVC 를 마운트하고, PVC 가 Bound 로 바뀌는 것과 자동으로 만들어진 PV 이름/root/cst/bound.txt 에 담으세요.
4. 볼륨에 파일을 쓰고 파드를 지웠다 다시 만들어 데이터가 남는지 확인해 /root/cst/persist.txt 에 담으세요.
5. ReadWriteOnce 가 무엇을 제한하는지 확인해 /root/cst/accessmode.txt 에 담으세요.
6. temp PVC 를 하나 더 만들었다 지우고, 그 PV 가 어떻게 되는지 /root/cst/reclaim.txt 에 담으세요.
7. web 스테이트풀셋(레플리카 2)을 volumeClaimTemplates 와 함께 만들고, PVC 가 몇 개 생기는지 /root/cst/sts.txt 에 담으세요.
8. /root/cst/report.mdbinding_mode=, reclaim_policy=, sts_pvcs= 세 줄과 세 층의 관계를 쓰세요.

참고

단계 8개

  1. 누가 볼륨을 만드는가
  2. Pending 이 정상인 경우
  3. 파드를 붙이면 볼륨이 생긴다
  4. 파드를 지워도 데이터는 남는다
  5. ReadWriteOnce 는 노드 단위다
  6. PVC 를 지우면 PV 는 어떻게 되나
  7. 파드마다 볼륨을 따로 준다
  8. 무엇을 배웠나