Watch the Scheduler Pick a Seat

이 실습은 자원이 진짜로 모자란 클러스터에서 합니다

VM 안에 진짜 k3s 가 떠 있습니다. 노드에 CPU 가 실제로 유한하기 때문에, 요청을 크게 잡으면 정말로 자리가 모자라 Pending 에 머뭅니다.

CKA 과정의 다른 스케줄링 실습이 도는 가짜 클러스터에는 가짜 노드가 여럿 있고 자원 압박이 없어서, 무엇을 요청하든 다 놓입니다. 그래서 스케줄러가 실제로 무엇을 보고 거절하는지 확인할 수 없었습니다.

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

목표

스케줄러가 자리를 고르는 다섯 가지 장치를 실제로 막히게 만들어 확인합니다. 그리고 우선순위가 낮은 파드가 쫓겨나는 것까지 봅니다.

왜 중요한가

스케줄링 설정은 "잘 쓰면 원하는 데 놓인다" 보다 "잘못 쓰면 아무 데도 안 놓인다" 쪽이 훨씬 자주 문제가 됩니다. 그리고 그 증상은 언제나 같습니다 — 파드가 Pending 입니다.

원인은 여러 층에 흩어져 있습니다.

• 자원 요청이 노드보다 큼 → Insufficient cpu
• 테인트를 톨러레이트하지 않음 → untolerated taint
• required 어피니티가 맞는 노드가 없음 → didn't match node affinity
• 안티어피니티가 같은 노드를 막음
• 토폴로지 분산이 DoNotSchedule 인데 나눌 노드가 없음

스케줄러는 왜 못 놓았는지를 언제나 이벤트에 남깁니다. 그것을 읽는 훈련이 이 실습의 전부입니다.

단계

모든 것은 csch 네임스페이스에 만듭니다. 노드는 한 대입니다.

1. 노드의 capacity 와 allocatable, 그리고 지금 얼마나 요청되어 있는지를 /root/csch/capacity.txt 에 담으세요.
2. hog-a·hog-b·hog-c 세 파드로 자리를 다투게 하세요. 앞의 둘은 놓이고 셋째는 Pending 이어야 합니다. 스케줄러의 사유를 /root/csch/pressure.txt 에 담습니다.
3. 노드에 lab=only:NoSchedule 테인트를 걸고, 톨러레이션이 없는 no-tol 과 있는 with-tol 을 비교해 /root/csch/taint.txt 에 담으세요.
4. 노드에 disktype=ssd 라벨을 붙이고 aff-required(맞는 것)·aff-impossible(없는 라벨을 required 로)·aff-preferred(없는 라벨을 preferred 로) 셋을 만들어 /root/csch/affinity.txt 에 담으세요.
5. spread Deployment(레플리카 2)에 required 안티어피니티를 걸어, 노드가 하나뿐이라 하나만 뜨는 것을 /root/csch/anti.txt 에 담으세요.
6. low-prio·high-prio PriorityClass 를 만들고, 낮은 것으로 노드를 채운 뒤 important(높은 것)를 넣어 선점이 일어나는 것을 /root/csch/preempt.txt 에 담으세요.
7. even Deployment 에 topologySpreadConstraints 를 ScheduleAnyway 로 걸어 /root/csch/spread.txt 에 담으세요.
8. /root/csch/report.md 에 pending_reason=Insufficient, taint_effect=NoSchedule, high_priority_value= 세 줄과 설명을 쓰세요.

참고

• 노드 정보는 kubectl describe node 의 Capacity·Allocatable·Allocated resources 세 절에 있습니다. 셋은 다른 값입니다.
• 스케줄러의 사유는 kubectl -n csch describe pod <이름> 의 Events 나 .status.conditions[?(@.type=="PodScheduled")].message 에 있습니다.
• 테인트는 kubectl taint node <노드> lab=only:NoSchedule 로 걸고, 지울 때는 끝에 - 를 붙입니다.
• 7번에서 whenUnsatisfiable 을 DoNotSchedule 로 두면 노드가 하나뿐이라 아무것도 안 뜹니다. ScheduleAnyway 를 쓰세요.
• 흔한 실수 1: requests 대신 limits 로 자리를 다투려는 것. 스케줄러가 보는 것은 requests 뿐입니다. limits 는 실행 중에 커널이 강제하는 값입니다.
• 흔한 실수 2: 테인트를 걸고 나서 기존 파드가 왜 안 쫓겨나는지 의아해하는 것. NoSchedule 은 새로 놓는 것만 막습니다. 이미 있는 것까지 쫓아내려면 NoExecute 입니다.

노드에 무엇이 얼마나 있는가

노드의 capacity 와 allocatable, 그리고 지금 얼마나 요청되어 있는지를 /root/csch/capacity.txt 에 담으세요.

capacity 는 하드웨어가 가진 것, allocatable 은 시스템 몫을 뺀 나머지, Allocated resources 는 이미 요청된 합계입니다.

자리가 모자라면 기다린다

hog-a·hog-b·hog-c 세 파드로 자리를 다투게 하세요. 앞의 둘은 놓이고 셋째는 Pending 이어야 합니다. 스케줄러의 사유를 /root/csch/pressure.txt 에 담습니다.

CPU requests 를 크게 잡아 두 개만 들어가게 하세요. 스케줄러가 보는 것은 requests 뿐입니다.

노드가 거절한다

노드에 lab=only:NoSchedule 테인트를 걸고, 톨러레이션이 없는 no-tol 과 있는 with-tol 을 비교해 /root/csch/taint.txt 에 담으세요.

테인트는 노드가 거는 것이고, 톨러레이션은 파드가 갖는 것입니다. NoSchedule 은 새로 놓는 것만 막습니다.

required 와 preferred

노드에 disktype=ssd 라벨을 붙이고 aff-required(맞는 것)·aff-impossible(없는 라벨을 required 로)·aff-preferred(없는 라벨을 preferred 로) 셋을 만들어 /root/csch/affinity.txt 에 담으세요.

required 는 못 맞추면 영영 Pending 이고, preferred 는 못 맞춰도 놓입니다.

같은 노드를 피한다

spread Deployment(레플리카 2)에 required 안티어피니티를 걸어, 노드가 하나뿐이라 하나만 뜨는 것을 /root/csch/anti.txt 에 담으세요.

topologyKey: kubernetes.io/hostname 은 '노드가 다르면 된다' 는 뜻입니다. 노드가 하나면 두 번째는 놓일 곳이 없습니다.

높은 우선순위가 자리를 빼앗는다

low-prio·high-prio PriorityClass 를 만들고, 낮은 것으로 노드를 채운 뒤 important(높은 것)를 넣어 선점이 일어나는 것을 /root/csch/preempt.txt 에 담으세요.

낮은 우선순위로 노드를 채운 뒤 높은 우선순위 파드를 넣으면, 스케줄러가 낮은 것을 쫓아냅니다.

고르게 흩는다

even Deployment 에 topologySpreadConstraints 를 ScheduleAnyway 로 걸어 /root/csch/spread.txt 에 담으세요.

노드가 하나뿐이므로 whenUnsatisfiable: ScheduleAnyway 여야 합니다. DoNotSchedule 이면 아무것도 안 뜹니다.

무엇을 배웠나

/root/csch/report.md 에 pending_reason=Insufficient, taint_effect=NoSchedule, high_priority_value= 세 줄과 설명을 쓰세요.

pending_reason=, taint_effect=, high_priority_value= 세 줄과 함께 Pending 을 좁히는 순서를 쓰세요.