사례29건

29건 중 19~23번째

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-0196 Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.

   Palark2020

   증상

   RedisFailover 리소스에 바뀐 설정을 적용하자 고객 웹사이트의 가장 큰 Redis 데이터베이스에서 데이터가 모두 사라졌다. 이 데이터베이스는 TTL 없이 영속 저장소로도 쓰였고, .rdb 스냅숏이 5 Gb 를 넘었다. 서비스가 멈췄고 백업에서 데이터를 복원해야 했다.

   데이터 유실서비스 중단

   촉발

   RedisFailover 리소스에서 Redis 레플리카 수를 1에서 2로 늘리면서, 같은 변경으로 컨테이너의 메모리 requests 와 limits 를 22 GB 에서 19 GB 로 낮췄다.

   원인

   소프트웨어 결함

   구성 요소

   애플리케이션 데이터베이스영구 볼륨과 스테이트풀셋컨테이너 메모리 한도

   기여 요인

   단계적 배포 부재단일 장애점미검증 가정

   조치

   • 미리 준비해 둔 백업에서 Redis 데이터를 복원했다.

   후속 조치

   • 레디니스 프로브 문제를 Redis Operator 이슈로 올렸고, 개발자들에게서 받은 수정을 시험해 통과를 확인했다.
   • 상황 분석을 마친 뒤 Spotahome Redis Operator 를 계속 쓸지 다시 검토한다.
   • Redis 데이터베이스를 정리하고, 불필요한 키를 만든 애플리케이션 코드를 고친다.
   • Redis 의 내장 클러스터링과 샤딩을 검토한다.

   교훈

   핵심 인프라를 쿠버네티스 오퍼레이터로 관리할 때는 그 오퍼레이터가 얼마나 성숙하고 검증됐는지 따져 봐야 한다. 레플리카 수와 리소스 값을 한 번에 바꾸면 롤링 업데이트가 예상하지 못한 순서로 파드를 재시작할 수 있다. 레디니스 프로브가 ping 만 보면 복제가 끝나지 않은 빈 인스턴스도 준비됐다고 판단한다. Redis 클러스터를 바꾸기 전에는 반드시 dump.rdb 파일을 백업해야 한다.

   사례 보기
4. IL-0002 빌더 파드가 노드 한 대에 몰리자 kubelet 이 기본 API QPS 한도에 막혀 파드 상태를 늦게 갱신했고, CI 빌드가 AWS IAM 자격 증명을 받지 못해 실패했다

   Zalando2019

   증상

   2019년 6월 11일, Zalando 가 직접 만들어 운영하는 CI/CD 플랫폼인 CDP 의 빌드가 한 시간 가까이 타임아웃으로 실패했다.

   오류율 상승자격 증명 획득 실패컨트롤 플레인 지연

   촉발

   CDP 쿠버네티스 클러스터의 규모가 조정되면서 공교롭게도 빌더 파드가 쓸 수 있는 노드가 한 대만 남았다. 그 노드에서 파드가 빠르게 생성되고 삭제되자 kubelet 이 따라가지 못했다.

   원인

   용량 한계

   구성 요소

   kubelet파드용 자격 증명 중개자쿠버네티스 API 서버CI 시스템

   기여 요인

   기본 설정 방치단일 장애점

   조치

   • 클러스터를 수동으로 늘려 빌더 파드가 노드 한 대가 아니라 여러 대에 흩어지게 했다.

   후속 조치

   • 전역 클러스터 설정으로 kubelet QPS 를 기본값 5 에서 50 으로 올렸다.

   사례 보기
5. 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 아래에도 인프라가 있다는 것을 잊지 말라고도 했다.

   사례 보기

원인별11