사례13건

13건 중 8~12번째

1. IL-0093 리더 ingress 컨트롤러 파드가 공유 메모리를 다 써서 ingress 컨트롤러 파드 6개 중 4개가 크래시 루프에 빠졌다

   UK Ministry of Justice2020

   증상

   2020-08-14 10:43 에 클러스터의 ingress 컨트롤러 파드 복제본 6개 중 2개가 크래시 루프에 빠진 것이 감지되었다.

   컨테이너 재시작 반복

   원인

   용량 한계

   구성 요소

   인그레스 컨트롤러

   기여 요인

   수동 조치 악화단일 장애점

   감지

   2020-08-14 10:43 에 ingress 컨트롤러 파드 6개 중 2개가 크래시 루프에 빠진 것이 감지되었다.

   조치

   • 리더 ingress 컨트롤러 파드를 재시작했다. 그러자 다른 파드들이 리더에 연결해 최신 nginx.config 파일을 받았다.

   사례 보기
2. IL-0199 운영에 꼭 필요하지 않은 컨테이너가 메모리 한도를 넘어 파드가 사용 불가로 표시됐고, DNS 작업 탓에 레지스트리에 접속하지 못해 파드가 다시 뜨지 못하면서 GitHub.com 이 4시간 넘게 멈췄다.

   GitHub2020

   증상

   2020년 7월 13일 08:18 UTC 에 운영 쿠버네티스 클러스터의 파드들이 사용 불가로 표시되기 시작했다. 이 상태가 클러스터 전체로 번지면서 처리 용량이 줄었고, 결국 GitHub.com 서비스가 내려갔다.

   OOMKilled이미지 풀 실패서비스 중단

   촉발

   파드 안에서 운영에 필요하지 않은 컨테이너 하나가 메모리 한도를 넘어 종료됐다. 앞서 끝난 정기 DNS 유지보수 작업 때문에 클러스터는 이미지 레지스트리에 접속하지 못하는 상태였다.

   원인

   DNS·네트워크 장애

   구성 요소

   컨테이너 메모리 한도컨테이너 레지스트리와 자격 증명

   기여 요인

   장애 중첩수동 조치 악화단일 장애점

   조치

   • 캐시된 DNS 레코드로 프로세스를 다시 시작해 레지스트리에서 컨테이너 이미지를 받아 올 수 있게 했다.
   • 이미지를 받아 온 뒤 다시 배포해 서비스를 복구했다.

   후속 조치

   • 같은 패턴으로 파드 재시작이 다시 실패하지 않도록 모니터링을 강화한다.
   • 이미지 레지스트리 의존도를 줄인다.
   • DNS 를 바꿀 때 검증 범위를 넓힌다.
   • 기존 쿠버네티스 배포 정책을 모두 다시 검토한다.
   • 배포 영향을 조금씩 확인하며 내보낼 수 있도록 점진 배포 방식을 개선한다.

   교훈

   운영에 필요 없는 보조 컨테이너 하나도 파드 전체를 사용 불가로 만들 수 있다. ImagePullPolicy 가 Always 이면 재시작마다 레지스트리에 기대게 되므로, 레지스트리나 DNS 가 흔들릴 때 평소에는 1분이면 끝날 재시작이 긴 장애로 바뀐다. 수습하려고 재배포하면 같은 실패를 전체 클러스터로 퍼뜨릴 수 있다.

   사례 보기
