IL-0026 Blue Matador · 2019-06-15kubernetesawsobservability
Blue Matador 의 운영 쿠버네티스 클러스터에서 2019년 6월 15일과 16일 이틀에 걸쳐 서로 다른 노드 두 대에 SystemOOM 이벤트가 났다. 노드는 곧바로 회복했고 애플리케이션 파드는 재시작되지 않아 눈에 띄는 서비스 중단은 없었다. 매번 SystemOOM 과 함께 루트 볼륨의 EBS Burst Balance 가 낮아졌다는 경고가 왔다. EBS 지표는 늘 10분에서 15분 늦게 들어오므로 경고는 SystemOOM 보다 늦게 왔다. 그러나 CloudWatch 데이터를 보면 burst balance 가 가장 낮았던 시점은 SystemOOM 보다 앞섰다.
원인은 로그 수집용 fluentd-sumologic 파드였다. 이 파드들이 노드 메모리를 다 쓰자 쿠버네티스가 이들을 죽이고 다시 띄워 메모리를 되찾았다. 다른 파드는 영향을 받지 않았다. Sumologic 쪽 로그량은 꾸준했고 문제 시점에 로그가 늘지 않았으므로, 로그 유입이 갑자기 늘어서 생긴 일은 아니었다. 매니페스트를 보니 fluentd-sumologic 에는 리소스 요청과 제한이 하나도 없었다.
담당자는 일요일 저녁에 모든 sumologic 파드를 재시작해, 파드들이 메모리를 적게 쓰는 상태에서 다시 출발하게 했다. 월요일에는 GitHub 이슈에서 찾은 Ruby GC 설정을 환경 변수로 넣고, 메모리 요청 128Mi, 제한 1024Mi, CPU 요청 100m, 제한 250m 을 지정해 배포했다. 며칠 뒤 노드 메모리가 안정된 것을 확인했다.
SystemOOM 과 함께 디스크 IO 가 늘어난 이유는 끝내 밝히지 못했다. 노드에서 free 와 swapon -s 로 확인한 결과 스왑은 꺼져 있었다. 담당자는 두 가지 가능성을 추정했다. 하나는 그때 fluentd-sumologic 파드가 로그를 많이 썼을 가능성이고, 다른 하나는 메모리가 부족할 때 로그를 많이 쏟아내는 쿠버네티스나 journald 로그 소스가 fluentd 설정에서 걸러지고 있었을 가능성이다. 문제 직전의 로그 파일은 이미 남아 있지 않아 더 파고들 수 없었다.
2019년 6월 15일 토요일 오후 5시 12분에 자체 모니터링이 운영 클러스터의 노드 한 대에서 SystemOOM 이벤트가 났다고 알렸다. 4분 뒤에는 같은 노드의 루트 볼륨에서 EBS Burst Balance 가 낮다는 경고가 왔다.
담당자가 kubectl get pods 로 확인했을 때 애플리케이션 파드는 하나도 죽지 않았다. kubectl top nodes 에서도 노드는 이미 회복되어 메모리 사용률이 60% 정도였다. 담당자는 일시적인 현상으로 보고 월요일에 살펴보기로 했다.
다음 날 오후 6시 2분에 다른 노드에서 다시 SystemOOM 알림이 왔고, 4분 뒤 EBS Burst Balance 경고가 이어졌다. 이번에도 파드는 죽지 않았고 노드 메모리 사용률은 70% 바로 아래였다. CloudWatch 를 보면 burst balance 는 문제가 나기 전 2시간 반쯤에 걸쳐 내려가고 있었다.
Datadog 의 메모리 그래프를 보니 SystemOOM 직전까지 노드 메모리를 많이 차지한 것은 fluentd-sumologic 파드였다. SystemOOM 시점에 이 파드들의 메모리 사용량이 급격히 떨어졌다. 토요일에 이를 놓친 것은 fluentd-sumologic 파드가 별도 네임스페이스에 있었고, 담당자가 그 네임스페이스를 확인하지 않았기 때문이다.
증상 ? OOMKilled
원인 ? 용량 한계
Blue Matador 의 자체 모니터링이 노드의 SystemOOM 이벤트 알림과 EBS Burst Balance 가 낮아졌다는 경고를 보냈다. 원인 파드는 Datadog 의 메모리 사용량 그래프에서 찾았다.
재시작된 파드를 확인할 때는 모든 네임스페이스를 본다. 이번에는 fluentd-sumologic 파드가 별도 네임스페이스에 있어 첫날 원인을 놓쳤다.
모든 파드, 특히 서드파티 애플리케이션에는 리소스 요청과 제한을 지정한다. 제한이 있으면 메모리 문제를 고치지는 못해도 그 문제가 해당 파드들 밖으로 번지지 않게 막을 수 있다.
보이는 문제는 증거가 남아 있을 때 근본 원인까지 파고든다. 이번에는 디스크 IO 가 늘어난 이유를 확인할 로그가 사라진 뒤였다.
같은 원인 · 공통 텔레메트리 에이전트, 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 텔레메트리 에이전트
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 텔레메트리 에이전트
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 텔레메트리 에이전트
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 텔레메트리 에이전트
같은 원인 · 공통 컨테이너 메모리 한도