사례7건

7건 중 1~5번째

1. IL-0021 GKE 의 COS 노드가 NVIDIA GPU 드라이버를 403 Forbidden 으로 받지 못해 새로 만든 GPU 노드를 쓸 수 없었다

   Google Cloud2024

   증상

   2024-03-12 US/Pacific 08:00 부터 GKE 에서 Container-Optimized OS 를 쓰는 GPU 노드가 일부 NVIDIA GPU 드라이버를 받지 못했다. 새로 만들거나 다시 만든 노드는 GPU 드라이버가 작동하지 않았고, 그 드라이버를 쓰는 워크로드가 돌지 못했다.

   GPU 인식 불가노드 NotReady

   원인

   의존성 장애

   구성 요소

   GPU 드라이버노드 운영체제 이미지노드 풀

   기여 요인

   자동화 증폭

   감지

   보고서는 Google 이 장애를 어떻게 알아챘는지 적지 않았다. GKE 사용자는 GPU 노드에서 드라이버를 설치할 때 "Failed to download GPU driver installer, status: 403 Forbidden" 오류를 보고 이 장애를 알아볼 수 있었다.

   조치

   • GPU 드라이버 다운로드를 시도하는 자동 노드 재생성을 멈췄다.
   • 드라이버를 공급하는 파트너와 함께 스토리지 버킷 접근 문제를 해결했다.

   교훈

   상태 페이지 보고서는 교훈이나 후속 조치를 적지 않았다.

   사례 보기
2. IL-0168 새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다.

   Scaleway2024

   증상

   2024년 2월 13일 01:04 CET 에 FR-PAR 리전의 Kubernetes API 에서 RAM 과 CPU 사용량이 치솟아 OOM 이 났다. 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 상태가 됐다.

   노드 NotReady컨트롤 플레인 지연OOMKilled

   촉발

   2월 12일 새 쿠버네티스 릴리스가 모든 사용자에게 나온 뒤, 12일에서 13일로 넘어가는 밤에 많은 클러스터가 동시에 자동 업그레이드를 시작했다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   재시도 폭주자동화 증폭단계적 배포 부재

   감지

   타임라인의 첫 기록은 01:04 CET 다. 이때 Kubernetes API 의 RAM 과 CPU 사용량이 치솟아 OOM 이 났고, 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 가 됐다. 기록된 첫 조치는 42분 뒤인 01:46 에 API 자원을 늘린 일이었다.

   조치

   • Kubernetes API 에 배정한 자원을 01:46 과 02:20 두 차례 늘렸다.
   • 02:30 에 API 트래픽을 제한해 들어오는 트래픽을 고르게 만들고 혼잡을 줄였다.
   • 03:20 부터 트래픽 제한을 50-100 개 배치로 나눠 차례로 풀어 노드들이 다시 인증하고 "Ready" 가 되게 했다.
   • 03:40 에 API 혼잡 중에 만들어진 고장 노드를 교체하는 스크립트를 돌렸다.
   • 15:45 부터 노드 인증이 한꺼번에 몰리지 않게 일부 클러스터부터 예전 인증 방식으로 차례로 롤백했고, 2월 19일 모든 클러스터에서 롤백을 마쳤다.
   • 노드 인증이 동시에 몰릴 수 있는 클러스터 업그레이드와 설정 갱신 기능을 2월 20일 10:30 까지 껐다.

   후속 조치

   • Kubernetes API 자원 배정을 늘렸다.
   • 예전 인증 방식으로 롤백했다.
   • 노드에 로컬 인증 캐시를 둔다.
   • 부하가 치솟을 때 더 잘 버티도록 자원 배정 전략을 다시 짠다.
   • 쿠버네티스에 새 요청 큐잉 방식을 넣는다.
   • 높은 부하나 장애가 다른 구성 요소로 번지지 않게 구성 요소를 서로 분리한다.
   • 몇몇 지표를 꼼꼼히 지켜봐 이상 패턴을 더 일찍 찾는다.
   • 이 기간에 노드를 배포했지만 제대로 쓰지 못한 고객에게 환불한다.

   교훈

   고객의 클러스터와 노드가 빠르게 늘면서 기존 트래픽 제어로는 혼잡을 막기 어려워졌다. 많은 클러스터의 자동 업그레이드가 한 번에 시작되면 Kubernetes API 에 부하가 몰리고, 계속 실패하고 재시도하는 노드 인증 방식이 혼잡을 더 키운다. 1월 24일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.

   사례 보기
