사례9건

9건 중 6~9번째

1. IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다

   DFDS2022

   증상

   2022-10-31 13:45 UTC 에 팀은 계획된 vpc-cni EKS 애드온 업그레이드를 배포 파이프라인으로 시작했다. 14:10 에 파이프라인이 업그레이드 중 타임아웃으로 실패했다. 45개 aws-node 파드 가운데 약 10개만 업그레이드됐다. 5개는 Terminating 에 멈췄고, 나머지 30개는 업그레이드를 시도하지도 못했다.

   노드 NotReady업그레이드 정체간헐적 타임아웃간헐적 연결 실패

   촉발

   매일 도는 노드 롤오버가 2022-10-31 07:30 UTC 에 가장 최신 EKS 노드 AMI 인 v20221027 을 가져와 기존 노드를 이 AMI 로 만든 새 노드로 바꿨다. 이 AMI 는 나중에 커널 문제로 회수됐다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지리눅스 커널kubeletAWS VPC CNI노드 런치 템플릿Terraform

   기여 요인

   단계적 배포 부재자동화 증폭장애 중첩모니터링 사각지대헬스 프로브 부재

   감지

   07:30 롤오버 뒤 14:10 에 vpc-cni 업그레이드 파이프라인이 타임아웃으로 실패했다. 팀은 롤오버 7시간 뒤인 14:30 에 노드가 NodeNotReady 를 오가는 것을 보고 이상을 알았다. 감지까지 7시간이 걸렸다. 알림은 NodeNotReady 이벤트와 소켓 증가를 잡지 못했다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾고 나서 원인을 알았다.

   조치

   • Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 vpc-cni 업그레이드를 끝냈다. 모두 15대를 지웠다.
   • 특정 AMI 를 지정할 수 있도록 인프라 모듈의 terraform 을 고치고 테스트해 master 브랜치에 머지했다.
   • 파이프라인으로 EC2 Auto Scaling 그룹 launch configuration 의 AMI 를 이전의 정상 버전으로 되돌려 노드를 다시 만들었다.

   후속 조치

   • 각 팀에 readiness, liveness 프로브를 쓰자고 제안한다.
   • readiness, liveness 프로브 적용 현황을 보여 주는 대시보드를 만든다.
   • readiness, liveness 프로브와 그 쓸모를 설명하는 위키 글을 쓴다.
   • 인프라 모듈에서 특정 AMI 를 지정할 수 있게 고친다.
   • 최신 AMI 를 바로 받을지, 새 AMI 를 배포 전에 어떻게 시험할지 논의하는 자리를 잡는다.
   • 비정상적인 NodeNotReady 이벤트나 소켓 사용 증가를 잡는 알림을 만든다.
   • 팀 안에 Kubernetes 학습 과정을 만든다.
   • 노드 로그를 중앙에서 모은다.
   • 나와 있는 최신 AMI 를 조회하는 Prometheus exporter 를 만들고, 이를 쓰는 대시보드와 알림도 만든다.

   교훈

   새 AMI 를 배포한 날에는 다른 컴포넌트 업그레이드를 매우 조심해야 한다. 이번에는 새 노드 AMI 를 쓴 날 EKS 컴포넌트도 함께 올리면서 원인을 가리기 어려웠다. 장애나 문제가 생겼을 때 각 팀과 소통하는 경로도 개선해야 한다. 문제를 알린 팀에게서 자세한 내용을 받기 어려웠고, 팀별 당직 호출 경로도 없었다. 팀이 Kubernetes 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다.

   사례 보기
