사례3건

3건 중 1~3번째

1. IL-0087 RKE2 클러스터 노드를 재부팅한 뒤 Multus 가 쿠버네티스 API 에 닿지 못해 파드가 IP 를 받지 못했고, 같은 장애가 모든 노드로 번져 전체 서비스가 멈췄다.

   Fyra Labs2023

   증상

   ICT 기준 2023-04-09 새벽 2시쯤 클러스터 노드 하나가 평소와 다른 CPU 사용을 보였다. 팀은 containerd 와 runc 의 상위 프로젝트에 있는 CRI 버그로 추정했다. 이 노드가 다른 서비스를 모두 스로틀링해 서비스가 실패하고 있었다.

   노드 CPU 고부하서비스 중단

   촉발

   평소와 다른 CPU 사용을 보인 노드를 바로잡으려고, 시스템을 쓰는 사람이 없는 시간이라고 보고 클러스터를 정비 상태로 내린 뒤 영향받은 노드를 전부 재부팅했다.

   원인

   unknown

   구성 요소

   Multus 메타 CNICalico컨테이너 런타임

   기여 요인

   수동 조치 악화미검증 가정

   감지

   새벽 2시쯤 노드 하나의 평소와 다른 CPU 사용을 발견했다. 재부팅 뒤 2시 30분쯤 일부 서비스에서 이상한 문제가 보여 네트워크 장애를 알아챘고, 6시 31분에는 개발자들이 Terra 저장소가 내려갔다고 알려 왔다.

   조치

   • Multus 와 Calico 를 완전히 지우고 Cilium CNI 로 바꿨다.
   • 14:30 ICT 까지 CNI 를 뺀 클러스터 설정 대부분을 되돌려 모든 서비스를 다시 올렸다.

   교훈

   팀은 처음 장애를 저절로 풀릴 일시적인 문제로 보고 다른 노드까지 재부팅했는데, 이 판단은 완전히 틀렸고 장애가 모든 노드로 번졌다. 바꿔 넣은 Cilium 은 이 클러스터에서 Calico 보다도 잘 동작했다. 팀은 한 블로그 글의 자원 사용량 비교를 보고 Cilium 을 피했었지만, 실제로는 Calico, Canal, Flannel 과 마찬가지로 노드당 1코어라는 허용 범위 안에서 돌았다. 작은 클러스터에서는 Cilium 의 조금 더 큰 자원 사용량이 문제가 되지 않았다.

   사례 보기
2. IL-0059 kubeadm이 만든 etcd 정적 파드의 liveness probe가 실패해 kubelet이 약 2분마다 etcd를 재시작했고, 단일 마스터 클러스터의 API 서버가 계속 끊겼다

   NRE Labs2018

   증상

   2018년 12월 4일 아침 8시 회의 중 운영자가 NRE Labs의 일일 통계를 보다가 레슨 사용량이 떨어진 것을 알아챘다.

   컨트롤 플레인 무응답프로브 실패서비스 중단

   촉발

   kubeadm이 etcd 정적 파드 매니페스트에 넣은 liveness probe가 실패하기 시작했다. 이 probe는 etcdctl로 foo 키를 조회한다. failureThreshold가 8, timeoutSeconds가 15라서 약 2분 동안 실패가 이어지면 kubelet이 etcd를 재시작한다. probe가 왜 실패하기 시작했는지는 끝내 밝히지 못했다.

   원인

   unknown

   구성 요소

   etcdkubelet쿠버네티스 API 서버

   기여 요인

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

   감지

   운영자가 아침 회의 중 NRE Labs 일일 통계를 보다가 레슨 사용량이 떨어진 것을 보고 알았다. 클러스터 모니터링은 갖추지 않은 상태였고, 원문은 모니터링이 우선순위에서 밀려 있었다고 적었다.

   조치

   • kubeadm이 만든 etcd 매니페스트에서 liveness probe 부분을 통째로 지우고, 다음 etcd 재시작 때 kubectl apply로 반영했다.

   후속 조치

   • 단일 마스터 클러스터에 모니터링을 갖춘다.
   • 장애가 나면 트위터를 보라고 안내하는 점검 페이지를 Google Cloud Functions에 만든다. 계획된 작업이든 아니든 일이 생기면 트래픽을 그 페이지로 돌린다.

   교훈

   모든 인프라를 코드로 관리한 덕에 클러스터를 금방 다시 만들 수 있었다. 하지만 원인을 모른 채 지우면 증거도 함께 사라진다. 단일 마스터로 운영한다면 모니터링이 더 중요하다. kubectl 출력에서 Running만 보지 말고 재시작 횟수까지 읽어야 한다. 복잡한 원인을 기대하기 전에 기본부터 의심하고, 장애의 급박함에 밀려 성급한 결정을 내리지 않는다. 사이트를 반쯤 망가진 채로 두지 말고 점검 페이지로 상황을 알려야 한다.

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

   사례 보기

원인별1