사례4건

4건 중 1~4번째

1. IL-0183 kubeadm 으로 만든 클러스터의 1년짜리 인증서가 만료되어 kube-apiserver 가 etcd 와 TLS 연결을 맺지 못하고 재시작을 반복했고, 클러스터에 접속할 수 없게 됐다.

   ckck8032026

   증상

   외부에서 쿠버네티스 클러스터에 접속할 수 없었다. 작성자는 컨트롤 플레인 노드로 들어가 sudo systemctl status kubelet 으로 kubelet 로그를 확인했다.

   컨트롤 플레인 무응답컨테이너 재시작 반복

   촉발

   kubeadm 이 만든 하위 인증서의 기본 유효기간 1년이 2026-02-20 16:16 UTC 에 끝났다.

   원인

   인증서·자격 증명 만료

   구성 요소

   쿠버네티스 API 서버etcdkubeletCalico

   기여 요인

   기본 설정 방치

   감지

   외부에서 클러스터에 접속이 안 되는 것으로 알아챘다. 컨트롤 플레인 노드에서 kubelet 로그, containerd 로그, kube-apiserver 컨테이너 로그를 차례로 보다가 kube-apiserver 로그의 x509 만료 오류에서 원인을 확인했다.

   조치

   • sudo kubeadm certs renew all 로 만료된 인증서를 한 번에 갱신했다.
   • containerd 와 kubelet 을 재시작해 Static Pod 로 도는 컨트롤 플레인 컴포넌트를 새 인증서로 다시 띄웠다.
   • /etc/kubernetes/admin.conf 를 $HOME/.kube/config 로 복사하고 소유자를 바꿔 kubeconfig 를 새 인증서로 바꿨다.

   교훈

   sudo kubeadm certs check-expiration 으로 만료일을 주기적으로 확인하고, 만료 30일 전부터 갱신하는 것이 좋다. kubeadm upgrade apply 를 실행하면 인증서도 함께 갱신되므로, 1년에 한 번 이상 쿠버네티스 버전을 올리는 클러스터는 이 문제를 자연스럽게 피한다. 버전을 올리지 않고 오래 운영하는 클러스터라면 kubeadm certs renew all 과 kubelet 재시작을 cron 으로 매년 걸어 둘 수 있다. 작성자가 든 예시에서는 매년 1월 1일 새벽 3시에 실행한다.

   사례 보기
2. IL-0187 Spring Cloud Config Server 가 잠깐 내려가자 이를 헬스 체크에 포함한 모든 앱의 Liveness Probe 가 실패해 쿠버네티스가 파드를 계속 죽이고 다시 띄우면서 한 계열사 서비스가 마비됐다.

   Yonghyun Kim2025

   증상

   Config Server 업그레이드로 서버가 잠깐 응답하지 않는 동안, 클라이언트 앱 전부가 Liveness Probe 요청에 Config Server 와 연결되지 않는다며 실패로 응답했다.

   프로브 실패컨테이너 재시작 반복서비스 중단

   촉발

   Config Server 를 다운타임이 있는 방식으로 업그레이드하면서 서버가 잠깐 응답하지 않았다.

   원인

   의존성 장애

   구성 요소

   라이브니스·레디니스 프로브

   기여 요인

   기본 설정 방치자동화 증폭과도한 영향 범위

   교훈

   Liveness Probe 가 앱 자신이 아니라 외부 의존성의 상태까지 판단하면, 잠깐의 외부 장애나 네트워크 문제에도 쿠버네티스가 멀쩡한 앱을 죽인다. 일시적인 부하나 외부 서버 다운은 앱을 죽일 이유가 아니며, Readiness Probe 로 잠시 트래픽만 막으면 된다. 글쓴이는 특별한 이유가 없으면 Liveness Probe 를 끄라고 권한다. 꼭 써야 한다면 헬스 체크 경로에서 DataSourceHealthIndicator, ConfigServerHealthIndicator 같은 외부 Health Indicator 를 빼거나 /healthz 같은 별도 경로를 만들어야 한다. initialDelaySeconds 는 앱이 뜨는 데 걸리는 최대 시간보다 길게, failureThreshold 와 periodSeconds 는 넉넉하게 잡는다. 예를 들어 failureThreshold: 10, periodSeconds: 6 이면 60초 동안 연속으로 실패해야 재시작된다. 글쓴이가 운영한 레브잇 환경은 Liveness Probe 없이 2년 동안 안정적으로 서비스했다.

   사례 보기
