クイズ: プラットフォームのアーキテクチャとインフラ

allocatable CPU 24코어, 세 테넌트 requests.cpu 쿼터 상한의 합 30코어입니다. 현재 파드 정보 없이 말할 수 있는 것은?

• 상한 합/용량은 1.25이며 실제 requests 합과 사용량은 따로 확인해야 한다
• 실행 중 파드가 30코어를 예약했으며 여섯 코어는 항상 Pending이다
• 클러스터 CPU 사용률이 125%이므로 모든 팀이 즉시 제한을 받는다
• 쿼터 합이 용량을 넘었으므로 API 서버가 마지막 쿼터를 거절한다

컨테이너 하나인 새 파드에 메모리 request/limit만 64Mi로 채워졌고 CPU 자원과 파드 수준 resources는 없습니다. QoS는?

• Guaranteed: 지정된 메모리의 request와 limit이 서로 같기 때문이다
• Burstable: 메모리 자원은 있지만 Guaranteed의 CPU 조건이 빠졌기 때문이다
• BestEffort: CPU를 선언하지 않으면 메모리 자원도 무시하기 때문이다
• 생성 거절: 메모리만 선언하는 파드는 API 스키마가 금지하기 때문이다

같은 노드에서 두 파드가 같은 RWO PVC를 사용하고 둘 다 Ready입니다. 가장 적절한 판단은?

• RWO는 파드 하나만 허용하므로 Ready 상태 중 하나는 반드시 위조다
• 같이 마운트됐으므로 두 버전의 동시 쓰기 정합성까지 검증됐다
• RWO는 이를 허용할 수 있으며 애플리케이션의 동시 쓰기 안전성은 별도다
• 다음 파드 재시작 전에 RWX로 바꿔야만 현재 공유 데이터가 보존된다

원장 서비스의 새 버전은 시작하자마자 데이터를 갱신합니다. 블루/그린의 preview로만 노출하면 어떤 점을 확인해야 합니까?

• Service 전환이 모든 파일 잠금을 자동 처리하는지 확인한다
• preview로 가는 외부 트래픽이 없으면 쓰기가 없다고 판단한다
• RWO가 이전 파드를 자동 종료한 뒤 새 파드를 켜는지 기다린다
• 트래픽과 별개로 두 버전의 writer가 겹치지 않도록 제어한다

LimitRange의 defaultRequest를 낮췄는데 기존 파드의 request가 그대로입니다. 이 관찰을 어떻게 읽습니까?

• 기본값은 새 파드 admission에 적용되므로 기존 객체와 새 객체를 나눠 확인한다
• 쿼터 컨트롤러가 다음 주기에 기존 파드의 모든 request를 자동으로 낮춘다
• kubectl get 캐시가 문제이므로 API 서버를 재시작해 새 기본값을 강제한다
• defaultRequest가 무시됐으므로 LimitRange를 삭제하면 기존 값도 제거된다

노드 추가 후에도 파드 이벤트에 nodeSelector 불일치가 표시됩니다. 다음 행동으로 적절한 것은?

• 전체 CPU 사용률을 먼저 낮추면 스케줄러가 선택자 조건을 완화한다
• 선택자와 노드 라벨을 대조하고 다른 배치 제약도 함께 점검한다
• PVC 크기를 늘리면 새 노드가 선택자를 만족하는 후보로 바뀐다
• 요청량만 줄이면 라벨이 없는 노드에도 같은 파드를 배치할 수 있다