2. IL-0105 VPC CNI 교체로 ALB 에서 타깃 그룹이 떨어져 나가 쿠버네티스 클러스터의 모든 서비스가 503 을 냈다

   DFDS2021

   증상

   2021-06-22 08:29 UTC 에 알림이 울렸다. 쿠버네티스 클러스터로 들어오는 트래픽이 모두 실패했고, 모든 서비스가 503 을 냈다.

   서비스 중단오류율 상승

   촉발

   EKS 애드온을 kubectl 대신 Terraform 으로 관리하려는 리팩터링과 정리 작업 중에 파이프라인이 VPC CNI 를 교체했다.

   원인

   설정 변경

   구성 요소

   AWS VPC CNI클라우드 로드 밸런서Terraform

   기여 요인

   미검증 가정설정 테스트 부재

   감지

   08:29 UTC 에 알림으로 감지했다. 파이프라인이 VPC CNI 를 교체한 지 8분 뒤였다. 08:32 에는 고객도 문제를 알려 왔다.

   조치

   • infrastructure-modules 참조를 되돌리는 수정을 커밋했다.
   • AWS API 타임아웃으로 멈춘 파이프라인을 다시 돌렸다.
   • 파이프라인이 타깃 그룹을 ALB 에 다시 붙였다.

   후속 조치

   • ALB 의 등록 해제 지연을 기본값 300초로 되돌린다.
   • 노드 교체 스크립트가 교체 전에 ALB 등록 해제 지연을 잠시 0 으로 낮추도록 고친다.
   • Ingress 테스트 스위트를 만든다.

   교훈

   팀은 등록 해제 지연을 주로 성능 측면에서만 보고 바꿨다. 중요한 파이프라인 실행은 끝날 때까지 지켜봐야 한다. 알림은 모든 사람이 받고 대응해야 한다. 뜻이 분명하지 않은 알림 문구는 고쳐 써야 한다.

   사례 보기
3. 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 문서를 훑어보기만 하고 구현을 제대로 살피지 않았다. 내부 동작을 알았다면 디버깅 방법과 가설을 더 잘 세웠을 것이다.

   사례 보기
4. IL-0057 EKS 노드의 SNAT 과정에서 conntrack 경합으로 바깥으로 나가는 TCP 연결이 1초나 3초씩 늦어져, 서비스 간 호출이 많은 서비스의 p99 지연이 늘었다.

   Prezi2019

   증상

   Nginx 기반 리버스 프록시를 쿠버네티스로 옮긴 뒤, Prometheus 가 몇몇 서비스의 p99 지연 증가에 알림을 보냈다. 그래프에서 p99 지연은 7/24 부터 올라가 있었다.

   지연 시간 증가간헐적 타임아웃

   촉발

   리버스 프록시를 전용 ElasticBeanstalk 머신에서 공용 EKS 워커 노드로 옮기자, 프록시가 다른 서비스로 보내는 패킷이 노드에서 iptables 규칙에 따라 SNAT 를 거치게 되었다.

   원인

   DNS·네트워크 장애

   구성 요소

   conntrack 테이블AWS VPC CNI리눅스 커널노드 운영체제 이미지

   기여 요인

   기본 설정 방치미패치 알려진 버그

   감지

   Prometheus 가 몇몇 서비스의 p99 지연 증가에 알림을 보냈다. 예전처럼 평균 응답 시간만 봤다면 꼬리 지연만 오른 이번 문제는 십중팔구 놓쳤을 것이다.

   조치

   • 지연이 생기는 곳을 찾으려고 AWS X-Ray 추적을 붙이고, 추적에 $upstream_connect_time 속성을 더했다.
   • 해당 서비스의 파드를 더 많은 노드에 더 많이 띄웠다. 지연은 줄었지만 사라지지 않았다.
   • AWS VPC CNI 에 AWS_VPC_K8S_CNI_EXTERNALSNAT=true 를 설정해 노드에서 SNAT 를 껐다.

   교훈

   쿠버네티스 같은 복잡한 시스템을 디버깅할 때는 관측 가능성이 핵심이다. 평균 응답 시간 대신 p99 를 보고 있었기에 문제를 알아챘고, 추적을 붙여 느린 요청의 특징을 알게 되자 원인 가까이 갈 수 있었다. 실제 해법을 찾으려면 SNAT 가 어떻게 동작하는지, EKS 내부와 amazon-vpc-cni-k8s 플러그인이 어떤 역할을 하는지까지 이해해야 했다. EKS 에서는 노드 AMI 의 iptables 가 무작위 포트 할당을 지원하지 않을 수 있고, 그때는 외부 SNAT 설정이 대안이 된다.

   사례 보기

원인별4