사고를 분류하는 순서

한 줄 요약

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

왜 순서가 정해져 있나

스케줄링 실패는 원인이 여럿인데 증상은 하나입니다. 전부 Pending 입니다. 그래서 아무 데나 찔러 보면 시간을 잃습니다. 순서를 정해 두면 각 단계에서 하나씩 걸러집니다.

1. 이 파드의 선택자를 만족하는 노드가 몇 대인가        → 0 이면 여기서 끝2. 그 노드들에 남은 자원이 요청을 감당하는가            → 아니면 여기서 끝3. 테인트가 있고 톨러레이션이 없지는 않은가4. 네임스페이스 쿼터가 이미 차 있지는 않은가5. LimitRange 의 max 에 걸리지는 않는가

1번을 건너뛰면 나머지가 전부 헛수고가 됩니다. 용량을 늘려도 후보가 0 이면 아무 일도 일어나지 않기 때문입니다.

어떻게 동작하나

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

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

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

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

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

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

제약을 지워서 뜨게 한 것은 복구가 아니라 요구사항 삭제입니다. 그리고 이 차이는 화면에 드러나지 않습니다. 파드는 Running 이고 알림은 꺼지고 대시보드는 초록불입니다. 문제는 몇 주 뒤 엉뚱한 형태로 돌아옵니다.

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

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

비용을 줄이라는 요구를 받으면 노드를 먼저 줄이고 싶어집니다. 그런데 대부분의 낭비는 노드가 아니라 요청과 실사용의 차이에 있습니다. 요청을 실사용에 맞춰 내리고 그다음에 노드를 정리해야 합니다. 순서를 뒤집으면 워크로드가 못 뜨고, 아무것도 해결되지 않은 채 장애만 하나 생깁니다.

현장에서 만나는 모습

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

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

다음 실습에서 할 것

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