사례3건

3건 중 1~3번째

1. IL-0204 Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다.

   Render2024

   증상

   2022년 1월 Render 의 프랑크푸르트 Kubernetes 클러스터 하나에서 새 배포와 크론 잡 실행이 실패했다. etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸린 상태였다.

   컨트롤 플레인 무응답배포 실패DNS 조회 실패오류율 상승

   촉발

   etcd 메모리가 급증해 Kubernetes 컨트롤 플레인이 과부하에 걸렸다.

   원인

   용량 한계

   구성 요소

   etcdCoreDNS쿠버네티스 API 서버

   기여 요인

   기본 설정 방치수동 조치 악화

   후속 조치

   • CoreDNS 를 컨트롤 플레인 노드가 아닌 데이터 플레인 노드에서 돌게 했다.
   • etcd 를 전용 노드에서 돌게 했다.

   교훈

   CoreDNS 는 API 서버가 내려가 있어도 메모리 캐시로 DNS 질의에 답할 수 있지만, 초기화할 때는 API 서버가 필요하다. CoreDNS 가 컨트롤 플레인 노드에 있었기 때문에, 컨트롤 플레인 장애 중에 노드를 재부팅하자 새 배포와 크론 잡만 실패하던 장애가 이미 돌던 서비스로 가는 요청까지 실패하는 장애로 커졌다. 핵심 문제는 데이터 플레인이 컨트롤 플레인에서 충분히 분리되어 있지 않았다는 점이다. 노드를 재부팅하지 않았더라도 etcd 메모리 급증만으로 CoreDNS 가 재시작될 수 있었다.

   사례 보기
2. IL-0182 트래픽이 급변할 때 수가 모자란 CoreDNS 가 과부하로 지연과 간헐적 네트워크 끊김을 일으켰고, 나중에는 과하게 늘린 CoreDNS 파드가 Karpenter 의 노드 통합을 막았다

   이언철2024

   증상

   트래픽이 급하게 오르내리는 환경에서 CoreDNS 에 부하가 몰렸다. 네트워크 문제가 생기고 응답 지연이 크게 늘었다.

   지연 시간 증가간헐적 연결 실패오토스케일러 오동작

   촉발

   트래픽이 급변하면서 수가 적은 CoreDNS 파드에 처리할 수 있는 양보다 많은 부하가 몰렸다.

   원인

   용량 한계

   구성 요소

   CoreDNSKarpenter수평 파드 오토스케일러파드 스케줄링과 배치

   기여 요인

   자동화 증폭수동 조치 악화

   조치

   • 클러스터 크기에 맞춰 CoreDNS replica 를 늘리도록 CPA 를 설정하고, 인스턴스 타입에 맞게 nodesPerReplica, coresPerReplica, replica 최솟값과 최댓값을 조정했다.
   • CoreDNS 에 anti-affinity 대신 ScheduleAnyway 로 느슨하게 한 topologySpreadConstraints 를 걸어, Karpenter 의 Consolidation 과 Drift 가 CoreDNS 에 막히지 않게 했다.
   • CoreDNS 의 Error Rate, Panics, Request Duration, Request Rate 에 임곗값 알림을 걸었다.
   • NodeLocal DNSCache 를 적용해 노드마다 DNS 캐시를 두고 메인 CoreDNS 의 부하를 낮췄다.

   교훈

   CoreDNS 가 감당할 수 있는 양은 파드에 준 리소스에 따라 다르고, 그에 따라 평균 지연과 초당 질의 수인 QPS 도 달라진다. CoreDNS replica 를 무작정 늘리면 taint 와 topologySpreadConstraints 때문에 파드가 몇몇 노드에 몰려 Karpenter 의 Consolidation 을 막을 수 있다. 노드 하나가 드레인될 때 그 노드의 CoreDNS 가 한꺼번에 많이 종료되면 서비스에 영향이 갈 수 있다. NodeLocal DNSCache 를 쓰면 메인 CoreDNS 로 가는 DNS 질의가 크게 줄고 스파이크를 다루기 쉬워진다. 어느 노드에서 문제가 생겨도 메인 CoreDNS 는 영향을 받지 않는다. 그래서 서비스 전체 장애로 번질 일이 노드 하나의 문제로 그친다. 글쓴이는 CPA 와 NodeLocal DNSCache 를 함께 적용해 CoreDNS 부하 문제를 거의 없앴다고 보았다.

   사례 보기
3. IL-0230 쿠버네티스 업그레이드 도중 메인 운영 클러스터의 서비스 간 통신이 끊겨 모든 고객의 작업이 시작되지 않았다

   CircleCI2023

   증상

   2023-03-14 18:00 UTC 쯤 한 서비스에서 통신 오류가 늘기 시작했다. 곧 모든 고객의 파이프라인이 늦게 시작하다가 끝내 작업이 돌지 않았고, 18:19 UTC 에 상태 페이지에 작업 시작 지연이 올라왔다.

   서비스 중단간헐적 연결 실패DNS 조회 실패

   촉발

   3월 14일 17:40 UTC 쯤 인프라 팀이 전날 되돌렸던 구성 요소들을 다른 방식으로 다시 업그레이드했다. 전날 kube-proxy 를 되돌린 뒤로 iptables 동기화가 조금씩 실패하던 상태에서 업그레이드를 이어 가자 동기화 오류가 한꺼번에 치솟았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   kube-proxykubeletCoreDNS클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   부분 배포롤백 무효모니터링 사각지대수동 조치 악화

   감지

   팀은 3월 14일 18:00 UTC 에 한 서비스의 통신 오류가 늘어나는 것을 보고 장애를 알아챘다. 장애 통화에 사람이 더 들어오면서 영향이 여러 서비스로 퍼진 것을 확인했다. 3월 13일 롤백 뒤에 로그에 나온 소수의 Sync 실패 오류는 그때 알아채지 못했다.

   조치

   • 모든 노드를 차례로 재시작해 노드마다 iptables 규칙 집합을 새로 만들었고, 23:00 까지 모든 노드 교체를 마쳤다.
   • contexts 나 machine executor 를 쓰는 작업이 회복되지 않아 별도의 의존성 풀을 재시작했고, 3월 15일 01:15 UTC 에 모든 작업이 정상으로 돌았다.
   • 작업이 다시 돌기 시작하자 쌓인 작업을 처리하려고 용량을 늘렸다.
   • 망가진 큐 몇 개를 고치려고 RabbitMQ 노드를 재시작했다.

   후속 조치

   • 앞으로의 업그레이드에서 이런 위험을 크게 줄이도록 쿠버네티스 업그레이드 절차를 고친다.
   • 이번 장애 때 kube-proxy 가 낸 동기화 오류를 잡는 지표와 알림을 더했다.
   • RabbitMQ 인프라의 복원력을 높일 방법을 검토한다.

   교훈

   이번 장애를 촉발한 원인은 하나가 아니었다. 네트워크는 모든 것의 바탕이어서 쿠버네티스 업그레이드는 본래 위험하다. 여러 사건이 맞물려 터진 이번 경우에는 팀이 세워 둔 위험 완화 방법이 듣지 않았다.

   사례 보기

원인별2