사례3건

3건 중 1~3번째

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-0578 HAProxy 로드 밸런서를 거치는 정적 콘텐츠 전송이 수십 초씩 늦어졌다

   GMO Pepabo2020

   증상

   운영 환경에서 정적 콘텐츠 전송이 수십 초 단위로 늦어졌다.

   지연 시간 증가

   원인

   용량 한계

   구성 요소

   HAProxy리눅스 커널클라우드 로드 밸런서

   기여 요인

   기본 설정 방치

   조치

   • 동료 엔지니어가 sysctl net.ipv4.tcp_mem 을 조정해 정적 콘텐츠 전송 지연을 가라앉히고 장애를 복구했다.

   교훈

   net.ipv4.tcp_mem 의 기본값은 부팅 때 RAM 크기로 정해지므로 RAM 이 작은 VM 에서는 한계가 낮게 잡힌다. tcp_mem 은 시스템 전체의 TCP 소켓에 걸리는 페이지 단위의 값이고, 소켓 하나의 버퍼 크기를 바이트 단위로 정하는 net.ipv4.tcp_rmem, net.ipv4.tcp_wmem 과는 다른 설정이다. TCP: out of memory 로그가 가리키는 TCP oom 은 프로세스를 SIGKILL 로 끝내는 OOM Killer 와 관계가 없다. TCP oom 로그가 나왔을 때는 송수신 제한도 함께 일어나고 있다. 문제를 찾거나 감시할 때는 /proc/net/sockstat 의 TCP mem, /proc/net/protocols 의 press, /proc/net/netstat 의 TCPMemoryPressures, TCPMemoryPressuresChrono, TCPAbortOnMemory, OfoPruned, PruneCalled, TCPRcvQDrop, TCPAbortFailed 를 본다.

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