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

사례2건

2건 중 1~2번째

  1. IL-0168 새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다.
    Scaleway2024
    증상

    2024년 2월 13일 01:04 CET 에 FR-PAR 리전의 Kubernetes API 에서 RAM 과 CPU 사용량이 치솟아 OOM 이 났다. 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 상태가 됐다.

    노드 NotReady컨트롤 플레인 지연OOMKilled
    촉발

    2월 12일 새 쿠버네티스 릴리스가 모든 사용자에게 나온 뒤, 12일에서 13일로 넘어가는 밤에 많은 클러스터가 동시에 자동 업그레이드를 시작했다.

    원인
    용량 한계
    구성 요소
    쿠버네티스 API 서버
    기여 요인
    재시도 폭주자동화 증폭단계적 배포 부재
    감지

    타임라인의 첫 기록은 01:04 CET 다. 이때 Kubernetes API 의 RAM 과 CPU 사용량이 치솟아 OOM 이 났고, 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 가 됐다. 기록된 첫 조치는 42분 뒤인 01:46 에 API 자원을 늘린 일이었다.

    조치
    • Kubernetes API 에 배정한 자원을 01:46 과 02:20 두 차례 늘렸다.
    • 02:30 에 API 트래픽을 제한해 들어오는 트래픽을 고르게 만들고 혼잡을 줄였다.
    • 03:20 부터 트래픽 제한을 50-100 개 배치로 나눠 차례로 풀어 노드들이 다시 인증하고 "Ready" 가 되게 했다.
    • 03:40 에 API 혼잡 중에 만들어진 고장 노드를 교체하는 스크립트를 돌렸다.
    • 15:45 부터 노드 인증이 한꺼번에 몰리지 않게 일부 클러스터부터 예전 인증 방식으로 차례로 롤백했고, 2월 19일 모든 클러스터에서 롤백을 마쳤다.
    • 노드 인증이 동시에 몰릴 수 있는 클러스터 업그레이드와 설정 갱신 기능을 2월 20일 10:30 까지 껐다.
    후속 조치
    • Kubernetes API 자원 배정을 늘렸다.
    • 예전 인증 방식으로 롤백했다.
    • 노드에 로컬 인증 캐시를 둔다.
    • 부하가 치솟을 때 더 잘 버티도록 자원 배정 전략을 다시 짠다.
    • 쿠버네티스에 새 요청 큐잉 방식을 넣는다.
    • 높은 부하나 장애가 다른 구성 요소로 번지지 않게 구성 요소를 서로 분리한다.
    • 몇몇 지표를 꼼꼼히 지켜봐 이상 패턴을 더 일찍 찾는다.
    • 이 기간에 노드를 배포했지만 제대로 쓰지 못한 고객에게 환불한다.
    교훈

    고객의 클러스터와 노드가 빠르게 늘면서 기존 트래픽 제어로는 혼잡을 막기 어려워졌다. 많은 클러스터의 자동 업그레이드가 한 번에 시작되면 Kubernetes API 에 부하가 몰리고, 계속 실패하고 재시도하는 노드 인증 방식이 혼잡을 더 키운다. 1월 24일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.

    사례 보기
  2. IL-0140 us-central1 의 GKE API 가 지연과 오류를 내면서 고객이 클러스터 상태 확인, 업그레이드, 생성과 삭제를 하지 못했다.
    Google Cloud2022
    증상

    2022년 6월 14일 03:03 US/Pacific 부터 us-central1 의 GKE API 호출이 느려지고 오류를 냈다. gcloud 와 Google Cloud Console 에서 보내는 GKE API 호출이 모두 영향을 받았다.

    오류율 상승지연 시간 증가컨트롤 플레인 지연
    촉발

    GKE 백엔드로 들어오는 트래픽이 예상하지 못하게 늘었다.

    원인
    용량 한계
    구성 요소
    GKE 컨트롤 플레인
    기여 요인
    재시도 폭주
    조치
    • 늘어난 트래픽을 감당하도록 GKE 컨트롤 플레인을 증설했다.
    교훈

    실패한 요청을 클라이언트가 재시도하면 갑자기 늘어난 트래픽이 더 커진다. 관리형 컨트롤 플레인이 느려져도 클러스터 워크로드는 계속 돌지만, 클러스터를 조회하거나 바꾸는 작업은 막힌다.

    사례 보기
내 클러스터에도 있는지 확인하기

이 2건에서 가장 많이 나오는 구성 요소: GKE 컨트롤 플레인, 쿠버네티스 API 서버. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

kubegap 열기

원인별1

용량 한계2건

구성 요소
GKE 컨트롤 플레인1건쿠버네티스 API 서버1건
기여 요인
재시도 폭주2건자동화 증폭1건단계적 배포 부재1건
조직
Google Cloud1건Scaleway1건
  1. IL-0168 새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다.
    Scaleway2024
  2. IL-0140 us-central1 의 GKE API 가 지연과 오류를 내면서 고객이 클러스터 상태 확인, 업그레이드, 생성과 삭제를 하지 못했다.
    Google Cloud2022