사례8건

8건 중 3~7번째

1. IL-0118 쿠버네티스 네임스페이스 라벨을 전역으로 바꾸자 네트워크 계층이 메타데이터를 다시 계산하면서 가장 큰 GPU 클러스터들 가운데 세 곳의 컨트롤 플레인이 과부하에 빠졌고, ChatGPT 와 API 가 타임아웃과 503 오류를 냈다.

   OpenAI2024

   증상

   2024년 11월 25일 태평양 시각 오전 10시 15분부터 API 와 ChatGPT 트래픽의 상당 부분이 타임아웃과 503 오류로 실패했다.

   오류율 상승지연 시간 증가컨트롤 플레인 무응답

   촉발

   쿠버네티스 네임스페이스 라벨을 전역으로 바꿨고, 이 변경 때문에 네트워크 계층이 의도치 않게 메타데이터를 다시 계산했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   과도한 영향 범위디버그 접근 제한

   조치

   • 영향받은 클러스터에서 워크로드를 손으로 빼냈다. 컨트롤 플레인이 응답하지 않아 이 작업이 더 복잡했다.
   • 클라우드 업체와 함께 컨트롤 플레인 노드 수를 늘리고 동시에 데이터 플레인 노드 수를 줄여 컨트롤 플레인을 회복시켰다.

   후속 조치

   • 같은 장애가 다시 나지 않도록 네임스페이스 변경을 잠갔다.
   • 일부 종류의 인프라 배포를 동결했다.
   • 같은 종류의 장애가 반복되지 않도록 신원을 허용 목록으로 관리한다.
   • 가능한 경우에는 트래픽이 자동으로 다른 곳으로 더 잘 옮겨 가도록 GPU 로드 밸런싱 로직을 고친다.
   • 플릿 전체에 걸친 인프라 변경을 관리하는 방식을 개선한다.

   사례 보기
2. IL-0060 쿠버네티스 1.24 업그레이드로 node-role.kubernetes.io/master 레이블이 사라지자 이 레이블에 기대던 Calico 라우트 리플렉터가 동작을 멈춰 레거시 클러스터의 네트워크가 모두 끊기고 Reddit 이 314분 동안 멈췄다

   Reddit2023

   증상

   2023년 3월 14일 19시 UTC 직후 엔지니어가 Old Reddit 이라 불리는 레거시 스택을 돌리는 클러스터의 업그레이드를 시작했다. 2분쯤은 괜찮아 보였지만 곧 사이트 전체가 갑자기 멈췄다. CDN 엣지의 상태 코드별 RPS 그래프가 이를 보여 주었다. 사용자는 오류 페이지나 글이 하나도 없는 홈페이지를 보았다.

   서비스 중단오류율 상승DNS 조회 실패모니터링 중단파드 ContainerCreating 정체컨트롤 플레인 지연

   촉발

   Reddit 에서 가장 중요한 클러스터 가운데 하나인 레거시 클러스터를 쿠버네티스 1.23 에서 1.24 로 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   Calico쿠버네티스 API 서버어드미션 웹훅etcd

   기여 요인

   코드로 관리되지 않는 설정스테이징 불일치미검증 백업모니터링 사각지대단일 장애점

   감지

   업그레이드를 시작하고 2분쯤 뒤 CDN 엣지의 상태 코드별 RPS 그래프에서 사이트가 멈춘 것이 보였다. 팀은 곧바로 장애를 선언했고 3분 안에 대응 인원이 통화에 모였다. 엣지 지표는 일부러 클러스터와 분리되어 있어 살아 있었지만, 클러스터 자체의 지표는 모두 사라졌다.

   조치

   • API 서버에서 타임아웃을 내던 Open Policy Agent 의 웹훅 설정을 지웠다.
   • 복원 뒤 어차피 쓸 수 없게 될 워커 노드를 모두 종료했다.
   • 컨트롤 플레인 노드 두 대를 종료하고, 남은 한 대의 구성 요소를 다운그레이드한 뒤 그 노드에 백업 데이터를 복원했다.
   • 단일 노드 컨트롤 플레인이 부하에 무너지지 않도록 클러스터 오토스케일러를 껐다.
   • 새 컨트롤 플레인 노드를 띄우고, 호스트명이 맞지 않던 TLS 인증서를 새로 만들어 노드들을 합류시켰다.
   • 트래픽을 1% 에서 시작해 5%, 10%, 20%, 35%, 55%, 80%, 100% 로 조금씩 늘렸다.
   • 트래픽이 돌아올 때 문제를 일으키지 않도록 손으로 멈춰 두었던 민감한 레거시 서비스를 조심스럽게 다시 켰다.

   후속 조치

   • 클러스터 구성을 코드로 관리해 모든 선택에 기록이 남게 하고, 코드로 만들 수 없는 것은 자세히 문서로 남긴다.
   • 클러스터마다 다른 맞춤형 구성을 걷어 내고 모든 클러스터의 구성 요소를 표준화한다.
   • 모든 클러스터를 최대한 같은 모습으로 유지하고 필요하면 다시 만들거나 복제할 수 있도록 클러스터 전체의 수명 주기를 관리하는 도구를 만든다.
   • 믿고 테스트에 쓸 수 있는 프리프로덕션 클러스터를 더 둔다.
   • 백업 복원 절차를 개선하고 클러스터 업그레이드를 안전하게 만든다.

   교훈

   쿠버네티스 버전과 구성 요소 업그레이드는 여전히 위험하다. 미리 테스트하고 검증해도 이번처럼 처음 보는 방식으로 깨질 수 있다. 쿠버네티스에는 공식 다운그레이드 절차가 없어, 롤백하는 방법은 백업에서 복원하는 것뿐이다. 복원 절차가 환경 변화를 따라가지 못하면 실제 장애 때 그 자리에서 고쳐 써야 하고, 복원을 결정하기까지 오래 망설이게 된다. 이번 복원은 결국 성공했지만 절차는 개선해야 한다. 코드로 남기지 않은 설정은 아는 사람이 떠나면 아무 기록도 남지 않는다. 라우트 리플렉터 설정이 어디에도 커밋되어 있지 않아 장애 중에 누구도 의심하지 못했다. 지표가 클러스터 안에서만 수집되면 클러스터가 망가질 때 함께 사라진다. 이번에는 로그 수집 에이전트가 영향을 받지 않아 원인을 추적할 수 있었다. 클러스터마다 다른 맞춤형 구성이 쌓이면 장애가 잦아진다. 직접 원인은 노드 레이블이었지만 근본 원인은 일관성 부족이었다.

   사례 보기
