사례8건

8건 중 6~8번째

1. IL-0056 kops 에서 EKS 로 옮긴 뒤 AWS VPC CNI 의 SNAT 때문에 파드에서 다른 VPC 의 NLB 뒤 서비스로 가는 호출이 간헐적으로 실패했다

   MindTickle2020

   증상

   새해 첫 주말, 운영 클러스터를 kops 에서 EKS 로 옮긴 날 아침에 팀장이 전화로 플랫폼이 매우 느리게 동작한다고 알렸다. 아직 패턴은 보이지 않았고, 너무 불안정해서 계속 운영할 수 없는 상태였다.

   간헐적 연결 실패지연 시간 증가

   촉발

   운영 클러스터를 kops 에서 EKS 로 옮겼고, AWS VPC CNI 가 다른 VPC 에 있는 NLB 로 가는 파드 트래픽의 출발지 주소를 노드에서 변환했다.

   원인

   DNS·네트워크 장애

   구성 요소

   AWS VPC CNI

   기여 요인

   기본 설정 방치미검증 가정

   감지

   EKS 로 옮긴 날 팀이 플랫폼이 매우 느리게 동작하는 것을 보았다. 실패하는 호출의 패턴은 AWS 네트워크 전문가가 요청한 패킷 캡처를 하고 나서야 보였다.

   조치

   • 플랫폼이 너무 불안정해 운영을 이어 갈 수 없었으므로 EKS 이전을 되돌렸다.
   • AWS VPC CNI 에 AWS_VPC_K8S_CNI_EXTERNALSNAT=true 를 설정해 외부 SNAT 을 켰다. 이제 CNI 플러그인은 주소를 변환하지 않고 NAT 게이트웨이가 변환한다.

   후속 조치

   • AWS CNI 에 모니터링과 경보를 설정했다.

   교훈

   장애를 디버깅할 때, 특히 네트워크 문제라면 스택 전체의 구성 요소를 모두 의심해야 한다. EKS 를 원인 후보에서 일찍 뺀 탓에 귀중한 시간을 많이 잃었다. 관측 도구를 작업 흐름에 넣어야 한다. 모든 구성 요소가 서로 핑을 보내는 pinger DaemonSet 으로 이상한 연결 현상을 보고 나서야 해결에 다가갈 수 있었다. 쓰는 시스템을 알아야 한다. 팀은 EKS 로 옮기기 전에 AWS CNI 문서를 훑어보기만 하고 구현을 제대로 살피지 않았다. 내부 동작을 알았다면 디버깅 방법과 가설을 더 잘 세웠을 것이다.

   사례 보기
2. IL-0011 HAProxy 인그레스 템플릿이 백엔드 파드를 IP 순으로 정렬해 일부 파드에 요청이 몰리고 인그레스 컨테이너가 OOMKilled 됐다

   Skyscanner2019

   증상

   어느 일요일, 클러스터 사용자 한 명이 지연 시간이 올라갔다며 쿠버네티스 업무 시간 외 지원 담당을 직접 호출했다. 특히 p90 과 최댓값 지연이 높았다.

   지연 시간 증가부하 불균형OOMKilled간헐적 연결 실패

   촉발

   HAProxy 인그레스 컨트롤러를 v0.6 으로 올렸다. v0.5 문서는 sort-backends 플래그의 기본값이 false 이고 백엔드 서버를 기본으로 무작위로 섞는다고 설명했다. 그러나 템플릿이 pod_ip:port 를 키로 하는 맵을 순회할 때 Go 의 text/template 이 키 순서대로 방문해, 파드는 늘 IP 오름차순으로 설정 파일에 들어갔다. 운영 클러스터처럼 변화가 잦은 곳에서는 설정이 자주 다시 쓰였고, HAProxy 가 무중단 리로드를 하지 못해 재시작하는 일이 잦았다. 그때마다 모든 HAProxy 인스턴스가 같은 목록의 처음부터 라운드 로빈을 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러HAProxy설정 템플릿

   기여 요인

   스테이징 불일치미검증 가정초기 신호 무시

   감지

   클러스터 사용자가 p90 과 최댓값 지연이 오른 것을 보고 업무 시간 외 쿠버네티스 지원 담당을 직접 호출했다. 그 전에도 한 사용자가 파드 사이 요청 분포가 고르지 않다고 알렸지만 팀은 우선순위를 낮게 두었다.

   조치

   • 내부 배포 도구 Slingshot 의 설정을 바꿔, 영향받은 서비스의 매니페스트가 파드 IP 대신 Service VIP 를 쓰게 했다.
   • 컨트롤러가 맵에 넣은 순서를 슬라이스에 보관하고 템플릿이 그 슬라이스를 순회하도록 컨트롤러 코드와 설정 템플릿을 패치했다.
   • 패치를 샌드박스 클러스터에서 테스트한 뒤 운영 클러스터에 배포했다.

   후속 조치

   • 컨트롤러 패치를 운영에서 돌리고, 백엔드 주소는 다시 파드 IP 를 기본으로 쓴다.
   • 업스트림 프로젝트에 GitHub 이슈와 PR 을 올려 문제를 알렸다.
   • 클러스터 컴포넌트를 바꿀 때는 구체적인 동작과 조건을 염두에 두고 테스트한다.

   교훈

   클러스터 컴포넌트를 바꿀 때는 특정 동작과 조건을 염두에 두고 테스트해야 한다. 팀은 백엔드 목록이 정렬되면 hot-podding 이 생긴다는 것을 이미 알았지만, 새 플래그가 기대대로 동작하는지 충분히 테스트하지 않았다. 같은 키워드라도 언어의 한 곳에서 동작하는 방식이 다른 곳에서도 같으리라고 기대하면 안 된다. Go 의 range 와 text/template 의 range 는 맵을 순회하는 순서가 달랐다. 쿠버네티스 클러스터의 작은 컴포넌트 하나만 바꿔도 클러스터 사용자와 고객에게 큰 피해를 줄 수 있다.

   사례 보기
