사례6건

6건 중 3~6번째

1. IL-0017 live 클러스터 노드 6대에서 VPC CNI 가 IP 주소를 할당하지 못해 새 파드가 ContainerCreating 에 멈췄다

   UK Ministry of Justice2023

   증상

   2023-07-21 08:15, 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 상태에서 멈춘다고 알렸다.

   파드 ContainerCreating 정체IP 주소 고갈

   원인

   설정 변경

   구성 요소

   AWS VPC CNI노드 풀

   기여 요인

   설정 테스트 부재

   감지

   팀은 08:15 에 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 에서 멈춘다고 보고해 장애를 알았다. 장애 선언은 09:31 이었다.

   조치

   • 새 노드를 추가하고, 영향받은 노드 6대를 cordon 한 뒤 drain 하기 시작했다.
   • live 클러스터에서 Prefix Delegation 을 켜는 명령을 실행해 빠진 CNI 설정을 넣었다.

   후속 조치

   • IP 주소 할당이 제대로 되는지 확인하는 테스트나 점검을 추가한다. 작업 번호는 #4669 다.

   교훈

   이 글은 교훈을 따로 적지 않았다. 후속 조치로는 IP 주소 할당이 제대로 되는지 확인하는 점검을 추가한다는 것 하나만 적었다.

   사례 보기
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-0521 AKS 클러스터의 Azure 서비스 주체 자격 증명이 만료돼 파드가 볼륨을 마운트하지 못함

   Jenkins project2021

   증상

   2021년 6월 2일 18:02 UTC 부터 Jenkins 인프라의 AKS 클러스터에서 파드가 볼륨을 마운트하지 못한다는 오류와, 스케일 업으로 늘어난 노드가 CNI 에서 네트워크 가상 인터페이스를 받지 못한다는 오류가 나타나기 시작했다.

   자격 증명 획득 실패파드 ContainerCreating 정체

   촉발

   2021년 6월 2일 17:53 UTC 에 AKS 노드가 Azure API 인증에 쓰는 Azure 서비스 주체 자격 증명이 만료됐다.

   원인

   인증서·자격 증명 만료

   구성 요소

   클러스터의 클라우드 자격 증명영구 볼륨과 스테이트풀셋CNI 플러그인노드 풀

   기여 요인

   모니터링 사각지대

   감지

   LTS 2.289.1 릴리스 문제의 근본 원인을 조사하던 엔지니어가 AKS 콘솔 화면에서 오류를 확인했다.

   조치

   • 인프라 팀이 서비스 주체 자격 증명을 갱신했다. 그러자 AKS 가 모든 노드를 재시작하는 작업을 자동으로 시작했고, 이 작업은 멈출 수 없었다.

   후속 조치

   • 인증서 만료 점검처럼, 서비스 주체 만료 일주일 전에 PagerDuty 알림을 울리는 자동 점검을 더한다.
   • 자격 증명 재설정 같은 수동 작업 일정을 적어 둘 팀 공용 캘린더를 마련한다.
   • 서비스 주체 대신 자동으로 갱신되는 Azure managed identity 를 쓰는 방안을 검토한다.

   사례 보기
4. 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 메일은 스팸으로 분류되고 알림이 몇 시간 뒤에야 도착했다.

   사례 보기

원인별4