사례6건

6건 중 1~5번째

1. IL-0139 Calico 네트워크 정책을 쓰는 GKE 클러스터를 1.22 이상으로 업그레이드하자 경쟁 조건 때문에 CNI 정리가 Unauthorized 로 실패해 파드가 Terminating 이나 Pending 에 멈췄다.

   Google Cloud2022

   증상

   GKE 를 1.22 이상으로 업그레이드한 뒤 Calico 네트워크 정책을 쓰는 클러스터에서 파드가 Terminating 이나 Pending 상태에서 빠져나오지 못했다. 실제로 파드가 멈춘 클러스터는 소수였다.

   파드 Terminating 정체파드 Pending

   촉발

   Calico 네트워크 정책을 켠 GKE 클러스터를 1.22 이상 버전으로 업그레이드했다.

   원인

   소프트웨어 결함

   구성 요소

   Calicokubelet파드 종료 처리

   기여 요인

   –

   조치

   • 1.24.4-gke.800 에 수정을 넣고 1.23 과 1.22 로 백포트했으며, 고객이 수정 버전으로 직접 업그레이드할 수 있게 했다.
   • 영향받는 버전의 고객에게 Google Cloud 지원팀을 통해 내부 패치를 적용받도록 권했다.
   • kubelet 과 calico-node 를 재시작해 멈춘 파드를 풀어 주는 우회책을 안내했다.
   • Calico 가 꼭 필요하지 않은 고객에게는 Calico 네트워크 정책을 끄는 우회책을 안내했다.

   후속 조치

   • 1.22 나 1.23 을 쓰는 RAPID, REGULAR, STABLE 릴리스 채널의 클러스터를 앞으로 몇 주에 걸쳐 수정 버전으로 자동 업그레이드한다.

   교훈

   클러스터 오토스케일러를 쓰면 이 경쟁 조건에 걸릴 확률이 높아진다. 수정 버전으로 올리기 전에는 kubelet 과 calico-node 를 재시작해 멈춘 파드를 풀 수 있고, Calico 가 꼭 필요하지 않다면 Calico 네트워크 정책을 끄는 방법도 있다.

   사례 보기
2. IL-0514 클라우드 사업자의 노드 교체 뒤 Consul 이 리더를 뽑지 못하고 Vault 가 봉인된 채 남아 PyPI 백엔드가 7분 동안 응답하지 않았다

   Python Software Foundation2022

   증상

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 다시 올라오려면 봉인 해제가 필요하다는 첫 알림이 왔다. 살펴보니 클러스터의 Vault 컨테이너는 모두 쓸 수 없었고 Consul 컨테이너는 새 리더를 뽑지 못하고 있었다.

   서비스 중단파드 Terminating 정체

   촉발

   2022-07-28 17:24 UTC 부터 클라우드 사업자가 알 수 없는 장애를 이유로 PyPI 가 도는 쿠버네티스 클러스터의 클라우드 인스턴스 여러 대를 자동으로 교체했다.

   원인

   클라우드 제공자 장애

   구성 요소

   코디네이션 키-값 저장소시크릿 저장소

   기여 요인

   자동화 증폭

   감지

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 봉인 해제가 필요하다는 알림이 왔다.

   조치

   • Terminating 상태에 멈춘 Consul 파드를 강제로 지우고 다시 만들어지게 했다. 그 뒤 Consul 회복이 시작됐다.
   • Consul 을 되살린 뒤 새 Vault 컨테이너의 봉인을 풀었다.

   사례 보기
3. IL-0449 EKS 관리형 노드 그룹으로 옮긴 며칠 뒤 파드가 재시작을 되풀이하거나 Terminating 상태에 멈추고 노드를 쓸 수 없게 됐다

   Enigmo2020

   증상

   EKS 클러스터의 파드를 새로 만든 관리형 노드 그룹으로 옮기고 2~3일 지나자, 파드가 갑자기 재시작을 되풀이하거나 제대로 종료되지 못하고 Terminating 상태로 계속 남았다. 노드의 CPU 와 메모리 부하가 높아져 클러스터에서 노드를 쓸 수 없게 됐다.

   파드 Terminating 정체노드 CPU 고부하메모리 압박노드 NotReady업그레이드 정체

   촉발

   EKS 1.16 업그레이드를 앞두고 파드를 버그가 있는 AMI 로 만든 새 관리형 노드 그룹으로 옮기고 옛 노드 그룹을 지웠다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   롤백 무효늦게 드러난 변경

   조치

   • 수정된 AMI 가 나오자 관리형 노드 그룹의 AMI 버전을 바꿨다.
   • CloudFormation 으로 관리형 노드 그룹 업데이트를 실행했다.
   • 업데이트가 도는 동안 kubectl get pods --all-namespaces 로 파드 상태를 지켜봤다.
   • Terminating 상태로 한동안 변화가 없는 파드를 찾을 때마다 kubectl delete pods <pod name> --grace-period=0 --force 로 강제로 지웠다.

   후속 조치

   • 분기나 달마다 각종 모듈의 최신 릴리스를 확인하고 정기적으로 업그레이드해, 서비스 영향을 가장 작게 하는 운영 방법을 찾는다.

   교훈

   Amazon EKS 나 쿠버네티스를 쓰는 한 클러스터 본체와 Ingress Controller 같은 모듈의 업그레이드를 늘 신경 써야 한다. 안정적으로 돈다고 한동안 손대지 않고 두면, 그사이 호환성을 깨는 변경이 담긴 릴리스가 갑자기 발표되는 일이 드물지 않다. 쿠버네티스 마이너 버전은 3개월쯤마다 나오므로 1년에 적어도 한 번은 업그레이드해야 한다.

   사례 보기
