Incident Library
적용된 필터 구성 요소노드 운영체제 이미지증상컨테이너 재시작 반복도메인쿠버네티스모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. 증상

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

    촉발

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

    원인
    구성 요소
    기여 요인
    감지

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

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

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

  2. 증상

    2024년 10월 24일 BSEE SaaS 고객 인스턴스가 모두 Environment Unavailable 메시지를 띄웠다. 04:45 에 SaaS Uptime Over Time 지표의 가용률이 크게 떨어졌고, 08:07 에 Growth 팀이 장애를 채널에 알렸다.

    촉발

    2024년 10월 24일 eu-west-1 에 Bottlerocket v1.26.0 이 최신 AMI 로 나오자, Karpenter 가 이를 알아채고 04:00 부터 운영 EKS 클러스터의 EC2 노드를 새 버전으로 바꾸기 시작했다.

    원인
    구성 요소
    기여 요인
    감지

    04:45 에 SaaS Uptime Over Time 지표의 가용률이 크게 떨어졌다. 08:07 에 Growth 팀이 BSEE cloud onboarding issues 채널에 장애를 알렸고, 08:15 에 Product 팀원이 기술팀에 구두로 알렸다.

    조치
    • 기술팀이 SaaS 운영 계정의 EC2 인스턴스를 모두 Bottlerocket v1.25.0 으로 되돌리기 시작했고, 09:15 에 고객 인스턴스가 다시 올라와 서비스가 복구됐다.
    • 모든 EKS 클러스터에 Bottlerocket 1.25.0 을 배포하고 새 EKS 노드로 교체했다.
    후속 조치
    • Karpenter 리소스를 바꿔 최신 AMI 대신 버전을 고정한 Bottlerocket AMI 를 배포하게 했다. 이 방식은 기술팀의 유지 보수 부담을 늘리고 중요한 보안 패치 배포를 늦출 수 있다.
    • Bottlerocket 릴리스 ATOM 피드를 내부 도구 릴리스 대시보드에 넣었다.
    • 고객에게 투명하게 알리는 공개 상태 페이지를 만든다.
내 클러스터에도 있는지 확인하기

이 2건에서 가장 많이 나오는 구성 요소: 노드 운영체제 이미지, 어드미션 웹훅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별2