3. IL-0198 systemd 보안 패치가 Ubuntu 22.04 노드의 systemd-networkd 를 재시작해 Cilium 이 넣은 IP 규칙을 지웠고, 여러 리전과 세 클라우드의 Kubernetes 노드가 한꺼번에 네트워크를 잃었다.

   Datadog2023

   증상

   2023년 3월 8일 06:00 에서 07:00 UTC 사이에 여러 리전과 여러 클라우드의 Kubernetes 노드가 한꺼번에 네트워크 연결을 잃었다. Datadog 의 모든 서비스가 영향을 받았고, CI/CD 와 자동화 도구가 있는 리전도 함께 끊겼다.

   노드 NotReady서비스 중단처리량 저하

   촉발

   2023년 3월 7일 Ubuntu 저장소에 systemd 의 CVE 패치 249.11-0ubuntu3.7 이 올라왔다. 3월 8일 06:00 에서 07:00 UTC 사이에 Ubuntu 기본값 그대로 둔 무인 업그레이드가 이 패치를 설치했고, systemd-networkd 가 재시작되면서 자신이 모르는 IP 규칙을 모두 지웠다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   systemd-networkdCilium노드 운영체제 이미지

   기여 요인

   기본 설정 방치늦게 드러난 변경단계적 배포 부재자동화 증폭

   조치

   • Google Cloud 와 Azure 에서 네트워크만 잃고 실행 중이던 인스턴스 수천 대를 클라우드 API 로 재시작해 로컬 디스크의 데이터와 함께 복구했다.
   • AWS 에서 교체되면서 로컬 디스크를 잃은 데이터 저장소는 데이터를 다시 만들거나, 다시 처리하거나, 백업에서 복원해 되살렸다.

   교훈

   기본값 그대로 둔 OS 무인 보안 업데이트는 단계적 배포 절차를 거치지 않고 모든 리전과 클라우드에 같은 시각에 변경을 적용한다. systemd-networkd 의 새 동작은 22.04 도입 때부터 있었지만 systemd-networkd 가 재시작될 때만 나타나서 몇 달 동안 보이지 않았다. CNI 가 호스트의 IP 규칙에 기대고 있으면, 그 규칙을 지우는 다른 구성 요소 하나가 노드 네트워크 전체를 끊는다. 클라우드마다 네트워크를 잃은 인스턴스를 다루는 방식이 다르고, 로컬 디스크에 데이터를 두는 서비스에서는 자동 교체가 오히려 복구를 늦춘다.

   사례 보기
4. IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다

   DFDS2022

   증상

   2022-10-31 13:45 UTC 에 팀은 계획된 vpc-cni EKS 애드온 업그레이드를 배포 파이프라인으로 시작했다. 14:10 에 파이프라인이 업그레이드 중 타임아웃으로 실패했다. 45개 aws-node 파드 가운데 약 10개만 업그레이드됐다. 5개는 Terminating 에 멈췄고, 나머지 30개는 업그레이드를 시도하지도 못했다.

   노드 NotReady업그레이드 정체간헐적 타임아웃간헐적 연결 실패

   촉발

   매일 도는 노드 롤오버가 2022-10-31 07:30 UTC 에 가장 최신 EKS 노드 AMI 인 v20221027 을 가져와 기존 노드를 이 AMI 로 만든 새 노드로 바꿨다. 이 AMI 는 나중에 커널 문제로 회수됐다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지리눅스 커널kubeletAWS VPC CNI노드 런치 템플릿Terraform

   기여 요인

   단계적 배포 부재자동화 증폭장애 중첩모니터링 사각지대헬스 프로브 부재

   감지

   07:30 롤오버 뒤 14:10 에 vpc-cni 업그레이드 파이프라인이 타임아웃으로 실패했다. 팀은 롤오버 7시간 뒤인 14:30 에 노드가 NodeNotReady 를 오가는 것을 보고 이상을 알았다. 감지까지 7시간이 걸렸다. 알림은 NodeNotReady 이벤트와 소켓 증가를 잡지 못했다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾고 나서 원인을 알았다.

   조치

   • Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 vpc-cni 업그레이드를 끝냈다. 모두 15대를 지웠다.
   • 특정 AMI 를 지정할 수 있도록 인프라 모듈의 terraform 을 고치고 테스트해 master 브랜치에 머지했다.
   • 파이프라인으로 EC2 Auto Scaling 그룹 launch configuration 의 AMI 를 이전의 정상 버전으로 되돌려 노드를 다시 만들었다.

   후속 조치

   • 각 팀에 readiness, liveness 프로브를 쓰자고 제안한다.
   • readiness, liveness 프로브 적용 현황을 보여 주는 대시보드를 만든다.
   • readiness, liveness 프로브와 그 쓸모를 설명하는 위키 글을 쓴다.
   • 인프라 모듈에서 특정 AMI 를 지정할 수 있게 고친다.
   • 최신 AMI 를 바로 받을지, 새 AMI 를 배포 전에 어떻게 시험할지 논의하는 자리를 잡는다.
   • 비정상적인 NodeNotReady 이벤트나 소켓 사용 증가를 잡는 알림을 만든다.
   • 팀 안에 Kubernetes 학습 과정을 만든다.
   • 노드 로그를 중앙에서 모은다.
   • 나와 있는 최신 AMI 를 조회하는 Prometheus exporter 를 만들고, 이를 쓰는 대시보드와 알림도 만든다.

   교훈

   새 AMI 를 배포한 날에는 다른 컴포넌트 업그레이드를 매우 조심해야 한다. 이번에는 새 노드 AMI 를 쓴 날 EKS 컴포넌트도 함께 올리면서 원인을 가리기 어려웠다. 장애나 문제가 생겼을 때 각 팀과 소통하는 경로도 개선해야 한다. 문제를 알린 팀에게서 자세한 내용을 받기 어려웠고, 팀별 당직 호출 경로도 없었다. 팀이 Kubernetes 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다.

   사례 보기
5. IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.

   Moonlight2019

   증상

   1월 18일 금요일, Moonlight API 가 가끔 오류를 냈다. 처음 오류는 Redis 데이터베이스와 연결이 안 되는 문제로 보였다. Moonlight API 는 인증된 요청마다 Redis 에서 세션을 확인한다.

   오류율 상승간헐적 연결 실패노드 NotReady서비스 중단노드 CPU 고부하

   촉발

   쿠버네티스 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 같은 노드에 배치했다. 이 파드들이 노드 CPU 를 100% 쓰자 노드 VM 이 커널 패닉으로 죽었다.

   원인

   용량 한계

   구성 요소

   파드 스케줄링과 배치리눅스 커널애플리케이션 데이터베이스

   기여 요인

   단일 장애점미검증 가정자동화 증폭

   감지

   API 오류가 가끔 나면서 문제가 드러났다. 쿠버네티스 모니터링이 일부 노드와 파드가 응답하지 않는다고 보고했다. 노드가 CPU 100% 상태에서 커널 패닉으로 죽는다는 패턴은 Google Cloud 지원팀이 찾아냈다.

   조치

   • 주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드에 흩어 놓았다.

   후속 조치

   • Google Cloud 지원팀과 함께 노드 커널 패닉의 근본 원인을 찾아 고친다.

   교훈

   복제본을 세 개 두어도 스케줄러가 한 노드에 몰아 놓으면 그 노드가 단일 장애점이 된다. 사용자에게 응답하는 서비스에는 안티 어피니티 규칙을 넣어 파드를 여러 노드에 나눠 놓아야 한다. 팀은 처음에 클라우드 업체의 네트워크 장애를 원인으로 짐작했지만 실제 원인은 노드의 CPU 포화와 커널 패닉이었다.

   사례 보기

원인별4