{"id":"IL-0103","org":"Tetrate (unnamed U.S. federal customer)","date":"2025-02-26","docs":[],"title":{"en":"During an EKS node AMI update, Istio sidecars crash-looped because hundreds of pods restarting at once overloaded the external certificate authority behind istiod","ko":"EKS 노드 AMI 업데이트로 파드가 한꺼번에 다시 뜨자 인증서 요청이 몰린 외부 CA 가 과부하에 걸려 Istio 사이드카가 CrashLoopBackOff 에 빠졌다."},"domain":["kubernetes","aws"],"impact":{"scope":"One of more than 30 Istio EKS clusters: sidecar-injected workloads could not start; the cluster was isolated from traffic for maintenance at the time","users":"The clusters serve millions of users worldwide; the affected cluster carried no active traffic","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When a mesh hands certificate signing to an external CA, every pod start becomes a signing request to that CA, so a mass restart such as a node image rollout can overload it. Sidecars then abort under istiod's 10-second default CA timeout even though the CSRs are eventually signed. Restarting pods in controlled batches keeps the request rate within what the CA can handle.\n\nThe author's point is that diagnosing such a failure means looking at the whole service mesh ecosystem, including its external dependencies, not only Istio.","ko":"복잡한 인프라 장애를 진단할 때는 Istio 만이 아니라 서비스 메시를 둘러싼 구성 요소 전체를 봐야 한다. CSR 이벤트가 모두 성공으로 보여도 사이드카 로그에 CA 요청 실패가 있으면 외부 CA 의 처리 능력을 의심해야 한다. 노드 이미지 업데이트처럼 파드가 한꺼번에 다시 뜨는 작업을 하면 외부 CA 에 요청이 몰려, istiod 의 기본 CA 타임아웃 10초 안에 응답을 받지 못할 수 있다."},"related":[],"sources":[{"url":"https://tetrate.io/blog/tetrate-solves-a-critical-production-issue-on-a-cluster-serving-millions-of-users","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"A U.S. federal customer of Tetrate runs more than 30 Amazon EKS clusters with Istio and mirrors traffic across sibling clusters, isolating a cluster from traffic while it is maintained. During an update of the node AMIs, one cluster's sidecar-injected workloads went into CrashLoopBackOff. The cluster had no active traffic, but losing a sibling cluster weakened resiliency, and strict security compliance and limited production infrastructure made a fallback cluster hard to deploy quickly. With its own team busy upgrading the other clusters, the customer raised a Severity 1 ticket with Tetrate Support; a Tetrate engineer was reading logs within six minutes, and two more joined a live debugging session within 20 minutes.\n\nIn this setup Istio offloaded the certificate authority role to an external service: each sidecar's istio-agent asked for a signed certificate, istiod passed the request to the external CA, and the CA returned the signed certificate. Because the CSRs were being processed but the sidecars still failed, the team suspected the custom CA, and found it overwhelmed by the sudden flood of certificate requests from hundreds of pods starting at once. istiod's default CA request timeout of 10 seconds made the thundering herd worse.\n\nTetrate engineers temporarily reduced istiod from 40 replicas to 1 to slow Istio's internal processing and ease the load on the CA, found and deleted the many CSRs stuck in the Approved, Failed state, and restarted pods gradually instead of all at once. The issue was resolved in less than an hour. The write-up says the root cause was not an Istio malfunction but the overloaded external CA.","ko":"Tetrate 의 고객인 미국 연방 기관은 Istio 를 쓰는 EKS 클러스터 30여 개의 노드 AMI 를 업데이트하고 있었다. 이 클러스터들은 전 세계 수백만 사용자에게 서비스하며 형제 클러스터끼리 트래픽을 미러링한다. 유지보수 중인 클러스터는 트래픽에서 빠지는데, 그중 한 클러스터에서 사이드카가 주입된 워크로드가 CrashLoopBackOff 에 빠졌다. 트래픽은 없었지만 형제 클러스터 하나를 못 쓰게 되자 전체 복원력이 약해졌다. 엄격한 보안 규정과 부족한 운영 인프라 때문에 대체 클러스터를 빨리 띄우기도 어려웠고, 장애 등급은 Severity 1 이었다.\n\n이 구성에서 Istio 는 CA 역할을 외부 서비스에 맡겼다. 사이드카의 istio-agent 가 인증서 서명을 요청하면 istiod 가 이를 외부 CA 에 넘기고, CA 가 서명한 인증서를 받아 온다. 노드 업데이트로 수백 개의 파드가 동시에 뜨자 CA 가 갑자기 몰린 인증서 요청을 감당하지 못했다. istiod 의 기본 CA 요청 타임아웃 10초가 문제를 키워, 실패한 요청이 한꺼번에 다시 몰리는 썬더링 허드 현상이 생겼고, 사이드카 프록시는 인증서를 받지 못한 채 중단됐다. 원인은 Istio 자체의 오작동이 아니라 Istio 가 의존하는 외부 CA 의 과부하였다.\n\n고객 팀은 다른 클러스터 업그레이드에 매달려 있어 Tetrate 지원에 Severity 1 티켓을 열었다. 6분 안에 Tetrate 엔지니어가 로그를 보기 시작했고, 20분 안에 전문가 두 명이 더 실시간 디버깅에 합류했다. 팀은 istiod 레플리카를 줄이고 실패한 CSR 을 지우고 파드를 단계적으로 재시작해 1시간 안에 문제를 해결했다."},"trigger":{"en":"Updating the EKS node AMIs, which started hundreds of sidecar-injected pods at the same time.","ko":"EKS 노드 AMI 업데이트로 수백 개의 새 파드가 동시에 떠서 외부 CA 로 인증서 요청이 한꺼번에 몰렸다."},"severity":"sev1","symptoms":["crash-loop","readiness-probe-failures"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Sidecar-injected workloads in the updated cluster failed to start and showed CrashLoopBackOff; the customer raised a Severity 1 ticket and a Tetrate engineer was reviewing logs within six minutes.","ko":"노드 AMI 업데이트 중 한 클러스터에서 사이드카가 주입된 워크로드가 CrashLoopBackOff 로 시작하지 못했다. 처음 보인 신호는 istiod 초기화가 유난히 오래 걸리며 나온 Readiness probe 실패 이벤트였다."},"components":["istio","admission-webhook","node-image"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"scaled istiod down temporarily from 40 replicas to 1 to slow Istio's internal processes and ease the load on the CA","ko":"istiod 레플리카를 40개에서 1개로 잠시 줄여 Istio 내부 처리를 늦추고 CA 부하를 덜었다."}},{"text":{"en":"deleted the CertificateSigningRequests stuck in the Approved, Failed state","ko":"Approved, Failed 상태로 멈춰 있던 CSR 들을 찾아 지웠다."}},{"text":{"en":"restarted the pods gradually in a controlled order instead of all at once","ko":"파드를 한꺼번에 재시작하지 않고 단계적으로 재시작해 CA 요청이 다시 몰리지 않게 했다."}}],"action_items":[],"contributing":["default-config-unchanged","limit-unknown"],"recurrence_of":null,"symptoms_text":{"en":"While the customer was updating the AMIs of its Amazon EKS nodes across more than 30 clusters running Istio, sidecar-injected workloads in one cluster failed to start and showed CrashLoopBackOff.\n\nThe first sign was istiod taking unusually long to initialise, with the event `Readiness probe failed: HTTP probe failed with status code: 503` on the istiod pod. While istiod was not ready, no injector webhook was available, and pod creation failed with `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\"`.\n\nThe istiod delay passed, but once sidecars were injected the pods still did not become ready: the sidecar process aborted before it was operational. The sidecar logs ended with `warn ca ca request failed, starting attempt 1 in 99.993416ms` and `warn Aborting proxy`, while the Kubernetes events showed the CertificateSigningRequests as signed (`The CSR has been signed`).","ko":"미국 연방 기관 고객이 Istio 를 쓰는 EKS 클러스터 30여 개의 노드 AMI 를 업데이트하던 중, 그중 한 클러스터에서 사이드카가 주입된 워크로드가 시작하지 못하고 CrashLoopBackOff 에 빠졌다.\n\n처음에는 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\" 오류로 실패했다.\n\nistiod 지연은 잠깐이었다. istiod 가 뜨고 사이드카가 주입된 뒤에도 파드는 ready 가 되지 못했다. 사이드카 프로세스가 동작하기 전에 중단됐고, 사이드카 로그에는 Agent draining Proxy 다음에 warn ca ca request failed, starting attempt 1 in 99.993416ms 와 warn Aborting proxy 가 찍혔다.\n\n그런데 CSR 이벤트는 The CSR has been signed 처럼 모두 성공으로 보였다. CA 요청이 처리되는데도 사이드카가 실패하자 팀은 외부 CA 를 의심했고, CA 가 동시에 뜨는 수백 개 파드의 인증서 요청을 감당하지 못하는 것을 확인했다."},"updated_at":"2026-11-09T11:55:44.749886Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0103","org_slug":"tetrate-unnamed-u-s-federal-customer"}