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

사례5건

5건 중 1~5번째

  1. 증상

    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. 증상

    14:27 에 사용자가 #ask-cloud-platform 채널로 Kibana 에 13:45 부터 로그가 들어오지 않는다고 알려 왔다.

    촉발

    OpenSearch 의 디스크 공간이 바닥나 인덱스 쓰기가 막혔다.

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

    원문은 처음 감지된 시각을 12:10 으로 적었다. 이때 cp-live-app-logs 에서 ClusterIndexWritesBlocked 경보가 시작됐다. 팀이 실제로 문제를 알게 된 것은 14:27 에 사용자가 #ask-cloud-platform 채널로 Kibana 에 13:45 부터 로그가 들어오지 않는다고 알려 왔을 때였다.

    조치
    • 14:59 에 fluent-bit 컨테이너를 모두 rollout restart 했다. 로그가 잠깐 일부 흘렀지만 같은 오류가 다시 났다.
    • OpenSearch 디스크 공간을 8000 에서 12000 으로 늘렸다.
    • 근본 원인을 조사하는 동안 임시 조치로 fluent-bit 가 OpenSearch 로 로그를 보내지 않게 설정했다.
    후속 조치
    • OpenSearch 와 Elasticsearch 의 인덱스 날짜 문제를 살핀다.
    • Elasticsearch 와 OpenSearch 에 우선순위 높은 경보를 만든다.
    • OpenSearch 를 live 로깅에 다시 넣는다.
    • fluent-bit 의 “failed to flush chunk” 오류를 조사한다.
  3. 증상

    2023-09-18 13:42, 팀은 High-priority-alert 채널에서 RootVolUtilisation-Critical 알림을 봤다. 14:03 에는 한 사용자가 이미지 풀이 no space left on device 오류로 실패한다고 알렸다.

    촉발

    EKS 모듈을 버전 18 로 올리면서 런치 템플릿이 바뀌었고, 새 노드의 디스크가 100Gb 에서 20Gb 로 줄었다.

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

    13:42 에 High-priority-alert 채널로 RootVolUtilisation-Critical 알림이 왔다. 14:03 에 사용자가 이미지 풀 실패를 보고했고, 장애 선언은 15:12 였다.

    조치
    • 예전 기본 노드 그룹을 uncordon 하고, 새 노드를 drain 해 워크로드를 예전 노드 그룹으로 되돌렸다.
    • 루트 볼륨을 20Gb 로 줄인 런치 템플릿 변경을 찾아, manager 클러스터와 live 클러스터에 수정을 적용했다.
    • 예전 노드 그룹을 drain 해 워크로드를 수정한 노드로 옮겼다.
    후속 조치
    • EKS 모듈을 올릴 때 런치 템플릿 변경을 비교하는 절차를 런북에 넣는다.
    • live 클러스터처럼 크기가 다양한 이미지를 받아 보는 테스트 환경을 만든다.
    • RootVolUtilisation 알림 런북에 디스크 크기 설정을 확인하는 단계를 넣는다.
    • 노드 수에 따라 CoreDNS 를 자동으로 늘리고 줄인다.
    • IP 접두사 부족을 IPv6 로 풀 수 있는지 조사한다.
    • terraform plan 에서 런치 템플릿이 바뀌면 알아챌 수 있게 드리프트 테스트를 추가한다.
    • CNI 와 ipamd 로그를 볼 수 있게 로깅을 갖추고, IP 접두사 부족 오류가 나면 알림을 보낸다.
    교훈

    이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 빈틈이 두 가지 있었다. 하나는 모듈 업그레이드가 바꾼 런치 템플릿을 배포 전에 비교하지도, 드리프트 테스트로 잡지도 않은 것이다. 다른 하나는 drain 중 팀이 의심한 IP 접두사 부족을 확인할 CNI 와 ipamd 로그도, 알림도 없었던 것이다.

  4. 증상

    2023년 8월 4일 09:14에 사용자들이 Kibana 로그에 긴 공백이 있다고 #ask-cloud-platform 채널에 알렸다.

    촉발

    새 버전 fluent-bit에서 청크를 버리는 방식이 바뀌었다.

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

    사용자들이 #ask-cloud-platform 채널에 알려 와서 알았다. 처음 알려진 시각은 2023년 8월 4일 09:14이고, 장애 선언은 10:09였다.

    조치
    • 메모리 버퍼가 넘칠 때 파일 시스템에 쓰도록 하는 수정을 넣어 Live 환경에 배포했다.
    • 로그를 더 작은 청크로 나눠 내보내도록 바꿨다.
    후속 조치
    • 로깅 클러스터에서 나오는 알림을 #lower-priority-alerts 채널로 보낸다. 이슈 번호는 #4704다.
    • 로그가 로깅 클러스터로 실제로 전송되는지 확인하는 통합 테스트를 추가한다.
  5. 증상

    2023-07-25 14:05 PagerDuty 로 Pingdom 의 고우선순위 경보가 왔다. Prometheus - live 헬스 체크가 DOWN 이었다. 팀이 Prometheus 서버를 확인하니 규칙 평가 오류가 나 있었고 서버는 Exit code 137 로 종료돼 있었다.

    촉발

    네임스페이스와 Prometheus 규칙 수가 늘어 Prometheus 서버가 쓰는 메모리가 늘었고, 기존 인스턴스 크기로는 Prometheus 를 계속 띄울 수 없었다.

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

    14:05 Pingdom 이 Prometheus - live 헬스 체크가 DOWN 인 것을 감지해 PagerDuty 로 고우선순위 경보를 보냈다. 장애 선언은 15:21 에 했다.

    조치
    • 14:22 모니터링 노드를 드레인해 Prometheus 를 다른 모니터링 노드로 옮겼다.
    • 15:31 노드 인스턴스 크기를 CPU 와 메모리가 두 배인 r6i.4xlarge 로 바꿨다.
    • 15:50 Prometheus 컨테이너의 메모리 limit 을 100Gi 로 올렸다.
    • 16:18 Prometheus 컨테이너 limit 을 CPU 12코어, 메모리 110Gi 로 바꿨다.
    후속 조치
    • 노드 메모리 사용량을 감시하고, 파드 하나가 노드 메모리 대부분을 쓰는 상황을 잡아내는 경보를 추가한다. 이 일은 이슈 #4538 에서 다룬다.
내 클러스터에도 있는지 확인하기

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

원인별3

배포 결함1건

  1. IL-0020 EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 한꺼번에 쫓아내 운영 서비스가 멈췄다

용량 한계3건

  1. IL-0042 OpenSearch 디스크가 가득 찬 동안 fluent-bit 가 로그를 처리하지 못해 Elasticsearch 와 OpenSearch 에 애플리케이션 로그가 들어오지 않았다.
  2. IL-0043 새 버전 fluent-bit에서 청크를 버리는 방식이 바뀌어 Kibana의 애플리케이션 로그에 긴 공백이 생겼다
  3. IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다

설정 변경1건

  1. IL-0019 EKS 모듈 18 업그레이드로 새 노드의 디스크가 20Gb 로 줄어 이미지 풀이 no space left on device 로 실패했다