3. IL-0002 빌더 파드가 노드 한 대에 몰리자 kubelet 이 기본 API QPS 한도에 막혀 파드 상태를 늦게 갱신했고, CI 빌드가 AWS IAM 자격 증명을 받지 못해 실패했다

   Zalando2019

   증상

   2019년 6월 11일, Zalando 가 직접 만들어 운영하는 CI/CD 플랫폼인 CDP 의 빌드가 한 시간 가까이 타임아웃으로 실패했다.

   오류율 상승자격 증명 획득 실패컨트롤 플레인 지연

   촉발

   CDP 쿠버네티스 클러스터의 규모가 조정되면서 공교롭게도 빌더 파드가 쓸 수 있는 노드가 한 대만 남았다. 그 노드에서 파드가 빠르게 생성되고 삭제되자 kubelet 이 따라가지 못했다.

   원인

   용량 한계

   구성 요소

   kubelet파드용 자격 증명 중개자쿠버네티스 API 서버CI 시스템

   기여 요인

   기본 설정 방치단일 장애점

   조치

   • 클러스터를 수동으로 늘려 빌더 파드가 노드 한 대가 아니라 여러 대에 흩어지게 했다.

   후속 조치

   • 전역 클러스터 설정으로 kubelet QPS 를 기본값 5 에서 50 으로 올렸다.

   사례 보기