3. IL-0076 dex의 AuthRequest 리소스가 끝없이 쌓였고, 이를 치우려고 네임스페이스를 지우자 목록 조회 타임아웃과 재시도가 반복되며 쿠버네티스 마스터가 내려갔다

   Fullstaq2019

   증상

   dex의 AuthRequest 리소스가 엄청난 수로 쌓여 있었다. 발표자는 그 전부터 이미 징후가 있었다고 했다.

   컨트롤 플레인 무응답모니터링 중단

   촉발

   dex의 잘못된 기본값 때문에 AuthRequest 리소스가 쌓였다. 발표는 원인으로 지나치게 긴 TTL, 계속 새로고침되는 대시보드, 실제 보안 버그를 꼽았다. 그리고 쌓인 리소스를 치우려고 dex 네임스페이스를 지우자 마스터가 내려갔다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버etcd클러스터 인증 제공자

   기여 요인

   기본 설정 방치수동 조치 악화재시도 폭주디버그 접근 제한초기 신호 무시

   감지

   발표자는 그 전부터 이미 징후가 있었다고 했다. 마스터가 내려간 뒤에는 Slack에 경보가 많이 들어왔지만, 인증도 port-forward도 되지 않아 모니터링에는 들어갈 수 없었다.

   조치

   • kill-kube-ns 도구로 API를 직접 호출해 dex 네임스페이스에 남은 kubernetes finalizer를 지웠다.
   • dex를 적절한 기본값으로 설정해 새 네임스페이스에 다시 배포했다.

   교훈

   외부 도구의 기본값을 그대로 믿지 않는다. 목록 조회도 안 될 만큼 쌓인 리소스를 네임스페이스 삭제로 치우면 정리 루프가 타임아웃과 재시도를 반복해 마스터를 내릴 수 있다. 클러스터 인증이 클러스터 안에 있으면 클러스터가 죽었을 때 모니터링에도 들어갈 수 없다. API로 finalizer를 직접 지우는 방법은 발표자도 절대 하지 말라고 한 마지막 수단이다.

   사례 보기
4. IL-0037 imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다

   Datadog2019

   증상

   사용자들이 작업이 시작되지 않는다고 알려 왔다. 평소에는 모니터링이 먼저 잡아내는 편이었지만 이번에는 사용자 보고가 먼저였다. 처음부터 이미지 풀과 관련된 흔적이 보였다.

   이미지 풀 실패서비스 중단

   촉발

   애플리케이션 하나가 읽어야 하는 버킷의 권한을 바꾸면서 그 애플리케이션이 시작하지 못하게 됐다. 이 애플리케이션은 약 1,000대 노드에서 도는 DaemonSet이었고 크래시 루프에 빠졌다. imagePullPolicy가 Always여서 재시작할 때마다 노드에 이미 있는 이미지를 다시 받았다.

   원인

   용량 한계

   구성 요소

   컨테이너 레지스트리와 자격 증명NAT 게이트웨이애플리케이션 데이터베이스어드미션 웹훅

   기여 요인

   자동화 증폭단일 장애점한계 미인지수동 조치 악화과도한 영향 범위

   감지

   사용자들이 작업이 시작되지 않는다고 알려 와서 알았다. 모니터링보다 사용자 보고가 먼저였다. 팀은 파드 상태, 이미지 풀 지표, 레지스트리 응답 코드를 차례로 확인해 429 속도 제한을 찾았다.

   조치

   • 영향을 받은 NAT 인스턴스를 교체해 레지스트리로 나가는 출발지 IP를 바꿨다.
   • Cloud SQL 접속에 쓰던 고정 IP 설정과 방화벽 규칙을 다시 맞춰 데이터베이스 연결을 되살렸다.

   후속 조치

   • latest 같은 유동 이미지 태그를 막는 어드미션 웹훅을 만들어 워크로드 리소스와 파드에 걸었다.
   • 웹훅이 클러스터가 만드는 파드까지 거부하자, 파드 객체에서는 빼고 워크로드 객체에만 적용하도록 바꿨다.

   교훈

   imagePullPolicy가 Always인 DaemonSet이 크래시 루프에 빠지면 노드 수만큼 이미지 풀이 반복된다. 레지스트리 트래픽이 NAT 몇 대로 모이면 출발지 IP 몇 개가 속도 제한에 걸려 리전 전체가 이미지를 받지 못한다. NAT를 바꾸면 그 IP를 허용해 둔 외부 서비스 연결도 함께 끊긴다. 파드에 거는 어드미션 웹훅은 사용자가 아니라 컨트롤러가 만드는 파드까지 막는다. 발표자들은 대규모 클러스터에서는 DaemonSet을 특히 조심하라고 했다. DaemonSet이 기대는 DNS, Vault, 이미지 저장소도 모두 망가뜨려 본 적이 있다고 했다. 수천 대 단위로 무언가를 다루면 그만큼 망가뜨리기 쉽다는 것이다. kubelet 아래에도 인프라가 있다는 것을 잊지 말라고도 했다.

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