사례4건

4건 중 1~4번째

1. IL-0440 파드가 보낸 DNS 쿼리 패킷이 노드에서 버려져 클러스터 내부 서비스의 이름 조회가 no such host 와 i/o timeout 으로 자주 실패했다

   Cybozu2024

   증상

   파드 안의 애플리케이션이 초당 수백 건씩 클러스터 내부 서비스의 이름을 조회하자 no such host 와 i/o timeout 오류가 자주 났다. 쿠버네티스 플랫폼을 쓰는 팀은 클러스터의 DNS 서버에 성능 문제가 있다고 보고 Cloud Platform 팀에 문의했다.

   DNS 조회 실패간헐적 타임아웃패킷 손실

   촉발

   MySQL 클러스터 감시 애플리케이션이 감시하는 클러스터 수가 늘어났고, 그 뒤부터 이름 조회 오류가 잦아졌다.

   원인

   용량 한계

   구성 요소

   리눅스 커널클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   기본 설정 방치

   감지

   Cloud Platform 팀은 쿠버네티스 플랫폼을 쓰는 팀에게서 클러스터 DNS 서버에 성능 문제가 있다는 문의를 받고 알게 됐다.

   조치

   • 커널 파라미터 net.core.netdev_max_backlog 값을 늘렸다.
   • softnet 지표에 알림을 설정했다.
   • softnet 알림에 대응하는 런북을 마련했다.

   후속 조치

   • veth 인터페이스를 netkit 인터페이스로 바꿔 파드의 송신 패킷이 backlog 큐를 거치지 않고 물리 장치로 바로 가게 하는 방안을 검증한다. netkit 은 리눅스 커널 6.7 에 들어온 가상 네트워크 장치이고, Cilium 1.16 부터 쓸 수 있다.

   교훈

   netdev_max_backlog 를 늘리고 softnet 알림과 런북을 두면 같은 장애가 덜 나고, 나더라도 일찍 알아챌 수 있다. 다만 값을 늘리는 것은 근본 대책이 아니어서, 더 많은 패킷을 보내는 파드가 배포되면 backlog 큐가 다시 차고 패킷이 버려질 수 있다.

   사례 보기
2. IL-0176 시계열 급증으로 호스트 메모리가 바닥나자 oom_score_adj 999 를 받은 Prometheus 컨테이너가 커널 OOM Killer 에게 먼저 죽어 CrashLoopBackOff 에 빠졌다.

   LINE2020

   증상

   어느 월요일 아침, 엔지니어가 쿠버네티스 클러스터 경고를 보려고 Prometheus 대시보드를 열었는데 접속되지 않았다. Prometheus 서버 파드는 CrashLoopBackOff 상태였다.

   컨테이너 재시작 반복OOMKilled모니터링 중단프로브 실패

   촉발

   Prometheus 가 시작한 지 5분 만에 시계열 수가 2,162,256 까지 급증해 메모리 8GB 호스트의 메모리를 거의 다 썼다.

   원인

   용량 한계

   구성 요소

   Prometheuskubelet리눅스 커널

   기여 요인

   리소스 요청과 한도 미설정용량 계획 부재

   감지

   월요일 아침 엔지니어가 클러스터 경고를 확인하려고 Prometheus 대시보드를 열었다가 접속되지 않는 것을 보고 알았다.

   조치

   • Prometheus configMap 에서 불필요한 설정 대부분을 지워 컨테이너가 더 이상 비정상 종료되지 않게 했다.

   후속 조치

   • Prometheus 파드의 requests 와 limits 를 알맞게 고친다. 지금 문제를 완전히 풀지는 못해도 비슷한 문제를 막아 해결 시간을 줄인다.
   • 불필요한 수집 지표를 줄이도록 수집 대상이나 수집 간격을 조정한다.
   • Prometheus 에 필요한 메모리를 예측해 새 호스트를 마련하고 deploy-topology: Prometheus 같은 노드 레이블을 붙인 뒤, 매니페스트에 nodeSelector 를 넣어 Prometheus 파드가 그 호스트에만 배치되게 한다.

   교훈

   원인은 둘이었다. 첫째, Prometheus 파드의 requests 와 limits 를 잘못 잡아 Prometheus 서버 컨테이너가 높은 oom_score_adj 를 받았다. 둘째, 대규모 클러스터에서 Prometheus 가 쓸 메모리를 미리 예측하지 않았다. 쿠버네티스에서 파드의 QoS 클래스는 메모리가 모자랄 때 어느 컨테이너가 먼저 죽는지에 영향을 준다. 커널의 OOM Killer 는 메모리 사용량과 oom_score_adj 로 점수를 매기고, kubelet 은 QoS 클래스에 따라 oom_score_adj 를 정한다.

   사례 보기
3. IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.

   Moonlight2019

   증상

   1월 18일 금요일, Moonlight API 가 가끔 오류를 냈다. 처음 오류는 Redis 데이터베이스와 연결이 안 되는 문제로 보였다. Moonlight API 는 인증된 요청마다 Redis 에서 세션을 확인한다.

   오류율 상승간헐적 연결 실패노드 NotReady서비스 중단노드 CPU 고부하

   촉발

   쿠버네티스 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 같은 노드에 배치했다. 이 파드들이 노드 CPU 를 100% 쓰자 노드 VM 이 커널 패닉으로 죽었다.

   원인

   용량 한계

   구성 요소

   파드 스케줄링과 배치리눅스 커널데이터베이스

   기여 요인

   단일 장애점미검증 가정자동화 증폭

   감지

   API 오류가 가끔 나면서 문제가 드러났다. 쿠버네티스 모니터링이 일부 노드와 파드가 응답하지 않는다고 보고했다. 노드가 CPU 100% 상태에서 커널 패닉으로 죽는다는 패턴은 Google Cloud 지원팀이 찾아냈다.

   조치

   • 주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드에 흩어 놓았다.

   후속 조치

   • Google Cloud 지원팀과 함께 노드 커널 패닉의 근본 원인을 찾아 고친다.

   교훈

   복제본을 세 개 두어도 스케줄러가 한 노드에 몰아 놓으면 그 노드가 단일 장애점이 된다. 사용자에게 응답하는 서비스에는 안티 어피니티 규칙을 넣어 파드를 여러 노드에 나눠 놓아야 한다. 팀은 처음에 클라우드 업체의 네트워크 장애를 원인으로 짐작했지만 실제 원인은 노드의 CPU 포화와 커널 패닉이었다.

   사례 보기
4. IL-0472 노드 605개 클러스터의 모든 노드에서 ARP 캐시가 넘쳐 노드와 파드 사이 통신과 DNS 조회가 끊겼다

   Tinder2019

   증상

   2019-01-08 이른 아침 Tinder 플랫폼에 오래 이어지는 장애가 났다. 노드에서 파드로 가는 통신과 DNS 조회가 실패했다.

   서비스 중단네트워크 도달 불가DNS 조회 실패

   촉발

   그날 아침 장애에 앞서 이번 장애와 관계없는 플랫폼 지연이 늘자 클러스터의 파드와 노드 수를 늘렸다. 장애 당시 노드는 605개였고, 이 수는 기본 gc_thresh3 값을 넘기에 충분했다.

   원인

   용량 한계

   구성 요소

   리눅스 커널CNI 플러그인

   기여 요인

   기본 설정 방치

   조치

   • gc_thresh1, gc_thresh2, gc_thresh3 값을 올렸다.
   • Flannel 을 재시작해 ARP 표에서 빠진 네트워크를 다시 등록했다.

   교훈

   Tinder 는 이 장애로 네트워크 구성의 한계를 알게 됐다고 정리했다. Flannel 과 VXLAN 을 쓰는 클러스터에서는 노드마다 ARP 항목이 생기고, ELB 를 거쳐 다른 노드의 파드로 가는 통신이 항목을 더 늘린다. 그래서 노드가 605개에 이르자 리눅스의 기본 gc_thresh3 값으로는 모자랐다. 이 한계를 넘으면 패킷만 버려지는 것이 아니라 Flannel 의 /24 대역이 ARP 표에서 통째로 빠져 노드와 파드 사이 통신과 클러스터 안 DNS 가 함께 멈춘다.

   사례 보기

원인별1