사례3건

3건 중 1~3번째

1. IL-0191 Loki distributor 서비스에 레이블 셀렉터가 하나 더 들어가 롤아웃 중 새 파드 몇 개에만 쓰기 트래픽이 몰렸고, 그 파드들이 OOM으로 죽으면서 로그 쓰기 경로가 약 25분간 멈췄다.

   Grafana Labs2022

   증상

   Grafana Cloud Logs 의 한 환경에서 Grafana Loki 의 쓰기 경로가 내려갔다. 롤아웃 중이던 distributor 파드가 OOM으로 죽었다가 다시 뜨기를 되풀이했다.

   서비스 중단OOMKilled부하 불균형프로브 실패

   촉발

   키-값 저장소에서 내장 memberlist 로 옮기는 마이그레이션의 1단계가 distributor 디플로이먼트와 서비스에 새 레이블을 붙였다. 서비스를 만드는 함수가 이 레이블을 셀렉터로도 복사했기 때문에, 롤아웃이 시작되자 distributor 서비스는 새 레이블을 단 새 파드만 가리켰다.

   원인

   설정 변경

   구성 요소

   설정 템플릿서비스 디스커버리컨테이너 메모리 한도

   기여 요인

   기본 설정 방치초기 신호 무시스테이징 불일치

   감지

   처음에는 distributor 가 OOM으로 죽는 장애로 보였다. 첫 단서는 kubectl get pods 와 kube_deployment_status_replicas_updated 지표에서 distributor 의 10%만 재시작됐다는 점이었다. 팀은 PR 마다 Kubernetes 매니페스트 diff 를 만들어 PR 에 올리고 별도 레포에도 저장하는 자동화를 갖고 있었다. 이 diff 에서 distributor 서비스에 셀렉터가 추가되고 서비스가 다시 만들어진 것을 찾았다. 평소 배포에서는 서비스가 다시 만들어지지 않는다.

   조치

   • distributor 디플로이먼트의 레플리카를 늘렸다. 새로 뜬 파드도 새 레이블을 달고 있어서 부하가 더 많은 파드로 나뉘었고, OOM으로 죽는 파드가 줄면서 Kubernetes 가 옛 파드 교체를 이어 갔다.
   • 마이그레이션 단계의 변경을 되돌려 장애를 완전히 끝내고 원인을 조사할 시간을 벌었다.
   • service_ignored_labels:: [$._config.gossip_member_label] 을 설정하고 서비스 생성 함수 k.util.serviceFor 에 넘겨, memberlist 레이블이 서비스 셀렉터로 복사되지 않게 했다.

   후속 조치

   • 디플로이먼트나 스테이트풀셋의 레이블을 서비스 셀렉터로 복사하던 함수가 이번 같은 예외 상황도 처리하도록 고쳤다.

   교훈

   서비스 셀렉터를 디플로이먼트 레이블에서 자동으로 만들면, 롤아웃 중에 새 레이블이 붙는 순간 서비스가 새 파드만 가리킬 수 있다. 다른 환경에서 본 작은 오류를 롤아웃 때 흔한 잡음으로 넘기면 이런 신호를 놓친다. 환경마다 수평 확장과 메모리 한도 설정이 다르면 다른 환경에서 문제없던 변경이 특정 환경에서만 장애를 낸다. 원인을 빨리 찾는 데에는 Loki 와 Kubernetes 지표, PR 마다 남겨 둔 매니페스트 diff 가 도움이 됐다.

   사례 보기