3. IL-0103 EKS 노드 AMI 업데이트로 파드가 한꺼번에 다시 뜨자 인증서 요청이 몰린 외부 CA 가 과부하에 걸려 Istio 사이드카가 CrashLoopBackOff 에 빠졌다.

   Tetrate (unnamed U.S. federal customer)2025sev1

   증상

   미국 연방 기관 고객이 Istio 를 쓰는 EKS 클러스터 30여 개의 노드 AMI 를 업데이트하던 중, 그중 한 클러스터에서 사이드카가 주입된 워크로드가 시작하지 못하고 CrashLoopBackOff 에 빠졌다.

   컨테이너 재시작 반복프로브 실패

   촉발

   EKS 노드 AMI 업데이트로 수백 개의 새 파드가 동시에 떠서 외부 CA 로 인증서 요청이 한꺼번에 몰렸다.

   원인

   의존성 장애

   구성 요소

   Istio어드미션 웹훅노드 운영체제 이미지

   기여 요인

   기본 설정 방치한계 미인지

   감지

   노드 AMI 업데이트 중 한 클러스터에서 사이드카가 주입된 워크로드가 CrashLoopBackOff 로 시작하지 못했다. 처음 보인 신호는 istiod 초기화가 유난히 오래 걸리며 나온 Readiness probe 실패 이벤트였다.

   조치

   • istiod 레플리카를 40개에서 1개로 잠시 줄여 Istio 내부 처리를 늦추고 CA 부하를 덜었다.
   • Approved, Failed 상태로 멈춰 있던 CSR 들을 찾아 지웠다.
   • 파드를 한꺼번에 재시작하지 않고 단계적으로 재시작해 CA 요청이 다시 몰리지 않게 했다.

   교훈

   복잡한 인프라 장애를 진단할 때는 Istio 만이 아니라 서비스 메시를 둘러싼 구성 요소 전체를 봐야 한다. CSR 이벤트가 모두 성공으로 보여도 사이드카 로그에 CA 요청 실패가 있으면 외부 CA 의 처리 능력을 의심해야 한다. 노드 이미지 업데이트처럼 파드가 한꺼번에 다시 뜨는 작업을 하면 외부 CA 에 요청이 몰려, istiod 의 기본 CA 타임아웃 10초 안에 응답을 받지 못할 수 있다.

   사례 보기
4. IL-0107 오래된 Kyverno 가 서드파티 인증서 체인 만료로 크래시 루프에 빠졌고, failurePolicy 가 fail 인 웹훅이 응답하지 않아 Service 리소스의 생성, 수정, 삭제가 88분 동안 막혔다.

   DFDS2022

   증상

   2022년 8월 3일 11:38 UTC 에 한 사용자 팀이 해당 쿠버네티스 클러스터에 Service 리소스를 적용하는 데 문제가 있다고 알려 왔다.

   배포 실패컨테이너 재시작 반복

   촉발

   서드파티 애플리케이션이 쓰는 인증서 체인이 만료되면서 Kyverno 가 크래시 루프에 빠졌다. DFDS 쪽에서는 아무것도 바꾸지 않았다.

   원인

   인증서·자격 증명 만료

   구성 요소

   정책 엔진어드미션 웹훅

   기여 요인

   미뤄 둔 업그레이드기본 설정 방치모니터링 사각지대초기 신호 무시

   감지

   11:38 UTC 에 한 사용자 팀이 클러스터에 Service 리소스를 적용하지 못한다고 알려 오면서 장애가 드러났다. 팀은 11:50 UTC 에 조사를 시작했고, 보고서는 탐지까지 걸린 시간을 12분으로 적었다.

   조치

   • 쿠버네티스 샌드박스에서 문제를 재현하고, Kyverno 를 더 새 Helm 차트 버전으로 올리는 수정을 샌드박스에 먼저 배포했다.
   • 13:06 UTC 에 같은 수정을 영향받은 운영 클러스터에 배포했다.

   후속 조치

   • Kyverno 를 모니터링 대상에 넣는다.
   • Kyverno 를 어떻게 구성했는지 내부 문서로 정리한다.
   • 애플리케이션의 인증서에서 정확히 무엇이 문제였는지 조사한다.
   • 앞으로 ClusterPolicy 리소스의 failurePolicy 를 바꿀지 검토한다.

   교훈

   운영 문제는 처음부터 'Ops Day to Day' 보드에 올려야 한다.

   사례 보기

원인별2