사례19건

19건 중 2~6번째

1. IL-0020 EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 한꺼번에 쫓아내 운영 서비스가 멈췄다

   UK Ministry of Justice2025

   증상

   2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.

   파드 축출파드 Pending서비스 중단업그레이드 정체

   촉발

   EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.

   원인

   배포 결함

   구성 요소

   디스케줄러노드 풀클러스터 오토스케일러

   기여 요인

   여유 용량 부재한계 경보 부재기본 설정 방치

   감지

   팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.

   조치

   • cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
   • 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
   • 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
   • 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.

   후속 조치

   • AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
   • 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
   • 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
   • 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
   • 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
   • Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.

   교훈

   이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.

   사례 보기
2. IL-0007 EKS 클러스터에서 VPC-CNI 가 파드마다 VPC IP 를 쓰다가 서브넷 IP 가 바닥나 파드가 IP 를 받지 못했다

   Adevinta2024

   증상

   어느 저녁 일부 DaemonSet 이 실패하고 있다는 호출이 왔다. 당직자가 서버에 들어가 파드 상태를 보니 다음 오류가 찍혀 있었다: name=“aws-cni” failed (add): add cmd: failed to assign an IP address to container

   IP 주소 고갈파드 Pending

   촉발

   첫 호출의 계기는 원문에 나오지 않는다. 호출은 6월, kube-aws 기반 SCHIP 에서 EKS 기반 클러스터로 옮기던 중에 왔다. 원문은 클러스터의 IP 가 바닥나는 경우로, 잡이 폭주하거나 실패하면서도 회수될 때까지 IP 를 붙잡고 있어 파드가 갑자기 늘어나는 경우를 든다.

   원인

   용량 한계

   구성 요소

   AWS VPC CNIVPC 서브넷 또는 파드 주소 범위Karpenter

   기여 요인

   기본 설정 방치용량 계획 부재

   감지

   어느 저녁 일부 DaemonSet 이 실패한다는 호출이 왔다. 당직자가 서버에 들어가 파드 상태를 확인하다 aws-cni 의 IP 할당 실패 오류를 보았다. 팀은 그전부터 IP 사용량을 감시하고 있었다.

   조치

   • 8월 말부터 작은 클러스터에 Secondary CIDR 를 쓰는 VPC-CNI 커스텀 네트워킹을 배포했다.
   • 9월에 사용 가능한 IP 가 너무 적어지자 EKS 이전을 잠시 멈췄다.
   • 커스텀 네트워킹을 나머지 클러스터 전체에 배포했다.
   • Karpenter 배포에 --reserved-enis 파라미터를 더했다.

   후속 조치

   • 커스텀 네트워킹을 나머지 클러스터 전체에 배포해 IP 여유를 되찾고 EKS 이전을 끝냈다.
   • Karpenter 배포에 --reserved-enis 파라미터를 더해 커스텀 네트워킹이 쓰는 첫 번째 ENI 를 빼고 노드당 파드 수를 계산하게 했다.

   교훈

   플랫폼 팀이나 클러스터 운영자가 용량 계획에 시간을 들이지 않으면, VPC-CNI 는 큰 규모의 운영 환경에 바로 쓸 수 있는 도구가 아니다. 선택지마다 장단점이 있다. 지금 큰 클러스터를 새로 띄운다면 더 싸고 앞으로도 오래 쓸 수 있는 IPv6 를 쓸 수 있는지 먼저 확인할 만하다. 작은 클러스터에서 되던 것이 규모를 키워도 된다고 가정하면 안 된다. 예측과 용량 계획을 잘하면 이 요구는 감당할 수 있다. 하지만 폭주하는 잡이나, 실패하면서도 회수될 때까지 IP 를 붙잡는 잡을 여럿 띄우는 잘못된 설정 때문에 파드가 갑자기 늘 수 있다.

   사례 보기
3. IL-0148 클러스터에 없는 노드를 가리키는 노드 어피니티를 가진 파드 하나 때문에 kube-scheduler 가 패닉에 빠져 AKS 클러스터에서 파드가 하나도 스케줄되지 않았다

   Microsoft Azure2024

   증상

   Kubernetes v1.27.14, v1.28.10, v1.29.5 를 쓰는 AKS 클러스터에서 kube-scheduler 가 패닉에 빠졌다. 그 뒤로 클러스터의 어떤 파드도 스케줄되지 않았다.

   파드 Pending

   촉발

   클러스터에 없는 노드를 가리키는 노드 어피니티를 가진 파드가 생겼다.

   원인

   소프트웨어 결함

   구성 요소

   파드 스케줄링과 배치

   기여 요인

   –

   감지

   AKS 팀이 직접 버그를 찾았고, 2024년 7월 24일 Azure/AKS 깃허브 이슈로 고객에게 알렸다.

   조치

   • Azure Kubernetes Service 엔지니어들이 영향을 받은 클러스터를 모두 고쳤다.
   • 고친 kube-scheduler 를 모든 리전에 배포해 고객 클러스터에 자동으로 적용했다.

   사례 보기
