멀티테넌시 자원과 사고 대응

목표

세 테넌트를 만들어 쿼터와 LimitRange 로 자원을 나누고, 오버커밋 비율을 직접 계산해 기록하고, 스케줄링 사고를 재현해 숫자로 분류한 뒤 요구사항을 지우지 않고 복구하고, 플랫폼 자신의 기록 규칙과 알림을 만들어 클러스터에 올립니다.

왜 중요한가

관측과 운영은 CNPE 배점의 20% 이고, 여기서 묻는 것은 도구 조작이 아니라 판단의 순서입니다. 사고가 났을 때 무엇부터 세는지, 그 값을 어디에 적는지, 그리고 무엇을 복구라고 부를 것인지가 그 순서입니다.

특히 마지막 항목이 중요합니다. 제약을 지워서 파드를 뜨게 하는 것과 제약을 만족시켜 뜨게 하는 것은 화면에서 구별되지 않습니다. 둘 다 Running 이고 둘 다 알림이 꺼집니다. 구별하는 것은 사람이고, 그 판단을 손에 익히는 것이 이 실습의 목적입니다.

이 클러스터의 노드는 세 대이고 각각 8 코어입니다. 그래서 클러스터 전체의 allocatable CPU 는 24 코어입니다. 쿼터 합계를 이 값으로 나눈 것이 오버커밋 비율입니다.

작업 디렉터리는 /root/cnpe-ops 입니다.

단계

1. 네임스페이스 tenant-red, tenant-green, tenant-gold 를 만들고 각각에 platform.labhub.io/tenant 라벨을 붙입니다. 값은 이름에서 tenant- 를 뗀 것입니다. 그다음 /root/cnpe-ops/inventory.txt 에 tenants 와 tenant_list 두 줄을 적습니다. 목록은 이름순으로 쉼표만 넣어 잇습니다.
2. /root/cnpe-ops/quotas.yaml 에 세 테넌트의 ResourceQuota 를 씁니다. 이름은 각각 tenant-red-quota 처럼 네임스페이스 이름에 -quota 를 붙인 것이고, requests.cpu 를 반드시 넣습니다. 세 쿼터의 requests.cpu 합계를 24 로 나눈 값이 1.00 초과 1.25 이하가 되게 하고, 어느 테넌트도 6 코어 아래로 내리지 않습니다. 그다음 /root/cnpe-ops/capacity.txt 에 quota_cpu, allocatable_cpu, overcommit 세 줄을 적습니다.
3. /root/cnpe-ops/limitranges.yaml 에 세 테넌트의 LimitRange 를 씁니다. 이름은 tenant-red-limits 처럼 짓습니다. defaultRequest 와 default 를 모두 두되 defaultRequest 의 CPU 가 default 의 CPU 보다 낮아야 하고, max 로 컨테이너 한 개가 CPU 4 코어를 요구하지 못하게 막습니다.
4. /root/cnpe-ops/ledger.yaml 에 Deployment ledger 를 써서 tenant-red 에 적용합니다. replicas 는 3, 파드 라벨은 app=ledger, nodeSelector 는 platform.labhub.io/pool=gpu 하나이며, 컨테이너 요청은 CPU 500m 과 메모리 512Mi 이고 이미지는 다이제스트로 고정합니다. 이 시점에 파드는 뜨지 못합니다.
5. /root/cnpe-ops/triage.txt 에 selector_key, selector_value, replicas, required_cpu 네 줄을 적습니다. required_cpu 는 컨테이너 요청에 레플리카 수를 곱한 값을 밀리코어로 적습니다.
6. 노드 한 대에만 platform.labhub.io/pool=gpu 라벨을 붙여 복구합니다. Deployment 의 nodeSelector 와 replicas 는 그대로 두어야 합니다. 파드 세 개가 모두 Running 이 될 때까지 확인합니다.
7. /root/cnpe-ops/platform-rules.yaml 에 Prometheus 규칙을 씁니다. 그룹 이름은 platform-slo 이고, 기록 규칙 platform:provision_success:ratio5m 은 나눗셈과 5분 구간을 써야 하며, 알림 규칙 PlatformProvisionFailing 에는 for, labels.severity, annotations.summary, annotations.runbook_url 이 있어야 합니다. promtool check rules 로 통과시킵니다.
8. 네임스페이스 monitoring 을 만들고, /root/cnpe-ops/platform-rules-cr.yaml 에 PrometheusRule platform-slo 를 써서 적용합니다. 그룹 이름은 7단계의 파일과 같아야 합니다. 마지막으로 /root/cnpe-ops/ops-report.txt 에 tenants, pool_nodes, ledger_running, alert_rules 네 줄을 조회한 값으로 적습니다.

참고

• 라벨로 센 값이 곧 플랫폼이 스스로 아는 값입니다. kubectl get ns -l platform.labhub.io/tenant 로 세십시오.
• 노드의 allocatable 은 kubectl get nodes -o json | jq '[.items[].status.allocatable.cpu | tonumber] | add' 로 다시 셀 수 있습니다.
• LimitRange 가 실제로 무엇을 채우는지 보려면 요청을 비운 파드를 --dry-run=server 로 넣어 보고 결과를 읽는 것이 가장 확실합니다.
• 라벨을 붙인 뒤에는 스케줄러가 한 바퀴 돌 시간을 주십시오. 즉시 확인하고 판단하면 옳은 조치를 되돌리게 됩니다.
• 흔한 실수 하나는 파드를 뜨게 하려고 nodeSelector 를 지우는 것입니다. 그것은 복구가 아니라 요구사항 삭제입니다.
• 또 하나는 검증한 규칙 파일과 다른 내용을 PrometheusRule 로 올리는 것입니다. 그러면 promtool 통과가 아무것도 보장하지 않게 됩니다.

단계 8개

1. 테넌트를 기계가 셀 수 있게 만들기
2. 약속한 양과 실제로 가진 양을 나눠 보기
3. 안 적은 사람에게 채워 줄 값 정하기
4. 사고를 재현해 두기
5. 분류의 결과를 숫자로 적기
6. 제약을 지우지 않고 복구하기
7. 플랫폼 자신의 기록 규칙과 알림 쓰기
8. 검증한 규칙을 올리고 현재 상태를 기록하기