사례36건

36건 중 29~33번째

1. IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.

   Grafana Labs2020

   증상

   2020년 3월 16일 11:31 UTC에 SLO 기반 알림이 당직 엔지니어를 호출했다. 런던 리전 Hosted Prometheus 로 들어오는 쓰기의 약 20%가 실패하고 있었다. 문제는 이미 11분 전에 시작된 상태였다.

   오류율 상승간헐적 타임아웃

   촉발

   예약된 쿠버네티스 버전 업그레이드가 etcd 리더가 돌던 노드를 정상 종료 절차 없이 갑자기 종료했다.

   원인

   소프트웨어 결함

   구성 요소

   etcd노드 풀

   기여 요인

   기본 설정 방치파괴적 변경 보호 장치 부재

   감지

   SLO 기반 알림이 11:31 UTC에 당직 엔지니어를 호출했다. 장애가 시작되고 11분이 지난 시점이었다. 오류율이 20% 수준이었기 때문에 이대로 두었다면 월간 SLA 를 넘기기까지 약 18시간이 걸렸을 것이다.

   조치

   • 11:32 UTC에 영향받은 distributor 를 재시작했고, 오류가 멈췄다.

   후속 조치

   • Cortex 의 etcd 클라이언트 설정에 gRPC keepalive 프로브를 켠다. DialKeepAliveTime 은 10초, DialKeepAliveTimeout 은 DialTimeout 의 두 배로 두고 PermitWithoutStream 을 true 로 한다.
   • 쿠버네티스 업그레이드 절차를 고쳐, etcd operator 가 관리하는 etcd 파드까지 포함해 파드와 머신을 정상 종료 절차로 내리게 한다.

   교훈

   노드가 죽으면 TCP 연결이 정상적으로 닫히지 않고 멈춘 채 남을 수 있다. etcd 클라이언트에 keepalive 를 설정하지 않으면 새 리더가 뽑힌 뒤에도 클라이언트는 죽은 연결을 계속 쓴다. 노드를 내리는 업그레이드 스크립트는 operator 가 관리하는 파드까지 정상 종료할 수 있어야 한다. 장애 대응과 복구, 사후 분석 동안 Grafana Loki 로 로그를 빠르게 뒤질 수 있어서 복구 시간이 줄었다.

   사례 보기
2. IL-0013 노드 RAM 을 절반으로 줄이자 conntrack 테이블이 가득 차 집계 서비스에 연결 리셋과 오류가 늘었다

   loveholidays2020

   증상

   서비스 구조를 바꾸고 노드 풀 크기를 조정하고 하위 서비스를 샤딩한 직후, 집계 서비스에 여러 연결 문제가 생기고 오류율이 올라갔다.

   연결 리셋오류율 상승간헐적 연결 실패

   촉발

   집계 서비스가 도는 노드의 RAM 을 절반으로 줄였고, 하위 서비스를 샤딩하면서 추적해야 할 연결 수는 두 배가 됐다. conntrack_max 는 노드 RAM 에 비례하므로 노드가 추적할 수 있는 연결 수는 줄고 추적할 연결은 늘었다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블kube-proxy노드 풀HAProxy

   기여 요인

   한계 미인지용량 계획 부재한계 경보 부재

   감지

   팀은 먼저 서비스의 연결 문제와 오류율 상승을 알아챘다. HAProxy 가 보고하는 연결 리셋 오류가 계속 늘었고, 팀은 node_nf_conntrack_entries 를 node_nf_conntrack_entries_limit 과 겹쳐 보고 일부 노드의 conntrack 테이블이 바닥난 것을 확인했다.

   조치

   • 집계 서비스를 RAM 이 더 큰 노드에 배치했다.
   • 노드 하나에 뜨는 집계 서비스 파드 수를 제한했다.

   후속 조치

   • conntrack 사용률이 75% 를 넘으면 경보가 가도록 Prometheus 쿼리 (node_nf_conntrack_entries / on (pod) node_nf_conntrack_entries_limit / on (pod) group_right kube_pod_info) > 0.75 로 경보 규칙을 만들었다.

   교훈

   쿠버네티스 노드의 conntrack_max 는 노드 RAM 에 비례해 정해진다. 부하가 큰 애플리케이션은 특히 작은 노드에서 conntrack_max 를 쉽게 넘겨 연결 리셋과 타임아웃을 일으킨다. 노드를 작게 바꾸면 추적할 수 있는 연결 수도 함께 줄어든다. conntrack 사용률은 지표로 보고 경보를 걸어 둬야 한다.

   사례 보기
