컨테이너 내부 원리 · cgroup — 얼마나 쓸 수 있는가 · 퀴즈
퀴즈: cgroup
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
`--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` 줄을 확인한다