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

사례4건

4건 중 1~4번째

  1. 증상

    2024년 4월 19일 16:40 UTC 에 메인넷 운영 환경에서 정산이 멈췄다. 핵심 서비스가 내려가 있었다.

    촉발

    클러스터 용량을 늘리는 IaC 자동화가 돌면서, IaC 에 버전이 고정되지 않은 VPC CNI 플러그인이 자동으로 업데이트됐다.

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

    장애는 16:40 UTC 에 정산이 멈추면서 시작됐다. 팀은 23분 뒤인 17:03 UTC 에 CNI 버전 불일치를 원인으로 짚었다.

    조치
    • 19:00 UTC 쯤 쿠버네티스 클러스터 업그레이드를 시작했다.
    • 새 버전의 네트워크 플러그인을 쓰는 노드 그룹을 새로 만들었다.
    교훈

    IaC 스크립트에 버전을 명시해야 의도치 않은 업데이트를 막을 수 있다. 운영 환경일수록 쉽게 되돌릴 수 있는 변경 관리가 필요하다.

  2. 증상

    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 로그도, 알림도 없었던 것이다.

  3. 증상

    2023-07-21 08:15, 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 상태에서 멈춘다고 알렸다.

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

    팀은 08:15 에 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 에서 멈춘다고 보고해 장애를 알았다. 장애 선언은 09:31 이었다.

    조치
    • 새 노드를 추가하고, 영향받은 노드 6대를 cordon 한 뒤 drain 하기 시작했다.
    • live 클러스터에서 Prefix Delegation 을 켜는 명령을 실행해 빠진 CNI 설정을 넣었다.
    후속 조치
    • IP 주소 할당이 제대로 되는지 확인하는 테스트나 점검을 추가한다. 작업 번호는 #4669 다.
    교훈

    이 글은 교훈을 따로 적지 않았다. 후속 조치로는 IP 주소 할당이 제대로 되는지 확인하는 점검을 추가한다는 것 하나만 적었다.

  4. 증상

    동료가 슬랙으로 애플리케이션 배포가 오래 걸린다고 알려 왔다. 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 머물러 있었다. 새 파드의 절반쯤은 트래픽을 받고 있었고 나머지 절반은 Pending 상태였다.

    촉발

    클러스터의 노드 수가 256개에 이르렀다. GKE 는 노드당 최대 파드 수를 기본 110 으로 두고, 그 두 배 이상을 담을 수 있는 서브넷 마스크를 노드마다 미리 할당한다. 노드 하나가 IP 256개를 차지하므로 /16 보조 범위의 65,536개 주소가 노드 256개에서 바닥났다.

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

    동료가 슬랙으로 배포가 오래 걸린다고 알려 왔다. 확인해 보니 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 멈춰 있었다.

    조치
    • 파드가 많이 뜨지 않을 노드 풀에서 노드당 최대 파드 수를 줄여 전체 IP 사용량을 약 30% 줄였다.
    • 일부 노드 풀의 인스턴스 크기를 키워 노드당 더 많은 파드를 돌리게 했다.
    후속 조치
    • 상태 저장 애플리케이션, 캐시, 보안을 강화한 워크로드처럼 노드에 파드가 많이 뜨지 않는 노드 풀은 노드당 최대 파드 수를 낮춰 운영한다.
    • 일부 노드 풀에 더 큰 인스턴스를 쓴다.
    교훈

    GKE 는 기본으로 노드마다 IP 256개를 할당한다. /16 처럼 큰 범위도 노드가 256개면 바닥난다. 노드당 최대 파드 수가 파드 IP 소비량을 정하므로, 노드 풀마다 실제로 띄울 파드 수에 맞춰야 한다. 큰 노드를 쓰면 IP 를 효율적으로 쓰고 자원 활용도도 높아지지만, 노드 하나가 죽을 때 더 많은 파드가 함께 내려간다.

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

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

원인별2