4. IL-0401 Kubernetes 프로젝트의 Prow 빌드 클러스터 노드가 GCP 디스크 IOPS 스로틀링에 걸려 테스트가 이상하게 실패하고 PR 머지가 몇 시간 멈췄다

   Kubernetes project2019

   증상

   2019년 5월 30일 13:26 PDT 에 Slack 으로 Prow 가 이상하다는 신고가 들어왔다. GitHub 에는 잡이 실패했다고 올라왔는데 Deck 에서는 같은 잡이 아직 실행 중으로 보였다. 많은 테스트가 뜻밖의 방식으로 실패하거나 실행 도중 뚜렷한 이유 없이 중단됐다.

   노드 NotReady노드 커널 패닉파드 Terminating 정체처리량 저하

   촉발

   Kubernetes 1.15 code freeze 를 앞두고 테스트 사용량이 치솟아, k8s-prow-build 클러스터 노드의 디스크 I/O 가 GCP 의 스로틀링 한도에 걸렸다.

   원인

   용량 한계

   구성 요소

   클라우드 블록 스토리지노드 루트 디스크kubeletCI 시스템

   기여 요인

   모니터링 사각지대초기 신호 무시

   감지

   여러 사용자가 GitHub 에는 실패로 올라왔지만 잡 상태로는 아직 실행 중인 잡이 있다고 신고했다. 첫 신고는 13:26 에 Slack 으로 들어왔다. 이런 장애를 잡는 알림은 없거나 동작하지 않았다.

   조치

   • 디스크 quota 를 더 요청해 15:14 에 받았다.
   • 17:10 에 500 GB 디스크 노드 55개를 띄웠다.
   • 23:55 에 새 노드 풀로 옮기는 일을 마쳐 모든 노드가 500 GB 디스크를 쓰게 됐다.

   후속 조치

   • tide 가 일을 멈추면 온콜 담당자가 호출을 받도록 모니터링을 만들거나 고친다. 이 일은 이슈 #12829 에서 다룬다.
   • 온콜 순번에 새 사람을 넣는 절차와 지침을 만들어, 새 사람이 준비나 추가 지원 없이 혼자 맡겨지지 않게 한다.

   교훈

   사고 전에 Prow 지표가 기록되지 않아 무슨 일인지 파악하기 어려웠다. 이런 장애를 잡는 알림은 없거나 동작하지 않았다. 원인을 찾고 해결책을 정한 뒤에도 두 시간 동안 아무것도 하지 않았다. 사고로 1.15 code freeze 가 밀렸다. IOPS 가 문제라는 것을 알아본 사람이 마침 자리에 있었던 것은 운이었다.

   사례 보기
5. IL-0402 GKE 노드가 고장 나 NodeLost 가 된 JupyterHub 파드가 hub DB 의 PVC 를 놓지 않아 mybinder.org 가 몇 시간 동안 새 사용자를 받지 못했다

   Binder Project2018

   증상

   2018년 3월 13일 07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. JupyterHub 가 새 사용자를 하나도 받지 못하고 있었다.

   서비스 중단노드 NotReady파드 Terminating 정체파드 ContainerCreating 정체

   원인

   unknown

   구성 요소

   영구 볼륨과 스테이트풀셋노드 풀

   기여 요인

   온콜 호출 미전달

   감지

   07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. Stackdriver 알림 메일은 오지 않았다. Stackdriver 메일은 스팸으로 분류되곤 했고 알림이 몇 시간 늦게 도착했다.

   조치

   • 07:33 에 상태가 나쁜 노드를 cordon 했다.
   • Unknown 상태의 hub 파드와 5시간째 ContainerCreating 이던 두 번째 hub 파드를 지워, 정상 노드에 다시 스케줄되는지 봤다.
   • GCP 웹 화면에서 노드 gke-prod-a-ssd-pool-32-134a959a-n2sk 를 손으로 reset 해 PVC 를 강제로 풀려고 했다. 08:05 에 새 hub 파드가 다른 노드에 떠 실행됐다.
   • 13:34 에 kubectl --namespace=prod delete pod <pod-name> --grace-period=0 --force 로 Unknown, NodeLost 상태 파드를 모두 강제 삭제했고, 그 파드에서 돌던 서비스들이 회복했다.

   후속 조치

   • 장애가 왜 시작됐는지 조사한다. 문제를 일으킨 파드가 있었는지, GCE 장애였는지 Stackdriver 로그와 Google Cloud 장애 공지를 살핀다.
   • Stackdriver 가 아닌 알림 서비스를 두어 이런 문제를 더 일찍 잡는다. 이 일은 지금 #365 에 막혀 있다.
   • PVC 가 풀리지 않았는지 확인하는 방법을 문서로 남겨, 다음에 이 문제를 빨리 알아볼 수 있게 한다.
   • 명령이 대부분 통하지 않을 때 노드를 손으로 재시작하는 방법을 문서로 남긴다.
   • Unknown 상태가 된 파드를 지우는 방법을 문서로 남긴다. 이 문서는 #512 에서 다룬다.

   교훈

   문제를 찾은 뒤에는 조치를 잘 기록했고, 필요에 따라 더 강한 조치로 빠르게 넘어가서 hub 가 멈춘 시간은 짧았다. 오류를 알아채기까지는 꽤 오래 걸렸다. Stackdriver 메일이 오지 않았는데, Stackdriver 메일은 스팸으로 분류되고 알림이 몇 시간 뒤에야 도착했다.

   사례 보기

원인별5