2. IL-0026 메모리 제한이 없는 fluentd-sumologic 파드가 메모리를 다 써서 운영 쿠버네티스 노드 두 대에 이틀 연속 SystemOOM 이 났다

   Blue Matador2019

   증상

   2019년 6월 15일 토요일 오후 5시 12분에 자체 모니터링이 운영 클러스터의 노드 한 대에서 SystemOOM 이벤트가 났다고 알렸다. 4분 뒤에는 같은 노드의 루트 볼륨에서 EBS Burst Balance 가 낮다는 경고가 왔다.

   OOMKilled

   촉발

   메모리 요청과 제한 없이 배포된 fluentd-sumologic 파드가 노드 메모리를 계속 차지해 노드에 SystemOOM 이 났다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트컨테이너 메모리 한도

   기여 요인

   리소스 요청과 한도 미설정초기 신호 무시

   감지

   Blue Matador 의 자체 모니터링이 노드의 SystemOOM 이벤트 알림과 EBS Burst Balance 가 낮아졌다는 경고를 보냈다. 원인 파드는 Datadog 의 메모리 사용량 그래프에서 찾았다.

   조치

   • 모든 sumologic 파드를 재시작해, 파드들이 메모리를 적게 쓰는 상태에서 다시 출발하게 했다.
   • fluentd-sumologic 파드 스펙에 환경 변수 RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR 를 "0.9" 로 넣어 배포했다.
   • fluentd-sumologic 에 메모리 요청 128Mi, 메모리 제한 1024Mi, CPU 요청 100m, CPU 제한 250m 을 지정했다.

   후속 조치

   • 기본 리소스 제한과 리소스 쿼터를 함께 써서 모든 파드가 요청과 제한을 갖게 하는 작업을 백로그에 올렸다.

   교훈

   재시작된 파드를 확인할 때는 모든 네임스페이스를 본다. 이번에는 fluentd-sumologic 파드가 별도 네임스페이스에 있어 첫날 원인을 놓쳤다. 모든 파드, 특히 서드파티 애플리케이션에는 리소스 요청과 제한을 지정한다. 제한이 있으면 메모리 문제를 고치지는 못해도 그 문제가 해당 파드들 밖으로 번지지 않게 막을 수 있다. 보이는 문제는 증거가 남아 있을 때 근본 원인까지 파고든다. 이번에는 디스크 IO 가 늘어난 이유를 확인할 로그가 사라진 뒤였다.

   사례 보기
3. IL-0011 HAProxy 인그레스 템플릿이 백엔드 파드를 IP 순으로 정렬해 일부 파드에 요청이 몰리고 인그레스 컨테이너가 OOMKilled 됐다

   Skyscanner2019

   증상

   어느 일요일, 클러스터 사용자 한 명이 지연 시간이 올라갔다며 쿠버네티스 업무 시간 외 지원 담당을 직접 호출했다. 특히 p90 과 최댓값 지연이 높았다.

   지연 시간 증가부하 불균형OOMKilled간헐적 연결 실패

   촉발

   HAProxy 인그레스 컨트롤러를 v0.6 으로 올렸다. v0.5 문서는 sort-backends 플래그의 기본값이 false 이고 백엔드 서버를 기본으로 무작위로 섞는다고 설명했다. 그러나 템플릿이 pod_ip:port 를 키로 하는 맵을 순회할 때 Go 의 text/template 이 키 순서대로 방문해, 파드는 늘 IP 오름차순으로 설정 파일에 들어갔다. 운영 클러스터처럼 변화가 잦은 곳에서는 설정이 자주 다시 쓰였고, HAProxy 가 무중단 리로드를 하지 못해 재시작하는 일이 잦았다. 그때마다 모든 HAProxy 인스턴스가 같은 목록의 처음부터 라운드 로빈을 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러HAProxy설정 템플릿

   기여 요인

   스테이징 불일치미검증 가정초기 신호 무시

   감지

   클러스터 사용자가 p90 과 최댓값 지연이 오른 것을 보고 업무 시간 외 쿠버네티스 지원 담당을 직접 호출했다. 그 전에도 한 사용자가 파드 사이 요청 분포가 고르지 않다고 알렸지만 팀은 우선순위를 낮게 두었다.

   조치

   • 내부 배포 도구 Slingshot 의 설정을 바꿔, 영향받은 서비스의 매니페스트가 파드 IP 대신 Service VIP 를 쓰게 했다.
   • 컨트롤러가 맵에 넣은 순서를 슬라이스에 보관하고 템플릿이 그 슬라이스를 순회하도록 컨트롤러 코드와 설정 템플릿을 패치했다.
   • 패치를 샌드박스 클러스터에서 테스트한 뒤 운영 클러스터에 배포했다.

   후속 조치

   • 컨트롤러 패치를 운영에서 돌리고, 백엔드 주소는 다시 파드 IP 를 기본으로 쓴다.
   • 업스트림 프로젝트에 GitHub 이슈와 PR 을 올려 문제를 알렸다.
   • 클러스터 컴포넌트를 바꿀 때는 구체적인 동작과 조건을 염두에 두고 테스트한다.

   교훈

   클러스터 컴포넌트를 바꿀 때는 특정 동작과 조건을 염두에 두고 테스트해야 한다. 팀은 백엔드 목록이 정렬되면 hot-podding 이 생긴다는 것을 이미 알았지만, 새 플래그가 기대대로 동작하는지 충분히 테스트하지 않았다. 같은 키워드라도 언어의 한 곳에서 동작하는 방식이 다른 곳에서도 같으리라고 기대하면 안 된다. Go 의 range 와 text/template 의 range 는 맵을 순회하는 순서가 달랐다. 쿠버네티스 클러스터의 작은 컴포넌트 하나만 바꿔도 클러스터 사용자와 고객에게 큰 피해를 줄 수 있다.

   사례 보기

원인별3