사례13건

13건 중 8~12번째

1. IL-0195 200개가 넘는 노드의 고객 클러스터에서 Cilium 파드가 LIST 요청을 한꺼번에 쏟아내 kube-apiserver 가 메모리를 다 쓰고 죽기를 되풀이했다.

   Palark2023

   증상

   어느 평범한 아침, 기술 지원 엔지니어가 전화로 고객 클러스터가 프로덕션 환경까지 포함해 사실상 동작하지 않는다고 알려 왔다. 클러스터에 접속해 보니 kube-apiserver 가 메모리를 전부 써 버린 상태였다.

   컨트롤 플레인 무응답OOMKilled

   촉발

   200개가 넘는 노드에서 Cilium 파드가 쿠버네티스 API 에 LIST 요청을 동시에 대량으로 보냈다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버Cilium

   기여 요인

   기본 설정 방치

   감지

   기술 지원 엔지니어가 전화로 고객 클러스터가 사실상 동작하지 않는다고 알렸다. 요청을 보낸 쪽을 찾을 때는 Grafana 대시보드에서 API 요청 수가 급증한 것을 먼저 보았고, Prometheus 의 apiserver_request_total 을 인스턴스와 리소스별로 묶어 Cilium 네트워크 정책 쪽 LIST 요청을 찾았다. 감사 로그로 실제 요청도 확인했다.

   조치

   • 컨트롤 플레인 노드에 CPU 와 메모리를 두 차례에 걸쳐 더해 CPU 8개, 메모리 16 GB 에서 CPU 16개, 메모리 64 GB 로 늘렸고, 두 번째 증설 뒤 API 가 안정됐다.
   • 고객과 합의한 시험 시간에 cilium-agent 를 재시작해 API 서버가 하나씩 메모리를 다 쓰고 죽는 흐름을 확인했다.
   • d8-cni-cilium 서비스 어카운트의 cilium.io list 요청을 묶는 cilium-pods FlowSchema 와, 이 요청의 동시 처리 수를 제한하는 cilium-pods PriorityLevelConfiguration 을 만들어 클러스터에 배포했다.
   • cilium-agent 를 재시작해도 메모리 사용량이 크게 변하지 않는 것을 확인한 뒤 컨트롤 플레인 노드 자원을 원래 크기로 줄였다.

   후속 조치

   • API 요청을 제한해야 했던 일을 여러 번 겪은 뒤, API Priority and Fairness 설정을 Palark 쿠버네티스 플랫폼의 기본 구성으로 넣었다.

   교훈

   특정 클라이언트의 요청을 API Priority and Fairness 의 별도 우선순위 수준에 묶어 두면, 그 클라이언트가 요청을 쏟아내도 사용자 요청이 밀리지 않고 API 서버도 버틴다. API 서버 전체의 동시 처리 한도는 --max-requests-inflight 기본값 400 과 --max-mutating-requests-inflight 기본값 200 을 더한 값이다. API 서버는 이 한도를 각 우선순위 수준의 assuredConcurrencyShares 비율대로 나누므로, 한 수준의 값을 올리면 다른 수준의 한도는 줄어든다. 로그 보기나 exec 같은 오래 걸리는 요청과 WATCH 요청은 이 한도에 걸리지 않는다. 큐 개수, queueLengthLimit, handSize 는 요청이 너무 느려지지 않으면서 갑작스러운 폭증에도 API 서버가 넘치지 않도록 실험으로 정해야 한다. 지켜볼 지표로는 apiserver_flowcontrol_rejected_requests_total, apiserver_current_inqueue_requests, apiserver_flowcontrol_request_execution_seconds 가 있다. Palark 는 이런 일을 이번 말고도 여러 번 겪었다.

   사례 보기
2. IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.

   GitLab2022

   증상

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. Apdex 는 목표 시간 안에 끝난 작업의 비율로 만족도를 나타내는 지표다. 사용자는 사이트가 간헐적으로 느려지는 것을 겪었고, 파이프라인 생성이나 가져오기와 내보내기 같은 비동기 작업이 평소보다 오래 걸렸다.

   지연 시간 증가데이터베이스 과부하OOMKilled오류율 상승

   촉발

   GKE 파드 안의 Consul 에이전트가 특정 상황에서 메모리를 갑자기 많이 요구했고, 쓸 수 있는 메모리가 없어 Consul 프로세스가 죽었다. 당시 파드 메모리 한도는 500MB 였다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도서비스 디스커버리애플리케이션 데이터베이스

   기여 요인

   –

   감지

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. 다음 날 01:21 UTC 에는 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다.

   조치

   • 16:13 에 gitlab 데이터베이스 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용해 17:47 에 적용을 확인했다.
   • 임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올려 Consul 에이전트가 메모리 급증 때도 계속 돌 수 있게 했다.

   후속 조치

   • 메모리 한도를 1GB 로 올린 것으로 충분한지 GKE 파드의 Consul 에이전트를 지켜본다.
   • Consul 의 메모리 수요 급증을 조사해 하드 메모리 한도를 올리는 것 말고 개선할 방법이 있는지 찾는다.

   교훈

   파드 안에서 함께 도는 Consul 에이전트의 메모리 한도가 모자라자 서비스 디스커버리가 끊겼고, 그 영향이 데이터베이스 primary 포화와 사이트 전체의 지연으로 번졌다. 처음 의심한 pgbouncer 풀 변경과 다음 날 별개로 보였던 오류율 상승이 모두 같은 원인으로 이어졌다. 메모리 한도를 올린 것은 임시 조치였고, Consul 의 메모리 급증이 정상 동작인지 GitLab 설정 탓인지는 아직 조사해야 했다.

   사례 보기
3. IL-0176 시계열 급증으로 호스트 메모리가 바닥나자 oom_score_adj 999 를 받은 Prometheus 컨테이너가 커널 OOM Killer 에게 먼저 죽어 CrashLoopBackOff 에 빠졌다.

   LINE2020

   증상

   어느 월요일 아침, 엔지니어가 쿠버네티스 클러스터 경고를 보려고 Prometheus 대시보드를 열었는데 접속되지 않았다. Prometheus 서버 파드는 CrashLoopBackOff 상태였다.

   컨테이너 재시작 반복OOMKilled모니터링 중단프로브 실패

   촉발

   Prometheus 가 시작한 지 5분 만에 시계열 수가 2,162,256 까지 급증해 메모리 8GB 호스트의 메모리를 거의 다 썼다.

   원인

   용량 한계

   구성 요소

   Prometheuskubelet리눅스 커널

   기여 요인

   리소스 요청과 한도 미설정용량 계획 부재

   감지

   월요일 아침 엔지니어가 클러스터 경고를 확인하려고 Prometheus 대시보드를 열었다가 접속되지 않는 것을 보고 알았다.

   조치

   • Prometheus configMap 에서 불필요한 설정 대부분을 지워 컨테이너가 더 이상 비정상 종료되지 않게 했다.

   후속 조치

   • Prometheus 파드의 requests 와 limits 를 알맞게 고친다. 지금 문제를 완전히 풀지는 못해도 비슷한 문제를 막아 해결 시간을 줄인다.
   • 불필요한 수집 지표를 줄이도록 수집 대상이나 수집 간격을 조정한다.
   • Prometheus 에 필요한 메모리를 예측해 새 호스트를 마련하고 deploy-topology: Prometheus 같은 노드 레이블을 붙인 뒤, 매니페스트에 nodeSelector 를 넣어 Prometheus 파드가 그 호스트에만 배치되게 한다.

   교훈

   원인은 둘이었다. 첫째, Prometheus 파드의 requests 와 limits 를 잘못 잡아 Prometheus 서버 컨테이너가 높은 oom_score_adj 를 받았다. 둘째, 대규모 클러스터에서 Prometheus 가 쓸 메모리를 미리 예측하지 않았다. 쿠버네티스에서 파드의 QoS 클래스는 메모리가 모자랄 때 어느 컨테이너가 먼저 죽는지에 영향을 준다. 커널의 OOM Killer 는 메모리 사용량과 oom_score_adj 로 점수를 매기고, kubelet 은 QoS 클래스에 따라 oom_score_adj 를 정한다.

   사례 보기