3. 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 를 효율적으로 쓰고 자원 활용도도 높아지지만, 노드 하나가 죽을 때 더 많은 파드가 함께 내려간다.

   사례 보기
4. IL-0149 2019-09-28 07:20 UTC 이전에 만든 VMSS 기반 AKS 클러스터의 업그레이드가 PlatformImageNotFound 오류로 실패했다.

   Microsoft Azure2019

   증상

   2019-09-28 07:20 UTC 부터 Virtual Machine Scale Sets 위의 AKS 클러스터에서 클러스터 업그레이드를 시도하면 실패 알림이 왔다.

   업그레이드 정체

   촉발

   최근 서비스 업데이트가 백엔드 서비스의 인스턴스를 비정상 상태로 만들어 요청이 끝나지 못했다. 이 상태에서 고객이 클러스터 업그레이드를 시도했다.

   원인

   배포 결함

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   –

   감지

   고객은 클러스터를 업그레이드하려 할 때 실패 알림을 받았다.

   조치

   • az vmss update 명령으로 스케일 세트 이미지의 version 을 "2019.09.25" 로, Sku 를 "aks-ubuntu-1604-201909" 로 바꾼 뒤 업그레이드를 다시 실행하는 방법을 공개했다.
   • AKS 팀과 VMSS 팀이 영향받은 클러스터를 손으로 완화했다.
   • 모든 리전에 핫픽스를 배포해 2019-10-15 에 마쳤다.

   사례 보기
5. IL-0039 CentOS 저장소 재구성으로 kops nodeup 에 하드코딩된 container-selinux 패키지 주소가 깨져 새 워커 노드가 클러스터에 합류하지 못했다

   FREE NOW2019

   증상

   Prelive 클러스터에 배포하던 개발자들이 #ask-platform 슬랙 채널에 배포가 실패한다고 알렸다. 16:00 에 첫 제보가 왔고 16:06 에 두 번째 제보가 왔다.

   파드 Pending노드 증설 실패

   촉발

   CentOS 저장소가 재구성되면서 container-selinux 패키지의 고정 다운로드 주소를 더는 쓸 수 없게 됐다. kops 는 nodeup 에 이 주소를 하드코딩해 두었고, docker-ce 를 실행하려면 이 패키지가 필요했다.

   원인

   의존성 장애

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   모니터링 사각지대

   감지

   팀은 개발자들이 배포가 실패한다며 #ask-platform 슬랙 채널에 도움을 요청하면서 장애를 알게 됐다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다.

   조치

   • Prelive 노드에서 패키지를 손으로 내려받아 부트스트랩을 끝내고 노드를 클러스터에 합류시켰다.
   • 클러스터 AMI 를 Amazon Linux 2 에서 Debian 으로 바꿔 Prelive 에서 확인한 뒤 모든 클러스터에 적용했다.

   후속 조치

   • 노드가 클러스터에 합류하지 못하는 상황을 알려 주는 알림을 만든다. cluster-autoscaler 가 이 정보를 갖고 있을 수 있다.
   • 노드 시작에 필요한 외부 의존성을 문서로 정리하고 줄일 방법을 찾는다.
   • kops 가 이 문제를 고치면 AMI 를 Amazon Linux 2 Minimal 로 되돌린다.
   • 클러스터 노드 문제 해결 문서를 보강해, 부트스트랩 중에 무슨 일이 일어나고 로그가 어디에 남는지 적는다.

   교훈

   kops 와 Jenkins 로 클러스터 변경을 적용하는 흐름은 잘 동작했다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다. 일부 오토스케일링 그룹의 워커 인스턴스 수와 쿠버네티스에 등록된 워커 노드 수가 오랫동안 달랐는데도 아무도 알아채지 못한 것은 잘못이었다. 문제가 이어지는 동안 운영 환경의 스팟 인스턴스가 대량으로 종료되지 않은 것과 업무 시간에 발견한 것은 운이 좋았다.

   사례 보기

원인별9