사례17건

17건 중 11~15번째

1. IL-0194 kube-apiserver 재시작 뒤 Vector DaemonSet 의 파드 list 요청이 한꺼번에 몰려 etcd 메모리가 세 배 가까이 늘고 마스터 노드가 연쇄적으로 재시작했다.

   Palark2023

   증상

   일상적인 kube-apiserver 재시작 직후 etcd 메모리 사용량이 거의 세 배로 치솟았고, 그 여파로 모든 마스터 노드가 연쇄적으로 재시작했다. 고객사의 운영 클러스터였다.

   컨트롤 플레인 무응답데이터베이스 과부하

   촉발

   일상적인 kube-apiserver 재시작 뒤, Vector 로그 수집기 DaemonSet 의 파드 전부가 캐시를 다시 채우려고 한꺼번에 파드 list 요청을 보냈다.

   원인

   용량 한계

   구성 요소

   etcd쿠버네티스 API 서버텔레메트리 에이전트

   기여 요인

   한계 미인지기본 설정 방치

   감지

   kube-apiserver 재시작 직후 마스터 노드 전체 메모리와 etcd 메모리 그래프가 치솟고 마스터 노드가 연쇄적으로 재시작하면서 알았다. 원인이 된 DaemonSet 은 감사 로그를 보고 찾았다.

   조치

   • limit-list-custom 이라는 PriorityLevelConfiguration 을 만들어 요청 대기열을 설정했다. 값은 문서의 표준 설정을 그대로 썼다.
   • 같은 이름의 FlowSchema 를 만들어, 이 DaemonSet 서비스 어카운트가 보내는 파드 list 와 get 요청을 그 대기열로 보냈다.

   후속 조치

   • 쿠버네티스 Rust 라이브러리에 resourceVersion 설정을 넣는 PR 을 냈다.
   • Vector 로그 수집기 쪽에 이 문제를 고치는 PR 을 열었다.
   • Cilium CNI 에서도 비슷한 문제를 찾아 같은 방법으로 해결했다.

   교훈

   etcd 는 필드 셀렉터와 레이블 셀렉터를 모르기 때문에, kube-apiserver 에는 가벼워 보이는, 필터를 건 list 요청도 etcd 에서는 그 종류의 객체 전체를 읽는 일이 된다. 데이터가 꼭 최신이어야 하는 컨트롤러가 아니라면 resourceVersion=0 으로 kube-apiserver 캐시에서 읽게 할 수 있다. 다만 kube-apiserver 가 여러 대면 인스턴스마다 다른 데이터를 받을 수 있다. 여러 파드가 한꺼번에 보내는 요청은 Priority and Fairness 로 대기열에 넣어 kube-apiserver 와 etcd 를 지킬 수 있다. 위험한 것은 파드 요청만이 아니어서 Cilium CNI 에서도 비슷한 문제가 나왔다.

   사례 보기
2. IL-0015 GKE 가 노드마다 IP 256개를 미리 잡아 /16 파드 주소 범위가 바닥나고 노드 증설과 배포가 멈췄다

   loveholidays2020

   증상

   동료가 슬랙으로 애플리케이션 배포가 오래 걸린다고 알려 왔다. 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 머물러 있었다. 새 파드의 절반쯤은 트래픽을 받고 있었고 나머지 절반은 Pending 상태였다.

   파드 PendingIP 주소 고갈노드 증설 실패

   촉발

   클러스터의 노드 수가 256개에 이르렀다. GKE 는 노드당 최대 파드 수를 기본 110 으로 두고, 그 두 배 이상을 담을 수 있는 서브넷 마스크를 노드마다 미리 할당한다. 노드 하나가 IP 256개를 차지하므로 /16 보조 범위의 65,536개 주소가 노드 256개에서 바닥났다.

   원인

   용량 한계

   구성 요소

   VPC 서브넷 또는 파드 주소 범위클러스터 오토스케일러노드 풀

   기여 요인

   기본 설정 방치한계 미인지

   감지

   동료가 슬랙으로 배포가 오래 걸린다고 알려 왔다. 확인해 보니 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 멈춰 있었다.

   조치

   • 파드가 많이 뜨지 않을 노드 풀에서 노드당 최대 파드 수를 줄여 전체 IP 사용량을 약 30% 줄였다.
   • 일부 노드 풀의 인스턴스 크기를 키워 노드당 더 많은 파드를 돌리게 했다.

   후속 조치

   • 상태 저장 애플리케이션, 캐시, 보안을 강화한 워크로드처럼 노드에 파드가 많이 뜨지 않는 노드 풀은 노드당 최대 파드 수를 낮춰 운영한다.
   • 일부 노드 풀에 더 큰 인스턴스를 쓴다.

   교훈

   GKE 는 기본으로 노드마다 IP 256개를 할당한다. /16 처럼 큰 범위도 노드가 256개면 바닥난다. 노드당 최대 파드 수가 파드 IP 소비량을 정하므로, 노드 풀마다 실제로 띄울 파드 수에 맞춰야 한다. 큰 노드를 쓰면 IP 를 효율적으로 쓰고 자원 활용도도 높아지지만, 노드 하나가 죽을 때 더 많은 파드가 함께 내려간다.

   사례 보기
3. IL-0033 kube-dns 파드 사이의 트래픽 불균형과 DNS 초당 패킷 한도 때문에 외부 DNS 조회가 많은 여러 서비스의 지연 시간이 20초까지 늘었다

   Airbnb2019

   증상

   한 서비스의 지연 시간 그래프에 5월 10일부터 스파이크가 보이기 시작했다. 처음에는 1초 안팎까지 튀었고, 이어서 5초, 다시 20초로 올라간 뒤 꽤 오랫동안 그 수준에 머물렀다.

   지연 시간 증가간헐적 타임아웃부하 불균형DNS 조회 실패

   촉발

   여러 서비스가 외부 DNS 조회를 많이 보냈고, 그 질의가 모두 kube-dns 를 거쳤다.

   원인

   용량 한계

   구성 요소

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

   기여 요인

   기본 설정 방치

   감지

   문제는 서비스의 지연 시간 그래프에서 처음 드러났다. 같은 모양이 여러 서비스에서 나타나자 팀은 공통점을 찾았고, kube-dns 파드별 질의량을 비교해 불균형을 찾아냈다.

   교훈

   기본 설정에서 파드는 클러스터 IP 로 DNS 서버를 찾고, dnsPolicy 기본값인 ClusterFirst 때문에 외부 이름 조회도 kube-dns 를 먼저 거친다. 쿠버네티스 DNS 해석이 필요 없는 파드는 dnsPolicy 를 Default 로 두거나, None 으로 두고 세부 값을 직접 정할 수 있다. iptables 는 로드 밸런서가 아니어서 클러스터 IP 뒤의 파드에 부하를 고르게 나누지 못한다. 발표자들은 DNS 정책을 초기부터 자주 확인하고 용도에 맞는 정책을 쓰라고 했다.

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

   사례 보기

원인별1