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

사례7건

7건 중 6~7번째

  1. 증상

    2023년 3월 14일 19시 UTC 직후 엔지니어가 Old Reddit 이라 불리는 레거시 스택을 돌리는 클러스터의 업그레이드를 시작했다. 2분쯤은 괜찮아 보였지만 곧 사이트 전체가 갑자기 멈췄다. CDN 엣지의 상태 코드별 RPS 그래프가 이를 보여 주었다. 사용자는 오류 페이지나 글이 하나도 없는 홈페이지를 보았다.

    촉발

    Reddit 에서 가장 중요한 클러스터 가운데 하나인 레거시 클러스터를 쿠버네티스 1.23 에서 1.24 로 업그레이드했다.

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

    업그레이드를 시작하고 2분쯤 뒤 CDN 엣지의 상태 코드별 RPS 그래프에서 사이트가 멈춘 것이 보였다. 팀은 곧바로 장애를 선언했고 3분 안에 대응 인원이 통화에 모였다. 엣지 지표는 일부러 클러스터와 분리되어 있어 살아 있었지만, 클러스터 자체의 지표는 모두 사라졌다.

    조치
    • API 서버에서 타임아웃을 내던 Open Policy Agent 의 웹훅 설정을 지웠다.
    • 복원 뒤 어차피 쓸 수 없게 될 워커 노드를 모두 종료했다.
    • 컨트롤 플레인 노드 두 대를 종료하고, 남은 한 대의 구성 요소를 다운그레이드한 뒤 그 노드에 백업 데이터를 복원했다.
    • 단일 노드 컨트롤 플레인이 부하에 무너지지 않도록 클러스터 오토스케일러를 껐다.
    • 새 컨트롤 플레인 노드를 띄우고, 호스트명이 맞지 않던 TLS 인증서를 새로 만들어 노드들을 합류시켰다.
    • 트래픽을 1% 에서 시작해 5%, 10%, 20%, 35%, 55%, 80%, 100% 로 조금씩 늘렸다.
    • 트래픽이 돌아올 때 문제를 일으키지 않도록 손으로 멈춰 두었던 민감한 레거시 서비스를 조심스럽게 다시 켰다.
    후속 조치
    • 클러스터 구성을 코드로 관리해 모든 선택에 기록이 남게 하고, 코드로 만들 수 없는 것은 자세히 문서로 남긴다.
    • 클러스터마다 다른 맞춤형 구성을 걷어 내고 모든 클러스터의 구성 요소를 표준화한다.
    • 모든 클러스터를 최대한 같은 모습으로 유지하고 필요하면 다시 만들거나 복제할 수 있도록 클러스터 전체의 수명 주기를 관리하는 도구를 만든다.
    • 믿고 테스트에 쓸 수 있는 프리프로덕션 클러스터를 더 둔다.
    • 백업 복원 절차를 개선하고 클러스터 업그레이드를 안전하게 만든다.
    교훈

    쿠버네티스 버전과 구성 요소 업그레이드는 여전히 위험하다. 미리 테스트하고 검증해도 이번처럼 처음 보는 방식으로 깨질 수 있다. 쿠버네티스에는 공식 다운그레이드 절차가 없어, 롤백하는 방법은 백업에서 복원하는 것뿐이다. 복원 절차가 환경 변화를 따라가지 못하면 실제 장애 때 그 자리에서 고쳐 써야 하고, 복원을 결정하기까지 오래 망설이게 된다. 이번 복원은 결국 성공했지만 절차는 개선해야 한다. 코드로 남기지 않은 설정은 아는 사람이 떠나면 아무 기록도 남지 않는다. 라우트 리플렉터 설정이 어디에도 커밋되어 있지 않아 장애 중에 누구도 의심하지 못했다. 지표가 클러스터 안에서만 수집되면 클러스터가 망가질 때 함께 사라진다. 이번에는 로그 수집 에이전트가 영향을 받지 않아 원인을 추적할 수 있었다. 클러스터마다 다른 맞춤형 구성이 쌓이면 장애가 잦아진다. 직접 원인은 노드 레이블이었지만 근본 원인은 일관성 부족이었다.

  2. 증상

    2023년 3월 8일 06:00 에서 07:00 UTC 사이에 여러 리전과 여러 클라우드의 Kubernetes 노드가 한꺼번에 네트워크 연결을 잃었다. Datadog 의 모든 서비스가 영향을 받았고, CI/CD 와 자동화 도구가 있는 리전도 함께 끊겼다.

    촉발

    2023년 3월 7일 Ubuntu 저장소에 systemd 의 CVE 패치 249.11-0ubuntu3.7 이 올라왔다. 3월 8일 06:00 에서 07:00 UTC 사이에 Ubuntu 기본값 그대로 둔 무인 업그레이드가 이 패치를 설치했고, systemd-networkd 가 재시작되면서 자신이 모르는 IP 규칙을 모두 지웠다.

    원인
    구성 요소
    기여 요인
    조치
    • Google Cloud 와 Azure 에서 네트워크만 잃고 실행 중이던 인스턴스 수천 대를 클라우드 API 로 재시작해 로컬 디스크의 데이터와 함께 복구했다.
    • AWS 에서 교체되면서 로컬 디스크를 잃은 데이터 저장소는 데이터를 다시 만들거나, 다시 처리하거나, 백업에서 복원해 되살렸다.
    교훈

    기본값 그대로 둔 OS 무인 보안 업데이트는 단계적 배포 절차를 거치지 않고 모든 리전과 클라우드에 같은 시각에 변경을 적용한다. systemd-networkd 의 새 동작은 22.04 도입 때부터 있었지만 systemd-networkd 가 재시작될 때만 나타나서 몇 달 동안 보이지 않았다. CNI 가 호스트의 IP 규칙에 기대고 있으면, 그 규칙을 지우는 다른 구성 요소 하나가 노드 네트워크 전체를 끊는다. 클라우드마다 네트워크를 잃은 인스턴스를 다루는 방식이 다르고, 로컬 디스크에 데이터를 두는 서비스에서는 자동 교체가 오히려 복구를 늦춘다.

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

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

