LabHub
배우기 러닝패스 코스

CNPE — 클라우드 네이티브 플랫폼 엔지니어 (전문가) · 플랫폼 아키텍처와 인프라 · 실습

입장권은 있는데 자리가 없는 서버

LabHub 에서 이어서 보기

목표

개인 k3s에서 기본값 변경 → 쿼터 거절 → CPU 부족 Pending → 복구 → 팀별 API 권한을 직접 다룹니다.

왜 중요한가

플랫폼이 요청을 받았다는 것과 실행할 자리가 있다는 것은 별개입니다. ResourceQuota는
팀의 요청 합계를 제한하지만 특정 노드의 실행 자리를 예약하지 않습니다. LimitRange가
빈 요청을 채워도 과거 Pod까지 수정하지는 않습니다. 이 둘을 섞으면 운영자는 쿼터를
계속 올리고 사용자는 Pending 화면 앞에서 기다립니다. CNPE의 멀티테넌시·용량 판단 일부를
연습하며 공식 시험 문제나 전체 시험 범위를 대신하지 않습니다.

준비된 것

Ubuntu 개인 VM과 k3s v1.36.4+k3s1, busybox 실제 컨테이너, 다섯 개의 전용 Namespace가 있습니다.
kubectl 리소스 조회·JSON·jq·RBAC 기초가 필요합니다. KUBECONFIG는
/etc/rancher/k3s/k3s.yaml이고 모든 상대 파일 경로는 /root/cnpe-capacity 아래입니다.
baseline.json과 baseline-origin.json은 초기 UID·노드 용량·old 자료이며 수정하지 않습니다.
new-pod.json은 자원 생략 Pod, oversized-pod.json은 수정할 1코어 Pod 재료입니다.
old·memory-only·first·second·sample은 미리 실행됩니다. 빈 RBAC부터 필요한 권한만 추가합니다.
외부 클러스터의 kubeconfig·실제 자격 증명은 넣지 마세요. 모든 변경은 개인 VM 안에서 합니다.

75분 실습이므로 기본 60분 세션에서 ＋시간으로 연장하세요. 세션이 끝나면 VM과 파일이
사라집니다. 필요한 보고서는 종료 전에 별도로 보관하세요. 첫 준비는 수분 걸릴 수 있습니다.

단계

1. 기존 Pod의 신분증을 보관한다 — kubectl get nodes와 cnpe-cap-defaults의 old Pod를 조회하세요. baseline.json의 old 객체를 before.json에 저장합니다. UID와 요청량 25m·32Mi를 확인하고 old를 삭제하거나 재생성하지 마세요.
2. 새 입장객의 기본값만 바꾼다 — cnpe-cap-defaults의 LimitRange defaults를 수정하세요. limits에는 type Container 규칙 하나만 둡니다. defaultRequest는 cpu 50m·memory 48Mi, default는 cpu 100m·memory 64Mi입니다. 기존 old는 요청량과 UID가 그대로여야 합니다.
3. 메모리만 같으면 Guaranteed일까 — 준비된 new-pod.json을 자원 항목 없이 제출하여 cnpe-cap-defaults/new를 만드세요. Ready를 기다리고 새 요청 50m·48Mi를 확인합니다. cnpe-cap-memory/memory-only는 메모리 request=limit=64Mi이고 CPU는 없습니다. qos.json의 new와 memory_only에 각 Pod status.qosClass를 기록하세요.
4. 세 번째 손님을 입구에서 거절한다 — quota-manifest.json으로 cnpe-cap-quota에 ResourceQuota budget을 만드세요. hard는 requests.cpu 100m, requests.memory 256Mi, pods 4입니다. 기존 first·second는 각각 50m를 요청합니다. status.used.requests.cpu가 100m가 되면 collect quota를 실행하세요. 세 번째 50m 요청은 CPU 쿼터로 거절되고 객체가 없어야 합니다.
5. 입장권은 있는데 자리가 없는 서버 — oversized-pod.json의 too-large Pod에서 CPU request와 limit를 모두 baseline.json의 wanted_cpu로 바꾸세요. 이는 노드 allocatable 코어 수를 올림한 뒤 1을 더한 값입니다. cnpe-cap-schedule의 기존 쿼터는 그대로 두고 Pod를 생성합니다. PodScheduled=False, Unschedulable, Insufficient cpu와 미배치를 확인하고 쿼터 used CPU가 요청량이 되면 collect pending을 실행하세요.
6. 쿼터를 늘리지 않고 복구한다 — recovery-pod.json에 같은 Pod 이름·Namespace·보안 설정을 유지하고 requests cpu 25m·memory 32Mi, limits cpu 25m·memory 64Mi를 작성하세요. too-large만 삭제하고 이 파일로 재생성합니다. 새 UID와 Ready를 확인한 뒤 collect recovered를 실행하세요. pending 자료와 기존 schedule 쿼터는 보존합니다.
7. 팀원에게 읽기 권한만 준다 — role.json과 binding.json에 cnpe-cap-quota의 Role reader와 RoleBinding reader를 작성해 적용하세요. core API의 pods get·list만 기존 ServiceAccount tenant에 허용합니다. collect rbac로 자기 first 조회 성공, cnpe-cap-other/sample 조회 거절, budget 변경 거절을 수집하세요. ClusterRoleBinding이나 와일드카드 권한을 추가하지 마세요.
8. 증명한 것과 모르는 것을 나눈다 — report.json에 node_allocatable_m, pending_request_m, quota_hard_m, recovered_request_m을 millicore 정수로 기록하세요. old_pod_recreated는 초기·현재 UID 비교 불리언, memory_only_qos는 실제 QoS입니다. recovery_proves는 placement_only, isolation_proves는 api_permissions_only, cost_slo_verified는 false로 기록합니다. 필드는 이 아홉 개만 사용하며 최종 복구와 권한을 유지하세요.

참고

수집 형식은 python3 /opt/fixtures/cnpe-capacity-lab.py collect <단계>입니다.
단계는 quota, pending, recovered, rbac입니다. 수집기는 시험 요청과 관측 자료를
각 단계의 .json 및 -origin.json에 저장합니다. quota는 작은 Pod 생성 거절을 시험하고,
허용된 경우 그 시험 Pod만 회수합니다. rbac는 tenant의 조회와 같은 상한 값의 PATCH를
시험합니다. 파일 저장 성공이 요구 상태의 성공은 아닙니다. 채점 결과까지 확인하세요.
채점은 자료와 현재 API를 읽으며 답이나 권한을 수정하지 않습니다. 과거 Pending 자료를
따로 남기므로 복구 후에도 5단계를 다시 채점할 수 있습니다. 잘못된 조건으로 수집했다면
그 조건을 고친 뒤 다시 수집해야 합니다. old와 다른 초기 Pod를 삭제하지 마세요.

보존본 대조는 우발적 편집 방지이지 학생 root에 대한 위변조 방지가 아닙니다. 이 실습은
실사용량·지연 시간·비용·SLO·네트워크 차단을 측정하지 않습니다. Ready가 성능 보증이거나
API 권한 분리가 완전한 테넌트 격리라는 결론을 내리지 마세요.

공식 문서

단계 8개

  1. 기존 Pod의 신분증을 보관한다
  2. 새 입장객의 기본값만 바꾼다
  3. 메모리만 같으면 Guaranteed일까
  4. 세 번째 손님을 입구에서 거절한다
  5. 입장권은 있는데 자리가 없는 서버
  6. 쿼터를 늘리지 않고 복구한다
  7. 팀원에게 읽기 권한만 준다
  8. 증명한 것과 모르는 것을 나눈다