사례2건

2건 중 1~2번째

1. IL-0014 GKE 를 1.12.5-gke.10 으로 올리는 중 노드 풀 업그레이드가 멈추고 인그레스와 HPA 가 망가졌다

   loveholidays2019

   증상

   미뤄 둔 GKE 업그레이드를 하던 저녁, 마스터는 문제없이 올라갔지만 노드 풀 업그레이드가 예상보다 훨씬 오래 걸렸다. 노드가 14개이고 노드당 5분쯤 걸리는 클러스터도 한 시간 넘게 걸렸고, 일부 노드는 드레인에 15분 넘게 걸렸다. emptyDir 를 쓰는 파드와 5분에서 10분짜리 terminationGracePeriodSeconds 가 드레인을 늦췄다.

   업그레이드 정체파드 Pending노드 증설 실패서비스 중단오토스케일러 오동작

   촉발

   마이그레이션에 쫓겨 미뤄 둔 업그레이드로 운영 클러스터를 1.10.X 에서 1.12.5-gke.10 으로 올렸다. 구글은 3월 14일 GKE 릴리스 노트에서, 이 버전으로 올린 마스터의 오류율이 높아진다는 보고가 있어 새 클러스터와 마스터 업그레이드에서 이 버전을 빼는 중이라고 밝혔다. 그런데도 3월 19일에 이 버전을 고를 수 있었다.

   원인

   클라우드 제공자 장애

   구성 요소

   GKE 컨트롤 플레인노드 풀클러스터 오토스케일러인그레스 컨트롤러수평 파드 오토스케일러

   기여 요인

   스테이징 불일치장애 중첩초기 신호 무시

   감지

   업그레이드하던 엔지니어가 드레인이 느리고 노드 풀 업그레이드가 멈추고 파드가 Pending 에 머무는 것을 직접 보았다. 인그레스 장애는 업그레이드 뒤에 드러났고, 로그로 원인을 찾지 못해 구글 지원팀에 물어 알려진 버그라는 것을 알았다. HPA 이상은 업그레이드 다음 날 발견했다.

   조치

   • 노드 풀의 노드 목록을 뽑아 kubectl drain 에 --ignore-daemonsets --delete-local-data 를 주어 노드를 미리 드레인했다.
   • 노드 풀에 해당하는 관리형 인스턴스 그룹을 찾아 gcloud compute instance-groups managed delete-instances 로 멈춘 인스턴스를 지웠다.
   • gcloud container operations list 로 operationType: UPGRADE_NODES, status: RUNNING 인 작업을 찾아 gcloud beta container operations cancel 로 멈춘 노드 풀 업그레이드를 취소했다.
   • 동작을 멈춘 내부 인그레스 대신 한동안 port-forward 로 접근했다.
   • HPA 가 이상해진 배포에서 활성 레플리카셋이 두 개면 오래된 레플리카셋을 천천히 줄였고, 하나면 더미 환경 변수를 바꿔 다시 배포했다.

   후속 조치

   • HorizontalPodAutoscaler 가 최대치의 70% 와 100% 에 닿으면 Alertmanager, Prometheus, Slack 으로 경보를 보내게 했다.
   • 배포에 활성 레플리카셋 두 개가 30분 동안 남아 있을 때와 60분 동안 남아 있을 때 경보를 보내게 했다.
   • 임의로 크게 잡은 종료 유예 시간을 다시 따져 본다.
   • 클러스터를 업그레이드하기 전에 GKE 릴리스 노트를 먼저 확인한다.
   • 운영이 아닌 환경에는 자동 업그레이드를 쓰고, 운영 환경은 클러스터를 수동으로 업그레이드하고 노드는 자동 업그레이드를 쓴다.
   • 사전 검증 환경을 이름까지 운영과 최대한 똑같이 맞춘다.

   교훈

   클러스터를 업그레이드하기 전에는 GKE 릴리스 노트를 먼저 봐야 한다. 운영이 아닌 환경에는 자동 업그레이드를 써서 영향을 먼저 겪고, 운영에는 수동 클러스터 업그레이드와 자동 노드 업그레이드를 섞어 예측 가능성과 유지 부담 사이에서 균형을 잡는다. 사전 검증 환경은 이름까지 운영과 같게 둬야 한다. 노드 풀 업그레이드 시간은 노드 수와 드레인 시간에 달려 있다. emptyDir 를 쓰는 파드에 safe-to-evict 어노테이션을 달고, 지나치게 긴 종료 유예 시간을 다시 따져 보고, PodDisruptionBudget 을 두면 드레인이 빨라진다.

   사례 보기
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