원인별1

업그레이드로 깨진 호환성7건

  1. IL-0092 ingress-nginx 를 1.12.0 에서 1.14.3 으로 올리자 새 ModSecurity 와 OWASP Core Rule Set 이 정상 요청을 오탐으로 막아 HMPPS 사용자가 인증하지 못했다.
  2. IL-0101 자동 업그레이드를 꺼 둔 GKE 클러스터의 컨트롤 플레인이 지원 종료 기한에 1.33.2 로 강제 업그레이드된 뒤 새 노드가 모두 초기화에 실패해, 오토스케일링과 스팟 노드 복구가 15시간 멈췄다.
  3. IL-0079 GKE 노드가 새 ubuntu_containerd 이미지로 자동 업그레이드된 뒤 커널에서 kube-proxy 가 쓰는 iptables 확장이 빠져, 여러 GKE 클러스터의 인그레스 트래픽이 완전히 끊겼다.
  4. IL-0203 클러스터 시스템 업데이트 뒤 AWS Load Balancer Controller 가 실패해 새 파드가 ALB 에 등록되지 않았고, Honeycomb EU1 의 수집과 UI 가 11분 동안 멈췄다
  5. IL-0180 GKE 컨트롤 플레인이 1.22 에서 1.23 으로 자동 업그레이드되면서 v1beta1 API 를 쓰던 Istio 1.7.4 가 제대로 동작하지 않았다
  6. IL-0060 쿠버네티스 1.24 업그레이드로 node-role.kubernetes.io/master 레이블이 사라지자 이 레이블에 기대던 Calico 라우트 리플렉터가 동작을 멈춰 레거시 클러스터의 네트워크가 모두 끊기고 Reddit 이 314분 동안 멈췄다
    Reddit2023
  7. IL-0198 systemd 보안 패치가 Ubuntu 22.04 노드의 systemd-networkd 를 재시작해 Cilium 이 넣은 IP 규칙을 지웠고, 여러 리전과 세 클라우드의 Kubernetes 노드가 한꺼번에 네트워크를 잃었다.