3. IL-0075 클러스터가 EC2 인스턴스 약 290대로 커지자 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하면서 API 서버가 CPU 와 메모리를 다 써 쿠버네티스 컨트롤 플레인을 쓸 수 없게 됐다.

   Civis Analytics2019

   증상

   스크립트 실행 기반을 쿠버네티스로 옮긴 Croquet 를 사내에 공개한 뒤, 개발자들은 kubectl 명령이 느리다고 했다. 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다.

   컨트롤 플레인 지연컨트롤 플레인 무응답지연 시간 증가오류율 상승DNS 조회 실패

   촉발

   자체 인프라 Bocce 에서 쿠버네티스로 옮긴 스크립트 실행 기반 Croquet 를 2018년 9월 사내에 공개했다. 대량의 스크립트가 몰리면서 클러스터가 EC2 인스턴스 약 290대로 커졌고, 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하는 부하도 함께 늘었다.

   원인

   용량 한계

   구성 요소

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

   기여 요인

   한계 미인지미검증 가정모니터링 사각지대용량 계획 부재

   감지

   개발자들이 kubectl 명령이 느리다고 했고, 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다. 마스터 노드의 CPU 사용률이 높았고, 조사해 보니 API 서버 컨테이너 세 개가 CPU 를 꽉 채워 쓰고 있었다. 당시 팀이 볼 수 있던 지표는 마스터 노드 CPU 의 CloudWatch 지표와 Datadog 의 컨테이너별 CPU, 메모리 지표였다. API 요청 처리량과 5xx 오류율과 요청 지연은 볼 수 없었다.

   조치

   • 사내 사용자들을 예전 인프라로 되돌려 클러스터를 안정시켰다.
   • 마스터 노드를 m4.large 세 대에서 m4.4xlarge 세 대로 키웠다.
   • 노드마다 도는 Datadog 에이전트가 서비스 메타데이터를 얻으려고 API 서버를 폴링하지 않도록 Datadog 설정을 바꿨다.
   • 상태를 바꾸지 않는 요청의 max-requests-inflight 한도를 400 에서 1200 으로 올렸다.
   • etcd 의 EBS 볼륨을 20 GB 에서 100 GB 로 늘려 IOPS 를 100 에서 300 으로 올렸다.
   • 스크립트의 DNS 정책을 ClusterFirst 에서 Default 로 바꿔 DNS 타임아웃을 줄였다.

   후속 조치

   • Kops 가 안전한 이전을 지원하면 etcd 를 2.2.1 에서 3.x 로 올린다.
   • 스크립트가 클러스터 안의 다른 워크로드와 통신할 수 있도록 DNS 타임아웃 문제를 근본적으로 해결한다.

   교훈

   가장 큰 실수는 쿠버네티스가 모든 것을 알아서 해 준다고 가정한 것이었다. 쿠버네티스는 노드 5,000대와 파드 100,000개를 지원한다고 하지만, 그 규모에 이르려면 손봐야 할 설정이 많다. 클러스터에 넣는 서드파티 도구, 특히 DaemonSet 을 조심해야 한다. 많은 도구가 보통 규모에 맞춰 만들어졌고 큰 규모에서는 시험되지 않았다. 클러스터 상태를 watch 하는 서비스가 데이터를 지나치게 많이 가져가도록 설계되면 규모 문제가 생긴다. kube2iam 은 모든 파드의 메타데이터를 메모리에 들고 있다가 메모리가 바닥났고, Fluentd Kubernetes Metadata Filter 플러그인도 같은 문제가 있다. 대개 설정 하나로 고칠 수 있지만, 부하 테스트를 해 보기 전에는 잘 드러나지 않는다.

   사례 보기

원인별4