4. 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 가 늘어난 이유를 확인할 로그가 사라진 뒤였다.

   사례 보기
5. IL-0001 CoreDNS 파드가 메모리 한도 100Mi 에 걸려 OOM 으로 계속 죽으면서 쿠버네티스 클러스터 전체의 DNS 가 멈췄다

   Zalando2019

   증상

   Zalando Fashion Store 의 모든 웹 상품 페이지와 코디 페이지가 한 시간 넘게 고객에게 오류를 많이 냈다. 오류는 쿠버네티스 클러스터 하나에서 도는 핵심 데이터 집계 계층 서비스에서 나왔다.

   오류율 상승DNS 조회 실패OOMKilled모니터링 중단

   촉발

   그리 중요하지 않은 하위 서비스 하나로 가는 호출이 타임아웃 나기 시작했다. 집계 계층이 이 호출에 404 로 응답하자 클라이언트가 재시도했고, 집계 계층으로 가는 요청과 그만큼의 DNS 쿼리가 갑자기 치솟았다.

   원인

   용량 한계

   구성 요소

   CoreDNS컨테이너 메모리 한도클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   한계 미인지캐시 부재재시도 폭주기본 설정 방치과도한 영향 범위모니터링 사각지대

   감지

   DNS 장애로 클러스터 내부 모니터링이 함께 멈춰 당직 호출이 자동으로 가지 않았다. 집계 계층 서비스 당직 엔지니어가 평소처럼 자동 호출에 기대지 못하고 쿠버네티스 담당 당직 엔지니어에게 직접 전화했다. 그래서 쿠버네티스 당직 엔지니어가 장애를 알기까지 예상보다 오래 걸렸다. 연락을 받은 엔지니어가 CoreDNS 파드가 OOM 으로 죽고 있는 것을 찾아냈다.

   조치

   • 쿠버네티스 당직 엔지니어가 CoreDNS 파드의 메모리 request 와 limit 을 100Mi 에서 2000Mi 로 직접 올렸다.

   후속 조치

   • 노드마다 dnsmasq 를 앞에 둔 CoreDNS 를 띄우는 방식으로 더 튼튼한 DNS 구성을 도입한다. 검토하고 시험한 다른 어떤 구성보다 이 방식의 성능이 좋았다.
   • 클러스터 바깥에서 클러스터 전체 상태를 보는 알림을 강화한다. 팀은 클러스터 안 애플리케이션이 영향을 받기 전에, 늦어도 같은 시점에는 클러스터 이상을 알아야 한다.
   • 장애 대응 절차와 도구를 개선한다. 자동 당직 호출이 실패해도 당직 엔지니어가 다른 도구로 옮겨 가지 않고 다른 팀에 바로 에스컬레이션할 수 있게 한다. 채팅 봇으로 에스컬레이션을 단순하게 만드는 방안을 추진하고 있다.

   교훈

   쿠버네티스 DNS 구성은 충분히 튼튼하지 않았다. 애플리케이션 하나가 DNS 를 사실상 서비스 거부 공격하듯 몰아붙여 클러스터 전체를 멈추게 할 수 있어서는 안 된다. DNS 쿼리를 늘린 애플리케이션의 영향 범위는 적어도 노드 하나, 가능하면 파드 하나 안에 갇혀야 한다. 팀은 conntrack 을 처리하는 리눅스 커널의 경쟁 상태나 ndots 5 문제 같은 쿠버네티스 DNS 문제를 대부분 알고 있었고, 일부는 완화책도 갖고 있었다. 하지만 이 문제들이 DNS 구성에 얼마나 크게 영향을 주는지는 제대로 알지 못했다. 모니터링도 충분히 튼튼하지 않았다. 일부 알림은 클러스터 밖에서 돌았지만 대부분은 클러스터 안에서 돌았다. 그래서 DNS 가 무너졌을 때 당직 엔지니어가 자동으로 호출되지 않았고 복구 시간이 필요 이상으로 길어졌다.

   사례 보기

원인별1