给事故分类的顺序

한 줄 요약

파드가 뜨지 않을 때 먼저 세야 할 것은 남은 자원이 아니라 후보 노드의 수입니다. 후보가 0 이면 남은 자원은 아무 의미가 없습니다.

왜 순서가 정해져 있나

먼저 Pod 객체가 존재하는지부터 나눕니다. ResourceQuota 공식 문서가 설명하는 쿼터 위반은 생성 요청을 거절할 수 있습니다. 이때는 Pending 파드가 아니라 Deployment·ReplicaSet 이벤트의 FailedCreate와 API 오류를 찾아야 합니다. LimitRange 위반도 입장 단계의 문제일 수 있습니다.

Pod가 있다면 Pod 생명주기를 따라 조건과 이벤트를 확인합니다. Pending에는 스케줄링 전뿐 아니라 이미지 준비 같은 대기도 들어갑니다. PodScheduled 조건, nodeName, 컨테이너 대기 이유를 함께 봅니다. 모든 Pending을 같은 순서의 자원 부족으로 해석하지 마세요.

이 실습의 가상 사고는 nodeSelector에 맞는 후보가 0인 경우입니다. 해당 조건을 이벤트로 확인한 다음 후보 수를 셉니다. 후보가 있어도 테인트, affinity, 볼륨, 실제 요청량 때문에 배치되지 않을 수 있습니다. 노드 할당 문서의 필수 선택 조건과 선호 조건을 구별하세요.

어떻게 동작하나

분류의 결과는 숫자여야 합니다

"자원이 부족한 것 같다" 는 분류가 아닙니다. 분류는 다음 네 값을 적는 일입니다.

항목	어디서 나오는가
선택자의 키와 값	워크로드의 nodeSelector
레플리카 수	Deployment 의 spec.replicas
필요한 총 CPU	컨테이너 요청 × 레플리카
후보 노드 수	그 선택자로 노드를 세어 본 값

이 네 값이 적혀 있으면 다음 사람이 같은 곳에서 시작합니다. 적혀 있지 않으면 다음 사람이 처음부터 다시 합니다. 사고 기록의 값어치는 문장이 아니라 이 숫자에 있습니다.

복구와 요구사항 삭제는 다른 일입니다

파드를 뜨게 만드는 가장 빠른 방법은 nodeSelector 를 지우는 것입니다. 다른 제약이 없다면 배치될 수 있습니다. 그런데 그 선택자는 누군가 이유가 있어서 적어 둔 것입니다. GPU 가 필요하거나, 특정 스토리지에 붙어야 하거나, 규제상 특정 노드에만 올라가야 하는 것입니다.

요구의 근거와 변경 승인을 확인하지 않고 제약을 지우면 요구사항 삭제가 될 수 있습니다. 그리고 이 차이는 화면에 드러나지 않습니다. 파드는 Running 이고 알림은 꺼지고 대시보드는 초록불입니다. 문제는 몇 주 뒤 엉뚱한 형태로 돌아옵니다.

복구는 제약을 만족시키는 쪽입니다. 노드에 풀 라벨을 붙이거나, 그 풀에 노드를 넣거나, 그럴 수 없다면 왜 못 하는지를 적고 워크로드 쪽 요구를 바꾸는 결정을 사람이 내리는 것입니다.

오른쪽 크기 조정은 방향이 정해져 있습니다

비용을 줄이라는 요구를 받으면 노드를 먼저 줄이고 싶어집니다. 먼저 대표 기간의 사용량·피크·실패·지연을 수집하고 요청량의 여유와 복구 용량을 검토합니다. 평균 사용량만 보고 낮추면 부하 급등을 놓칩니다. 요청 조정과 노드 축소는 되돌릴 조건을 정해 작은 범위에서 시험합니다. scale-to-zero 역시 기동 지연과 워크로드 요구에 따라 가능한 선택이지, 언제나 중단이나 언제나 절약이라고 단정할 수 없습니다.

현장에서 만나는 모습

다음은 실습을 위한 가상 사례입니다. 노드를 세 대 늘려도 파드가 계속 Pending입니다. 새 노드에 풀 라벨을 안 붙였고, 워크로드는 그 라벨을 요구하고 있었습니다. 용량 그래프는 올라갔고 후보 노드는 0 대 그대로였습니다. 대시보드만 보면 영원히 안 보이는 종류의 사고입니다.

또 하나는 라벨을 붙이고 바로 채점하듯 확인해 놓고 "안 된다" 고 결론 내린 경우입니다. 스케줄러는 주기적으로 다시 시도하므로 몇 초는 기다려야 합니다. 즉시 확인하고 판단하면 옳은 조치를 되돌리게 됩니다.

다음 실습에서 할 것

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