사례13건

13건 중 6~10번째

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-0109 로그 수집을 고치려던 EKS 노드 롤오버가 꼬이면서 Auto Scaling 그룹이 정상 워커 노드를 모두 종료해 클러스터에 노드가 하나도 남지 않았다.

   DFDS2023sev1

   증상

   2023-02-14 09:33 UTC, 최종 사용자들이 CloudWatch 로그가 제대로 들어오지 않는다고 알려 왔다. 팀은 fluentd 를 조사하다가 컨테이너 런타임이 docker-shim 이 아니라 containerd 로 바뀌어 있다는 것을 찾았다. 전날 07:30 UTC 의 정기 노드 롤오버 때 containerd 가 실수로 기본 런타임으로 설정돼 있었다.

   서비스 중단리소스 삭제모니터링 중단

   촉발

   쿠버네티스 로그가 CloudWatch 로 가지 않는 문제를 고치려고 예정에 없던 노드 롤오버를 시작했다.

   원인

   설정 변경

   구성 요소

   컨테이너 런타임노드 런치 템플릿노드 풀Terraform텔레메트리 에이전트

   기여 요인

   자동화 증폭기본 설정 방치스테이징 불일치설정 테스트 부재런북 부재수동 조치 악화

   감지

   로그 문제는 최종 사용자들이 CloudWatch 로그가 이상하다고 알려 오면서 드러났다. 노드가 사라진 장애는 사후 분석 기준으로 2분 만에 감지됐다.

   조치

   • 10:49 UTC 에 노드 롤오버 스크립트로 새 노드를 추가하려 했지만 Docker Hub 타임아웃으로 실패했다.
   • 10:52 UTC 에 노드 롤오버 스크립트를 다시 돌려 새 노드를 추가했고, 11:01 UTC 에 로드밸런서가 새 노드를 정상으로 판단해 트래픽을 다시 보냈다.

   후속 조치

   • 롤오버 절차를 문서로 남기고, 특히 롤오버가 잘못됐을 때 할 수 있는 일을 적는다.
   • 롤오버 절차를 개선할 방법을 찾는다.
   • QA 시험에 fluentd 로그 수집을 넣어 로그가 처음부터 끝까지 전달되는지 확인한다.
   • fluentd 가 보내는 로그 데이터가 부족하거나 없을 때 울리는 경보를 추가한다.
   • 스테이징 환경을 만든다.
   • 잘못된 컨테이너 런타임을 고르지 못하게 막는 장치를 넣었다.

   교훈

   상황이 심각해져도 침착해야 한다. 서둘러 고치다 피해를 키우기보다 알려진 정상 설정으로 롤백하는 편이 낫다. 새 워커 노드를 띄우는 일은 cloudinit 스크립트의 어느 단계도 실패하지 않는다는 전제에 크게 기대고 있다.

   사례 보기
3. 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 파일을 받았다.

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

   GitHub2020

   증상

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

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

   촉발

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

   원인

   DNS·네트워크 장애

   구성 요소

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

   기여 요인

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기
5. 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를 직접 지우는 방법은 발표자도 절대 하지 말라고 한 마지막 수단이다.

   사례 보기

원인별5