퀴즈: 자원 요청과 생성 거절

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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