クイズ：リソース要求と作成拒否

단일 노드의 allocatable CPU가 2인데 새 Pod가 CPU 3을 요청한다. 실제 사용률은 낮다. 가장 정확한 설명은?

• 요청량이 노드에 맞지 않아 배치되지 않을 수 있다.
• 사용률이 낮으면 요청량을 무시하고 우선 실행한다.
• limits만 3보다 높이면 요청은 항상 수락·배치된다.
• CPU 요청을 넘는 사용이 없으므로 반드시 Ready다.

Pending Pod의 원인을 CPU 요청량으로 좁히려 한다. 가장 직접적인 증거 조합은?

• 노드의 전체 사용률과 앱이 작다는 개발자의 설명
• 미배치 조건과 해당 Pod UID의 Insufficient cpu 이벤트
• Pod 이름과 어제 다른 UID에서 발생한 이미지 오류
• 컨테이너의 CPU limit와 Service의 ClusterIP 존재

컨테이너에 requests.cpu=250m, limits.cpu=1을 선언했다. 두 값의 관계를 올바르게 설명한 것은?

• 250m는 노드 전체 CPU의 250%를 요청한다는 뜻이다.
• 250m를 초과하는 순간 컨테이너는 반드시 종료된다.
• 0.25 CPU를 배치 계산에 쓰고 1 CPU를 제한값으로 둔다.
• CPU limit는 메모리 부족 종료의 기준량을 나타낸다.

CPU 50m를 명시한 기존 Pod가 있다. 기본 요청 100m의 LimitRange를 추가한 뒤 자원 필드를 생략한 새 Pod를 만들었다. 무엇을 비교해야 하나?

• 두 Pod가 모두 100m로 바뀌었다고 보고 원본은 생략한다.
• 새 Pod에 필드가 없으면 기본값 적용을 성공으로 본다.
• 기존 Pod를 먼저 삭제해 두 요청량을 동일하게 만든다.
• 새 입력과 저장된 기본값을 비교하고 기존 50m도 확인한다.

requests.cpu 사용량이 150m이고 상한은 200m다. 기본 요청 100m의 Pod 생성이 할당량 때문에 거절됐다. 올바른 관측은?

• API의 할당량 403을 확인하고 해당 Pod의 부재도 확인한다.
• 생성된 Pending Pod를 찾고 CPU 사용률이 낮아질 때까지 기다린다.
• Forbidden이면 할당량 본문과 무관하게 관리자 권한을 추가한다.
• 동일 이름의 오래된 Pod가 있으면 이번 생성도 성공으로 친다.

상한을 300m로 조정한 뒤 같은 요청에 HTTP 201이 반환됐다. 다음 확인으로 알맞은 것은?

• 201이면 kubelet 실행까지 끝났으므로 바로 정상으로 보고한다.
• 응답 UID와 저장된 Pod를 대조하고 실제 배치·기동도 확인한다.
• 입장이 허용됐으니 nodeName과 메모리 조건은 더 볼 필요 없다.
• 이전 실패 이벤트가 하나라도 남아 있으면 생성이 실패한 것이다.

기존 Pod의 CPU 요청 합계는 250m다. quota 상한을 100m로 낮췄는데 기존 Pod 세 개가 계속 실행된다. 가장 적절한 판단은?

• quota가 기존 Pod를 종료하지 않았으므로 적용에 실패했다.
• 기존 Pod의 요청이 자동으로 100m에 맞춰 축소된 상태다.
• 기존 객체는 유지될 수 있으므로 새 생성 거절을 추가 확인한다.
• 상한보다 많이 사용하면 모든 namespace의 Pod를 회수해야 한다.

실험용 extra Pod를 회수해 100m를 돌려받고 작은 요청을 다시 만들려 한다. 가장 신뢰할 수 있는 절차는?

• 이름이 extra인 객체를 강제 삭제하고 즉시 성공을 기록한다.
• 다른 팀 Pod부터 지워 메모리를 넉넉하게 만든 뒤 재시도한다.
• quota를 삭제한 뒤 새 Pod가 생성되면 예산 복구로 기록한다.
• 조사한 UID만 회수하고 객체 부재·사용량 감소 후 다시 요청한다.