测验：CPU 让它变慢，内存让它死掉

cpu 한계는 커널에서 어떻게 집행되는가?

• 한계를 넘으면 컨테이너가 종료 코드 137 로 종료된다
• 스로틀링으로 집행되어 한계보다 더 쓸 수 없지만 종료되지는 않는다
• 스케줄러가 그 Pod 를 다른 노드로 다시 배치한다
• 한계를 넘은 만큼 다음 주기의 요청량이 자동으로 늘어난다

memory 한계 집행이 '반응형' 이라는 말의 뜻은?

• 한계를 넘는 순간 커널이 예외 없이 즉시 종료한다는 뜻이다
• 한계를 넘으면 커널이 그 컨테이너의 할당 요청을 거부한다는 뜻이다
• 커널이 메모리 압박을 감지했을 때 종료가 일어나므로 즉시 죽지 않을 수도 있다는 뜻이다
• kubelet 이 주기적으로 사용량을 조사해 초과분을 회수한다는 뜻이다

메모리를 매체로 쓰는 emptyDir 볼륨에 파일을 쓰면 그 사용량은 무엇으로 계산되는가?

• 컨테이너의 메모리 사용량으로 계산된다
• 노드의 로컬 임시 저장소 사용량으로 계산된다
• 어느 쪽에도 계산되지 않고 볼륨 자체의 sizeLimit 만 적용된다
• Pod 의 CPU 요청량에 비례해 환산되어 계산된다

requests 와 limits 의 역할을 바르게 나눈 것은?

• requests 는 상한이고 limits 는 하한이다
• requests 는 kubelet 이, limits 는 스케줄러가 각각 집행한다
• 둘 다 스케줄링에만 쓰이고 실행 중에는 영향이 없다
• requests 는 스케줄러가 배치에 쓰고, limits 는 kubelet 과 커널이 사용량 제한에 쓴다

cpu 한계를 너무 낮게 잡은 배포에서 가장 흔히 나타나는 증상은?

• 성공률은 그대로인데 응답 시간만 몇 배로 늘어난다
• 컨테이너가 CrashLoopBackOff 로 반복 재시작한다
• Pod 가 Pending 에서 벗어나지 못한다
• 컨테이너 로그에 스로틀링 경고가 줄마다 남는다

컨테이너가 OOM 으로 종료되었을 때 상태에 남는 흔적으로 알맞은 것은?

• 종료 코드 0 과 Completed 이유
• 종료 코드 137 과 OOMKilled 이유
• 종료 코드 1 과 Error 이유만 남고 메모리 관련 표시는 없다
• 종료 코드 143 과 Throttled 이유