クイズ: cgroup

--memory=256m --cpus=0.5 로 띄운 컨테이너 안에서 free -m 이 64228MB, nproc 이 32 로 나옵니다. 가장 정확한 설명은?

• 제한이 적용되지 않은 것이므로 다시 걸어야 한다
• cgroup 은 제한을 강제하지만 /proc 의 호스트 값을 가리지는 않는다
• free 와 nproc 은 원래 컨테이너에서 동작하지 않는다
• 메모리 한도는 스왑을 포함하므로 값이 커 보인다

Go 로 만든 서비스를 0.5 코어로 제한했더니 응답시간만 튀고 CPU 사용률은 낮게 나옵니다. 가장 먼저 확인·조치할 것은?

• 컨테이너의 메모리 한도를 올려 준다
• 복제본 수를 두 배로 늘려 부하를 나눈다
• memory.high 를 낮춰 메모리 회수를 앞당기고 지켜본다
• cpu.stat 의 nr_throttled/nr_periods 비율을 보고 GOMAXPROCS 를 명시한다

memory.high 와 memory.max 의 차이로 옳은 것은?

• high 를 넘으면 즉시 OOM Kill, max 를 넘으면 경고만 남는다
• high 를 넘으면 회수 압박과 할당 지연이 걸리고 죽지는 않으며, max 를 넘으면 OOM Kill 이다
• 둘 다 동일하며 v1/v2 이름만 다르다
• high 는 CPU, max 는 메모리에 적용된다

쿠버네티스에서 노드 메모리가 부족할 때 BestEffort 파드가 먼저 죽는 이유는?

• QoS 클래스별 OOM score 가 Guaranteed -997 / Burstable 2~999 / BestEffort 1000 으로 설정되어 커널 OOM 킬러가 그 순서로 고르기 때문
• 스케줄러가 노드 메모리를 지켜보다가 BestEffort 파드를 가장 먼저 축출하도록 그렇게 코딩되어 있기 때문
• BestEffort 파드는 cgroup 에 등록되지 않기 때문
• BestEffort 는 메모리 한도가 0 이라 항상 초과 상태이기 때문

cgroup 이라는 이름의 유래로 옳은 것은?

• cluster group 의 약자로 쿠버네티스에서 유래했다
• control group 의 약자로, 2007년 커널 병합 때 container 라는 용어와의 혼동을 피하려고 개명됐다
• core group 의 약자로 CPU 코어 할당에서 시작됐다
• container group 의 약자로 도커가 도입했다

컨테이너가 종료코드 137 로 끝났습니다. OOM 킬인지 사람이 보낸 SIGKILL 인지 가르는 방법으로 가장 적절한 것은?

• 애플리케이션 로그에 남아 있는 예외 스택 트레이스와 종료 직전 줄을 확인한다
• 종료코드가 137 이면 항상 OOM 이므로 구분할 필요가 없다
• 재시작 정책을 always 로 바꿔 재현되는지 본다
• 런타임의 State.OOMKilled 필드와 커널 로그의 Memory cgroup out of memory 줄을 확인한다