4. IL-0075 클러스터가 EC2 인스턴스 약 290대로 커지자 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하면서 API 서버가 CPU 와 메모리를 다 써 쿠버네티스 컨트롤 플레인을 쓸 수 없게 됐다.

   Civis Analytics2019

   증상

   스크립트 실행 기반을 쿠버네티스로 옮긴 Croquet 를 사내에 공개한 뒤, 개발자들은 kubectl 명령이 느리다고 했다. 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다.

   컨트롤 플레인 지연컨트롤 플레인 무응답지연 시간 증가오류율 상승DNS 조회 실패

   촉발

   자체 인프라 Bocce 에서 쿠버네티스로 옮긴 스크립트 실행 기반 Croquet 를 2018년 9월 사내에 공개했다. 대량의 스크립트가 몰리면서 클러스터가 EC2 인스턴스 약 290대로 커졌고, 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하는 부하도 함께 늘었다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버텔레메트리 에이전트etcd

   기여 요인

   한계 미인지미검증 가정모니터링 사각지대용량 계획 부재

   감지

   개발자들이 kubectl 명령이 느리다고 했고, 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다. 마스터 노드의 CPU 사용률이 높았고, 조사해 보니 API 서버 컨테이너 세 개가 CPU 를 꽉 채워 쓰고 있었다. 당시 팀이 볼 수 있던 지표는 마스터 노드 CPU 의 CloudWatch 지표와 Datadog 의 컨테이너별 CPU, 메모리 지표였다. API 요청 처리량과 5xx 오류율과 요청 지연은 볼 수 없었다.

   조치

   • 사내 사용자들을 예전 인프라로 되돌려 클러스터를 안정시켰다.
   • 마스터 노드를 m4.large 세 대에서 m4.4xlarge 세 대로 키웠다.
   • 노드마다 도는 Datadog 에이전트가 서비스 메타데이터를 얻으려고 API 서버를 폴링하지 않도록 Datadog 설정을 바꿨다.
   • 상태를 바꾸지 않는 요청의 max-requests-inflight 한도를 400 에서 1200 으로 올렸다.
   • etcd 의 EBS 볼륨을 20 GB 에서 100 GB 로 늘려 IOPS 를 100 에서 300 으로 올렸다.
   • 스크립트의 DNS 정책을 ClusterFirst 에서 Default 로 바꿔 DNS 타임아웃을 줄였다.

   후속 조치

   • Kops 가 안전한 이전을 지원하면 etcd 를 2.2.1 에서 3.x 로 올린다.
   • 스크립트가 클러스터 안의 다른 워크로드와 통신할 수 있도록 DNS 타임아웃 문제를 근본적으로 해결한다.

   교훈

   가장 큰 실수는 쿠버네티스가 모든 것을 알아서 해 준다고 가정한 것이었다. 쿠버네티스는 노드 5,000대와 파드 100,000개를 지원한다고 하지만, 그 규모에 이르려면 손봐야 할 설정이 많다. 클러스터에 넣는 서드파티 도구, 특히 DaemonSet 을 조심해야 한다. 많은 도구가 보통 규모에 맞춰 만들어졌고 큰 규모에서는 시험되지 않았다. 클러스터 상태를 watch 하는 서비스가 데이터를 지나치게 많이 가져가도록 설계되면 규모 문제가 생긴다. kube2iam 은 모든 파드의 메타데이터를 메모리에 들고 있다가 메모리가 바닥났고, Fluentd Kubernetes Metadata Filter 플러그인도 같은 문제가 있다. 대개 설정 하나로 고칠 수 있지만, 부하 테스트를 해 보기 전에는 잘 드러나지 않는다.

   사례 보기
5. IL-0031 API 서버가 OOMKill로 죽자 Skipper 인그레스가 라우트를 잃었고, 고객 트래픽이 끊기며 IAM 서비스에서 404 오류가 났다

   Zalando2018

   증상

   고객에게 영향이 간 장애였다. IAM 서비스에서 404 오류가 나기 시작했다.

   오류율 상승컨트롤 플레인 무응답OOMKilled

   촉발

   발표는 문제의 출발점으로 CronJob 매니페스트 하나를 보여 주었다. 이 매니페스트에는 concurrencyPolicy, successfulJobsHistoryLimit, failedJobsHistoryLimit 필드가 CronJob spec이 아니라 파드 템플릿 spec 안에 들어 있었다. 실행 일정은 평일 9시부터 19시까지 15분마다였다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버인그레스 컨트롤러

   기여 요인

   단일 장애점과도한 영향 범위

   조치

   • CronJob 매니페스트를 고쳤다. concurrencyPolicy와 이력 보존 개수 필드를 CronJob spec으로 옮기고, Job에 activeDeadlineSeconds: 120을 넣고, 실행 일정을 바꿨다.

   후속 조치

   • API 서버에 문제가 생겨도 인그레스가 healthy 상태를 유지하도록 고친다.
   • API 서버가 응답하지 않아도 인그레스가 마지막으로 받은 라우트 목록을 계속 쓰도록 고친다.
   • ResourceQuota로 파드 수 상한을 1500개로 둔다.

   교훈

   ALB는 등록된 호스트가 모두 unhealthy를 보고하면 모든 호스트로 트래픽을 보낸다. 인그레스는 API 서버에 문제가 생겨도 healthy 상태를 유지해야 하고, 마지막으로 받은 라우트 목록을 계속 써야 한다. 파드 수에는 ResourceQuota로 상한을 걸어 둔다.

   사례 보기

원인별4