IL-0103 Tetrate (unnamed U.S. federal customer) · 2025-02-26 (게시일)kubernetesaws
Tetrate 의 고객인 미국 연방 기관은 Istio 를 쓰는 EKS 클러스터 30여 개의 노드 AMI 를 업데이트하고 있었다. 이 클러스터들은 전 세계 수백만 사용자에게 서비스하며 형제 클러스터끼리 트래픽을 미러링한다. 유지보수 중인 클러스터는 트래픽에서 빠지는데, 그중 한 클러스터에서 사이드카가 주입된 워크로드가 CrashLoopBackOff 에 빠졌다. 트래픽은 없었지만 형제 클러스터 하나를 못 쓰게 되자 전체 복원력이 약해졌다. 엄격한 보안 규정과 부족한 운영 인프라 때문에 대체 클러스터를 빨리 띄우기도 어려웠고, 장애 등급은 Severity 1 이었다.
이 구성에서 Istio 는 CA 역할을 외부 서비스에 맡겼다. 사이드카의 istio-agent 가 인증서 서명을 요청하면 istiod 가 이를 외부 CA 에 넘기고, CA 가 서명한 인증서를 받아 온다. 노드 업데이트로 수백 개의 파드가 동시에 뜨자 CA 가 갑자기 몰린 인증서 요청을 감당하지 못했다. istiod 의 기본 CA 요청 타임아웃 10초가 문제를 키워, 실패한 요청이 한꺼번에 다시 몰리는 썬더링 허드 현상이 생겼고, 사이드카 프록시는 인증서를 받지 못한 채 중단됐다. 원인은 Istio 자체의 오작동이 아니라 Istio 가 의존하는 외부 CA 의 과부하였다.
고객 팀은 다른 클러스터 업그레이드에 매달려 있어 Tetrate 지원에 Severity 1 티켓을 열었다. 6분 안에 Tetrate 엔지니어가 로그를 보기 시작했고, 20분 안에 전문가 두 명이 더 실시간 디버깅에 합류했다. 팀은 istiod 레플리카를 줄이고 실패한 CSR 을 지우고 파드를 단계적으로 재시작해 1시간 안에 문제를 해결했다.
미국 연방 기관 고객이 Istio 를 쓰는 EKS 클러스터 30여 개의 노드 AMI 를 업데이트하던 중, 그중 한 클러스터에서 사이드카가 주입된 워크로드가 시작하지 못하고 CrashLoopBackOff 에 빠졌다.
처음에는 istiod 초기화가 유난히 오래 걸리며 istio-system 28m Warning Unhealthy pod/istiod-74b69db89d-226lp Readiness probe failed: HTTP probe failed with status code: 503 이벤트가 나왔다. 인젝터 웹훅도 쓸 수 없어 파드 생성이 Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": no endpoints available for service "istiod" 오류로 실패했다.
istiod 지연은 잠깐이었다. istiod 가 뜨고 사이드카가 주입된 뒤에도 파드는 ready 가 되지 못했다. 사이드카 프로세스가 동작하기 전에 중단됐고, 사이드카 로그에는 Agent draining Proxy 다음에 warn ca ca request failed, starting attempt 1 in 99.993416ms 와 warn Aborting proxy 가 찍혔다.
그런데 CSR 이벤트는 The CSR has been signed 처럼 모두 성공으로 보였다. CA 요청이 처리되는데도 사이드카가 실패하자 팀은 외부 CA 를 의심했고, CA 가 동시에 뜨는 수백 개 파드의 인증서 요청을 감당하지 못하는 것을 확인했다.
증상 ? 컨테이너 재시작 반복프로브 실패
노드 AMI 업데이트 중 한 클러스터에서 사이드카가 주입된 워크로드가 CrashLoopBackOff 로 시작하지 못했다. 처음 보인 신호는 istiod 초기화가 유난히 오래 걸리며 나온 Readiness probe 실패 이벤트였다.
–
복잡한 인프라 장애를 진단할 때는 Istio 만이 아니라 서비스 메시를 둘러싼 구성 요소 전체를 봐야 한다. CSR 이벤트가 모두 성공으로 보여도 사이드카 로그에 CA 요청 실패가 있으면 외부 CA 의 처리 능력을 의심해야 한다. 노드 이미지 업데이트처럼 파드가 한꺼번에 다시 뜨는 작업을 하면 외부 CA 에 요청이 몰려, istiod 의 기본 CA 타임아웃 10초 안에 응답을 받지 못할 수 있다.
같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지