Incident Library
적용된 필터 원인배포 결함구성 요소노드 풀모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례5건

5건 중 1~5번째

  1. 증상

    2026-05-15 18:18 UTC 에 StackScript 를 쓰는 Linode 가상 머신 배포가 실패하는 문제가 확인됐다. 새로 만든 LKE 와 LKE-E 노드가 모두 여기에 해당했다.

    촉발

    최근 컴퓨트 호스트 업데이트에서 credential parser 가 제거됐다. 이 파서는 StackScript 를 해독하는 과정에 쓰였다.

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

    Akamai 는 2026-05-15 18:18 UTC 에 Linode 배포 실패 문제를 확인했다. 상태 페이지의 첫 공지는 05-16 00:42 UTC 에 올라왔다.

    조치
    • 05-16 01:10 UTC 에 롤백을 시험하기 시작해 01:20 에 실패가 줄었고, 01:30 에 고객 영향 대부분을 해소했다.
    교훈

    컴퓨트 호스트에서 credential parser 를 없애자 StackScript 로 배포한 Linode 가 모두 부팅하지 못했다. 새 LKE 와 LKE-E 노드도 모두 StackScript 로 배포되므로, 모든 리전에서 노드 생성과 오토스케일링, 노드 재생성이 멈췄다. 롤백 시험을 시작하고 10분 만에 실패가 줄었다.

  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 된 노드를 어떻게 다루는지도 분명히 알지 못했다.

  3. 증상

    2023년 5월 31일 16시 UTC 무렵부터 일부 고객의 LKE 클러스터 크기가 예상하지 못한 방식으로 바뀌었다. 클러스터 크기를 조정하면 잘못된 수의 노드가 만들어졌고, 고객 계정에 과금되는 자원이 추가됐다.

    촉발

    5월 31일 16시 UTC 무렵 LKE 클러스터를 잘못 스케일링하게 만드는 API 변경이 운영에 배포됐다. 자동 테스트에 빈틈이 있어 이 실패를 잡지 못했다.

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

    Linode 는 6월 1일 05시 07분 UTC 에 LKE 클러스터 크기를 조정하면 잘못된 수의 노드가 생기는 문제를 알고 있다고 공지했다. 변경이 나간 지 약 13시간 뒤였다.

    조치
    • 6월 1일 05시 07분 UTC 고객에게 가능하면 클러스터 크기 조정을 피하라고 안내했다.
    • 09시 40분 UTC 잘못된 스케일링을 바로잡는 핫픽스를 적용했다.
    • 고객 워크로드에 영향을 주지 않도록 늘어난 워커 노드를 지우지 않고 그대로 두었다.
    • 영향받은 고객에게 티켓으로 요금 조정과 추가 조치 방법을 알렸다.
    후속 조치
    • 자동 테스트를 점검한다.
    • 같은 일이 다시 일어나지 않도록 배포 전 체크리스트 항목을 추가했다.
    교훈

    자동 테스트가 잡지 못한 API 변경 하나가 고객 클러스터의 노드 수를 바꾸고 요금까지 늘렸다. Linode 는 테스트를 점검하고 배포 전 체크리스트를 늘리는 것으로 대응했다. 잘못 늘어난 노드라도 지우면 고객 워크로드에 영향을 줄 수 있어서, Linode 는 노드를 지우지 않고 요금 조정으로 보정했다.

  4. 증상

    2022년 6월 15일 18:30 UTC 무렵부터 LKE 고객이 클러스터를 업그레이드하거나 노드를 추가하려 하면 작업이 아무 오류 없이 실패했다. 19:54 UTC 에 상태 페이지에 LKE 문제를 조사 중이라는 공지가 올라왔다. 영향을 받은 곳은 US-East 뉴어크, US-Central 댈러스, US-West 프리몬트, US-Southeast 애틀랜타, CA-Central 토론토, EU-West 런던, EU-Central 프랑크푸르트, AP-South 싱가포르, AP-Northeast 도쿄 2, AP-West 뭄바이, AP-Southeast 시드니 리전의 LKE 였다.

    촉발

    6월 15일 18:30 UTC 무렵 LKE 운영 환경에 증분 업데이트를 배포했고, 이 업데이트에는 이전 릴리스의 변경이 빠져 있었다.

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

    상태 페이지 첫 공지는 업데이트 배포 약 1시간 24분 뒤인 19:54 UTC 에 올라왔다.

    조치
    • 빠진 변경을 다음 업데이트에 넣어 21:00 UTC 무렵 배포했다.
    후속 조치
    • 같은 문제를 막으려고 업데이트 절차에 단계와 자동화를 더했다.
  5. 증상

    2019-09-28 07:20 UTC 부터 Virtual Machine Scale Sets 위의 AKS 클러스터에서 클러스터 업그레이드를 시도하면 실패 알림이 왔다.

    촉발

    최근 서비스 업데이트가 백엔드 서비스의 인스턴스를 비정상 상태로 만들어 요청이 끝나지 못했다. 이 상태에서 고객이 클러스터 업그레이드를 시도했다.

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

    고객은 클러스터를 업그레이드하려 할 때 실패 알림을 받았다.

    조치
    • az vmss update 명령으로 스케일 세트 이미지의 version 을 "2019.09.25" 로, Sku 를 "aks-ubuntu-1604-201909" 로 바꾼 뒤 업그레이드를 다시 실행하는 방법을 공개했다.
    • AKS 팀과 VMSS 팀이 영향받은 클러스터를 손으로 완화했다.
    • 모든 리전에 핫픽스를 배포해 2019-10-15 에 마쳤다.
내 클러스터에도 있는지 확인하기

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

원인별1