사례2건

2건 중 1~2번째

1. IL-0096 GCP europe-west2-b 존의 자원이 바닥나 이 존 하나에 묶인 GKE 노드 풀이 늘어나지 못했고, LIS 허브의 사용자 서버가 6시간 30분 동안 뜨지 않았다.

   2i2c2022

   증상

   2022년 11월 14일 LIS 허브 사용자가 "backoff after failed scale-up" 오류를 보고했다. 사용자 서버가 뜨지 않았고 노드 풀이 늘어나지 않았다.

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

   촉발

   영국 시각 오전 10시에 Google Cloud europe-west2 리전의 B 존에서 할당할 자원이 바닥났다.

   원인

   클라우드 제공자 장애

   구성 요소

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

   기여 요인

   단일 장애점온콜 호출 미전달

   감지

   사용자가 "backoff after failed scale-up" 오류를 보고하면서 장애가 드러났다. 영향은 태평양 시각 02:00 에 시작됐고, 인시던트는 3시간 40분 뒤인 05:40 에 열렸다.

   조치

   • GCP 콘솔에서 해당 노드 풀을 고쳐, 자원이 남아 있던 같은 리전의 A 존과 C 존에도 노드를 만들 수 있게 했다.

   후속 조치

   • 다음 둘 중 하나를 한다. 블랙 프라이데이 행사가 끝나면 노드 풀을 다시 B 존으로만 묶거나, 클러스터와 NFS 를 A 존으로 옮긴다.
   • 리전 단위 NFS 를 쓸 수 있는 엔터프라이즈 요금제를 알아본다. 비용은 더 든다.
   • PagerDuty 알림이 언제나 엔지니어에게 닿도록 한다.

   교훈

   엔지니어 한 명이 인시던트 지휘, 공지, 디버깅을 오랫동안 혼자 맡았다. 팀이 함께 나서서 이 엔지니어를 더 많이 도울 수 있었다. 호출 알림이 대응 엔지니어에게 닿지 않아 이 문제가 더 커졌다. "backoff after failed scale-up" 은 보통 쿼터 문제지만 이번에는 쿼터를 올려도 소용이 없었다. 원인은 로그의 ZONE_RESOURCE_POOL_EXHAUSTED 오류에서 드러났다.

   사례 보기
2. IL-0040 비운영 쿠버네티스 클러스터에 Helm 차트를 한꺼번에 설치하자 작은 gp2 루트 볼륨의 IOPS 가 바닥나, 워커 노드 세 대에서 kubelet 이나 Docker 가 내려가 세 대 모두 NotReady 가 됐다

   Saltside2017

   증상

   SRE 팀장이 애플리케이션 Helm 차트를 고친 뒤 자기 머신에서 CI 과정을 돌렸다. watch kubectl get pods 로 지켜보니 파드가 모두 Running 이 되었는데, 그중 일부가 다시 Pending 으로 바뀌었다. 그는 저절로 풀릴 일시적인 문제라고 보고 회의에 들어갔다.

   파드 Pending이미지 풀 실패노드 NotReady서비스 중단

   촉발

   CI 과정을 로컬에서 돌려 시장 네 곳의 Helm 차트를 비운영 클러스터에 한꺼번에 설치했다. 그 결과 t2.medium 워커 노드 세 대가 여러 컨테이너의 이미지를 동시에 받고 컨테이너를 동시에 만들었다.

   원인

   용량 한계

   구성 요소

   노드 루트 디스크kubelet컨테이너 런타임Helm

   기여 요인

   기본 설정 방치모니터링 사각지대초기 신호 무시단일 장애점

   감지

   담당자가 CI 과정을 돌리며 watch kubectl get pods 로 지켜보다가 Running 이던 파드가 Pending 으로 바뀌는 것을 보았다. 두 시간 뒤 Unknown 상태의 파드를 보고서야 내부에서 무언가 확실히 잘못됐다고 판단했다. 워커 노드 세 대가 모두 NotReady 였지만 어떤 모니터링도 이를 잡지 못했다.

   조치

   • 워커 노드 세 대를 종료하고 오토스케일링 그룹이 새 인스턴스를 띄우게 했고, 약 10분 뒤 클러스터가 정상으로 돌아왔다.

   후속 조치

   • 비운영 AWS 계정과 DataDog 의 연동 문제를 고쳐 지표가 들어오게 하고, 그 지표를 보며 설치 과정을 다시 돌렸다.
   • 워커 노드의 루트 EBS 볼륨을 20GB 에서 120GB 로 늘렸다.
   • ruby:2.4, alpine:3.2 같은 공통 베이스 이미지 안에서 sleep 루프만 도는 DaemonSet 을 배포해 노드에 이미지를 미리 받아 두었다. kops 가 사용자 훅을 지원할 때까지 쓰는 임시 방편이다.
   • 쿠버네티스의 계층마다 할당 한도를 다르게 설정한다.
   • tiller 가 크래시 루프에 빠지면 차트 설치와 업그레이드로 수정을 배포할 수 없으므로 tiller 고가용성을 Helm 팀과 논의한다.
   • 새로 만드는 파드 수를 조절할 방법을 찾는다.

   교훈

   평소 하던 애플리케이션 배포만으로도 클러스터가 무너질 수 있었다. 워커 노드를 종료하는 방법은 효과가 있었지만 파드를 다른 노드로 옮기지 않으므로 운영 환경에서는 고객이 서비스를 못 쓰게 된다. 그래서 이런 장애의 표준 절차가 될 수 없다. 노드 상태, 파드 단계, 노드 리소스 지표가 없으면 이런 장애를 알아채지 못한다. kops 의 기본 20GB gp2 루트 볼륨은 IOPS 와 디스크 공간이 모두 모자랐다. 새로 만드는 파드 수를 조절할 수단이 있으면 문제를 풀지는 못해도 위험을 줄일 수 있고, 무언가 잘못됐을 때 제 손으로 클러스터를 마비시키는 일을 막을 수 있다.

   사례 보기

원인별2