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

사례2건

2건 중 1~2번째

  1. 증상

    Twingate 서비스로 가는 인증과 인가 요청 일부에서 오류율이 올라갔다. 처음에는 여러 GKE 클러스터 가운데 하나에서 이상 동작이 보였다.

    촉발

    GKE 클러스터 하나에서 이상 동작이 보이자 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였고, 트래픽이 평소 부하가 가벼운 다른 클러스터로 옮겨 갔다.

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

    사고 초기에 엔지니어들이 GKE 클러스터 하나에서 이상 동작을 관찰했다.

    조치
    • 앞서 디플로이먼트를 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 오류율과 재시도가 가라앉았다.
    후속 조치
    • 예상하지 못한 타임아웃과 클러스터 업데이트의 영향이 왜 생겼는지 클라우드 사업자와 계속 함께 조사한다.
    • HPA 설정을 고쳐 모든 리전의 디플로이먼트 레플리카 수를 같게 맞췄다.
    • 클러스터 노드 오토스케일러의 최대 노드 수를 늘려 확장할 여유를 키웠다.
    • HPA 가 더 빨리 확장하도록 설정했다.
  2. 증상

    2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.

    촉발

    EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.

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

    팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.

    조치
    • cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
    • 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
    • 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
    • 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.
    후속 조치
    • AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
    • 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
    • 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
    • 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
    • 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
    • Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.
    교훈

    이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.

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

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

원인별2