4. IL-0114 클러스터 용량을 늘리던 중 버전이 고정되지 않은 VPC CNI 플러그인이 자동으로 업데이트돼 새 파드가 IP 를 받지 못하고 Pending 에 머물렀고, 메인넷 운영 환경의 정산이 약 3.5시간 멈췄다.

   CoW Protocol2024

   증상

   2024년 4월 19일 16:40 UTC 에 메인넷 운영 환경에서 정산이 멈췄다. 핵심 서비스가 내려가 있었다.

   파드 PendingIP 주소 고갈파드 축출서비스 중단

   촉발

   클러스터 용량을 늘리는 IaC 자동화가 돌면서, IaC 에 버전이 고정되지 않은 VPC CNI 플러그인이 자동으로 업데이트됐다.

   원인

   설정 변경

   구성 요소

   AWS VPC CNI노드 풀

   기여 요인

   버전 미고정장애 중첩

   감지

   장애는 16:40 UTC 에 정산이 멈추면서 시작됐다. 팀은 23분 뒤인 17:03 UTC 에 CNI 버전 불일치를 원인으로 짚었다.

   조치

   • 19:00 UTC 쯤 쿠버네티스 클러스터 업그레이드를 시작했다.
   • 새 버전의 네트워크 플러그인을 쓰는 노드 그룹을 새로 만들었다.

   교훈

   IaC 스크립트에 버전을 명시해야 의도치 않은 업데이트를 막을 수 있다. 운영 환경일수록 쉽게 되돌릴 수 있는 변경 관리가 필요하다.

   사례 보기
5. IL-0231 EKS 클러스터의 워커 노드가 모두 꺼지고 새 노드가 뜨지 않아 Stytch API 가 14분 동안 완전히 멈췄다

   Stytch2023

   증상

   2023-02-23 20:48 UTC 에 운영 환경에서 Deployment Replicas Unavailable 알림이 울리기 시작했다. 21:10 UTC 에 운영 Live API 와 Test API 가 내려가 Stytch API 호출이 모두 5XX 를 냈고, 21:17 UTC 에는 Dashboard 와 SDK 도 내려갔다.

   노드 NotReady노드 증설 실패파드 축출파드 Pending서비스 중단

   촉발

   14:21 UTC 에 팀은 쓰지 않는 관리형 노드 그룹을 지우는 변경을 반영했고, 두 엔지니어가 AWS 콘솔에서 스테이징과 운영의 노드 그룹을 지웠다. 노드 그룹을 지우자 AWS 가 뒤에서 그 노드 그룹과 엮인 리소스를 정리하면서 Karpenter 노드도 쓰던 instance profile 을 지웠다.

   원인

   설정 변경

   구성 요소

   Karpenter노드 풀설정 템플릿

   기여 요인

   미검증 가정공용 자격 증명늦게 드러난 변경초기 신호 무시

   감지

   운영에서는 20:48 UTC 에 Deployment Replicas Unavailable 알림이 울렸고, 21:14 UTC 에 지원팀이 장애를 알렸다. 그보다 앞서 16:06 UTC 에 스테이징, 17:48 UTC 에 운영에서 Karpenter 가 instance profile 을 찾지 못한다는 낮은 긴급도 경고가 왔지만 급하지 않은 문제로 분류되었다. 20:26 UTC 에 Karpenter 오류율이 치솟자 팀은 장애 대응을 시작했다.

   조치

   • 노드 그룹 삭제를 되돌려 노드 그룹을 다시 만들었다. 새 파드는 새 노드가 뜨기를 기다려야 해서 충분히 빨리 스케줄되지 않았다.
   • Live API 노드 그룹 하나를 컴퓨팅 크기가 훨씬 큰 노드로 손으로 늘리고, 그 노드 그룹에서 taint 를 지웠다.
   • 애플리케이션의 node selector 를 차례로 지워 파드가 그 노드에 스케줄되게 했다. 몇 분 안에 애플리케이션마다 필요한 수의 노드에 파드가 스케줄되었다.

   후속 조치

   • Karpenter 오류의 심각도를 올려 당직 호출기로 바로 가는 높은 긴급도 알림으로 다룬다.
   • 클러스터 알림의 임계값을 조정해 높은 긴급도 호출이 더 일찍 가게 한다.
   • 노드가 오랫동안 NotReady 나 Unknown 으로 표시되면 알림을 보내 기존 노드의 상태를 더 잘 지켜본다.
   • 스케줄할 수 없는 파드, 사용할 수 없는 레플리카를 비롯한 다른 배포 관련 알림의 임계값을 올린다.
   • Karpenter 가 쓰는 IAM instance profile 을 노드 그룹이 쓰는 IAM profile 과 다른 것으로 바꾼다.
   • 여러 용도로 겹쳐 쓰던 다른 AWS 리소스, 특히 IAM 과 보안 그룹을 나눈다.
   • EKS 와 Karpenter 설정을 크게 고쳐 복잡도를 줄인다. 새 시스템 instance profile 은 Karpenter 가 클러스터마다 고유하고 고정된 이름으로 만들게 한다.
   • 개발팀이 인프라를 바꿀 때 쓸 수 있도록 클라우드 시각화 도구를 들인다.
   • 상태 페이지에 실시간 시스템 지표와 제품 지표를 넣어 Stytch API 가 지금 어떻게 동작하는지 보여 준다.
   • 문서에 없는 동작과 부작용을 AWS 에 문의해 확인한다.
   • 인프라에서 IAM 역할과 보안 그룹을 여러 용도로 겹쳐 쓰던 것을 바로잡는다.

   교훈

   Karpenter 의 자체 관리 노드에 노드 그룹과 같은 IAM 역할을 쓰지 말았어야 했다. 한 IAM 역할을 여러 용도로 겹쳐 쓰면 이번 같은 문제가 그대로 난다. 팀은 Karpenter 를 처음 설정할 때 빠르고 단순하게 하려다 역할을 나누지 않았다. 원인과 결과 사이가 몇 시간 벌어져 있어 장애 전체를 판단하기 어려웠다. AWS 는 이 지연이 예상된 동작이라고 확인했고, 팀은 앞으로 IAM instance profile 을 바꿀 때 이를 고려한다.

   사례 보기

원인별6