사례6건

6건 중 3~6번째

1. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다

   UK Ministry of Justice2024

   증상

   2024-04-15 12:32 에 계획된 Prometheus 변경을 적용한 뒤 Prometheus 를 쓸 수 없게 되었다. 팀은 prometheus 파드가 여러 번 재시작한 것을 보았다. 그동안 Cloud Platform 에는 모니터링이 없었고 지표가 빠졌다.

   모니터링 중단프로브 실패

   촉발

   계획된 변경으로 Prometheus 를 재시작했는데 그때 WAL 수가 평소보다 많아, WAL 다시 읽기가 startupProbe 기본 허용 시간인 15분 안에 끝나지 않았다.

   원인

   용량 한계

   구성 요소

   Prometheus

   기여 요인

   기본 설정 방치한계 미인지

   감지

   계획된 Prometheus 변경 뒤 팀이 prometheus 파드가 여러 번 재시작한 것을 보고 알았다. 처음 감지한 시각은 2024-04-15 12:32 였다.

   조치

   • startupProbe 허용 시간을 기본값 15분에서 30분으로 늘려 WAL 다시 읽기가 끝날 때까지 기다리게 했다.

   후속 조치

   • 팀은 계획된 Prometheus 재시작을 WAL 수가 적을 때 해서 재시작 시간을 줄이는 방안을 논의했다.
   • Prometheus 의 기본 CPU 와 메모리 요청값을 최대 사용량에 맞춰 설정했다.
   • 운영 환경의 WAL 수를 재현하는 테스트 환경을 만든다.
   • memory-snapshot-on-shutdown 과 auto-gomaxprocs 기능 플래그를 검토한다.
   • WAL 파일을 다른 위치의 원격 저장소에 두는 방법을 검토한다.
   • 운영과 같은 구성의 블루그린 Prometheus 를 만들어 운영에 적용하기 전에 변경을 시험하는 방안을 알아본다.
   • Amazon Managed Prometheus 를 간단히 조사한다.

   사례 보기
2. IL-0191 Loki distributor 서비스에 레이블 셀렉터가 하나 더 들어가 롤아웃 중 새 파드 몇 개에만 쓰기 트래픽이 몰렸고, 그 파드들이 OOM으로 죽으면서 로그 쓰기 경로가 약 25분간 멈췄다.

   Grafana Labs2022

   증상

   Grafana Cloud Logs 의 한 환경에서 Grafana Loki 의 쓰기 경로가 내려갔다. 롤아웃 중이던 distributor 파드가 OOM으로 죽었다가 다시 뜨기를 되풀이했다.

   서비스 중단OOMKilled부하 불균형프로브 실패

   촉발

   키-값 저장소에서 내장 memberlist 로 옮기는 마이그레이션의 1단계가 distributor 디플로이먼트와 서비스에 새 레이블을 붙였다. 서비스를 만드는 함수가 이 레이블을 셀렉터로도 복사했기 때문에, 롤아웃이 시작되자 distributor 서비스는 새 레이블을 단 새 파드만 가리켰다.

   원인

   설정 변경

   구성 요소

   설정 템플릿서비스 디스커버리컨테이너 메모리 한도

   기여 요인

   기본 설정 방치초기 신호 무시스테이징 불일치

   감지

   처음에는 distributor 가 OOM으로 죽는 장애로 보였다. 첫 단서는 kubectl get pods 와 kube_deployment_status_replicas_updated 지표에서 distributor 의 10%만 재시작됐다는 점이었다. 팀은 PR 마다 Kubernetes 매니페스트 diff 를 만들어 PR 에 올리고 별도 레포에도 저장하는 자동화를 갖고 있었다. 이 diff 에서 distributor 서비스에 셀렉터가 추가되고 서비스가 다시 만들어진 것을 찾았다. 평소 배포에서는 서비스가 다시 만들어지지 않는다.

   조치

   • distributor 디플로이먼트의 레플리카를 늘렸다. 새로 뜬 파드도 새 레이블을 달고 있어서 부하가 더 많은 파드로 나뉘었고, OOM으로 죽는 파드가 줄면서 Kubernetes 가 옛 파드 교체를 이어 갔다.
   • 마이그레이션 단계의 변경을 되돌려 장애를 완전히 끝내고 원인을 조사할 시간을 벌었다.
   • service_ignored_labels:: [$._config.gossip_member_label] 을 설정하고 서비스 생성 함수 k.util.serviceFor 에 넘겨, memberlist 레이블이 서비스 셀렉터로 복사되지 않게 했다.

   후속 조치

   • 디플로이먼트나 스테이트풀셋의 레이블을 서비스 셀렉터로 복사하던 함수가 이번 같은 예외 상황도 처리하도록 고쳤다.

   교훈

   서비스 셀렉터를 디플로이먼트 레이블에서 자동으로 만들면, 롤아웃 중에 새 레이블이 붙는 순간 서비스가 새 파드만 가리킬 수 있다. 다른 환경에서 본 작은 오류를 롤아웃 때 흔한 잡음으로 넘기면 이런 신호를 놓친다. 환경마다 수평 확장과 메모리 한도 설정이 다르면 다른 환경에서 문제없던 변경이 특정 환경에서만 장애를 낸다. 원인을 빨리 찾는 데에는 Loki 와 Kubernetes 지표, PR 마다 남겨 둔 매니페스트 diff 가 도움이 됐다.

   사례 보기
3. IL-0054 GKE 에서 옛 노드 풀을 드레인하자 로드밸런서가 ingress-nginx 파드가 없는 새 노드만 가리켜 클러스터의 모든 인그레스 트래픽이 끊겼다

   DevOps Hof2019

   증상

   GKE 클러스터에서 워크로드를 새 노드 풀로 옮기려고 옛 노드들을 드레인하던 중, 클러스터의 어떤 서비스에도 ingress-nginx 를 거쳐 접속할 수 없게 됐다.

   서비스 중단프로브 실패

   촉발

   새 노드 풀로 워크로드를 옮기려고 옛 노드를 cordon 하고 드레인했다.

   원인

   운영 실수

   구성 요소

   인그레스 컨트롤러kube-proxy노드 풀

   기여 요인

   기본 설정 방치미검증 가정

   감지

   옛 노드를 드레인하던 중 클러스터의 어떤 서비스에도 ingress-nginx 를 거쳐 접속할 수 없는 것을 팀이 알아챘다.

   조치

   • 옛 노드에 남아 있던 nginx-ingress-controller 파드를 지워 새로 Ready 상태가 된 노드에 다시 스케줄되게 했다.

   교훈

   트래픽에 영향을 줄 수 있는 변경을 하기 전에는 문서를 두 번 확인한다. externalTrafficPolicy 가 Local 이면 kube-proxy 는 다른 노드로 트래픽을 넘기지 않고, 로드밸런서 헬스 체크는 엔드포인트가 없는 노드에서 실패한다. cordon 한 노드는 로드밸런서 백엔드에서 빠진다. 이 둘이 겹치면 인그레스 컨트롤러 파드가 cordon 한 노드에만 남아 있을 때 트래픽이 모두 끊긴다.

   사례 보기
4. 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만 보지 말고 재시작 횟수까지 읽어야 한다. 복잡한 원인을 기대하기 전에 기본부터 의심하고, 장애의 급박함에 밀려 성급한 결정을 내리지 않는다. 사이트를 반쯤 망가진 채로 두지 말고 점검 페이지로 상황을 알려야 한다.

   사례 보기

원인별5