사례11건

11건 중 1~5번째

1. IL-0158 자격 증명이 만료돼 인증이 실패하면서 모든 리전에서 LKE 와 LKE-E 의 클러스터와 노드를 배포할 수 없었고, 노드 재생성과 오토스케일링도 막혔다.

   Linode2026

   증상

   2026년 4월 16일 11:45 UTC 부터 LKE 와 LKE-E 고객이 클러스터와 노드를 배포하지 못했다. 새 클러스터를 만들거나 기존 클러스터에 노드를 추가할 수 없었다.

   배포 실패노드 증설 실패자격 증명 획득 실패

   촉발

   자격 증명이 만료돼 LKE 와 LKE-E 가 클러스터와 노드를 배포할 때 인증이 실패했다. 상태 페이지의 모니터링 공지에는 원인이 만료된 인증서라고 적혀 있었다.

   원인

   인증서·자격 증명 만료

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   13:20 UTC 에 상태 페이지에 첫 공지가 올라왔다. 모든 리전의 LKE 와 LKE-E 에 영향을 주는 문제를 조사하고 있다는 내용이었다.

   조치

   • 새 자격 증명을 만들어 배포했고, 16:27 UTC 쯤 이 교체로 장애가 완화됐다.

   후속 조치

   • 자격 증명이 만료된 근본 원인을 계속 조사하고 그에 맞는 예방 조치를 한다.

   교훈

   만료된 자격 증명 하나가 모든 리전에서 동시에 새 노드가 필요한 작업을 모두 멈췄다. 새 클러스터 생성, 노드 추가, 노드 재생성, 오토스케일링이 모두 막혔다.

   사례 보기
2. IL-0098 ingress-nginx 에서 nginx-ingress 로 옮긴 뒤 같은 호스트를 나눠 쓰는 인그레스들의 동작이 바뀌어 cert-manager 가 새 TLS 인증서를 받지 못했다.

   2i2c2026

   증상

   새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.

   요청 오라우팅배포 실패

   촉발

   nginx-ingress 로 옮긴 클러스터에서 새 TLS 인증서가 필요한 허브를 새로 배포했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러cert-manager

   기여 요인

   늦게 드러난 변경

   감지

   새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다.

   조치

   • TLS 가 필요한 인그레스 객체에 어노테이션을 달아 cert-manager 가 edit-in-place 방식으로 인그레스를 고칠 수 있게 했다.

   후속 조치

   • 후속 작업을 2i2c-org/infrastructure 이슈 8016 으로 남겼다.
   • 후속 작업을 2i2c-org/infrastructure 이슈 3278 로 남겼다.

   교훈

   인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다.

   사례 보기
3. IL-0204 Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다.

   Render2024

   증상

   2022년 1월 Render 의 프랑크푸르트 Kubernetes 클러스터 하나에서 새 배포와 크론 잡 실행이 실패했다. etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸린 상태였다.

   컨트롤 플레인 무응답배포 실패DNS 조회 실패오류율 상승

   촉발

   etcd 메모리가 급증해 Kubernetes 컨트롤 플레인이 과부하에 걸렸다.

   원인

   용량 한계

   구성 요소

   etcdCoreDNS쿠버네티스 API 서버

   기여 요인

   기본 설정 방치수동 조치 악화

   후속 조치

   • CoreDNS 를 컨트롤 플레인 노드가 아닌 데이터 플레인 노드에서 돌게 했다.
   • etcd 를 전용 노드에서 돌게 했다.

   교훈

   CoreDNS 는 API 서버가 내려가 있어도 메모리 캐시로 DNS 질의에 답할 수 있지만, 초기화할 때는 API 서버가 필요하다. CoreDNS 가 컨트롤 플레인 노드에 있었기 때문에, 컨트롤 플레인 장애 중에 노드를 재부팅하자 새 배포와 크론 잡만 실패하던 장애가 이미 돌던 서비스로 가는 요청까지 실패하는 장애로 커졌다. 핵심 문제는 데이터 플레인이 컨트롤 플레인에서 충분히 분리되어 있지 않았다는 점이다. 노드를 재부팅하지 않았더라도 etcd 메모리 급증만으로 CoreDNS 가 재시작될 수 있었다.

   사례 보기
4. IL-0130 내부 스토리지 프로비저닝 설정 오류로 Vertex Model Garden 의 100GB 넘는 대형 모델 배포가 13일 넘게 "Model server never became ready" 오류를 내며 실패했다.

   Google Cloud2024

   증상

   2024년 10월 22일 14:08 US/Pacific 부터 Vertex AI Online Prediction 에서 대형 모델을 배포하던 고객은 "Model server never became ready" 오류를 받았다. 디스크가 100GB 넘게 필요한 모델이 대상이었다.

   배포 실패

   촉발

   최근 변경과 함께 들어간 내부 스토리지 프로비저닝 설정에 오류가 있었다.

   원인

   설정 변경

   구성 요소

   –

   기여 요인

   –

   감지

   장애는 2024년 10월 22일 14:08 에 시작됐지만 상태 페이지에 처음 올라온 것은 약 13일 뒤인 11월 4일 13:17 US/Pacific 이었다. 첫 게시는 GKE Autopilot 클러스터로 가는 100GB 넘는 Vertex Model Garden 배포가 실패할 수 있다고 적었다.

   조치

   • Google 엔지니어들이 문제를 일으킨 설정 변경을 롤백했다.

   교훈

   대형 모델 배포처럼 일부 조건에서만 실패하는 설정 오류가 대부분 리전에서 13일 넘게 이어졌다. 장애는 13일 가까이 지난 뒤에야 상태 페이지에 올라왔고, 원인이 된 설정 변경을 롤백하자 해결됐다.

   사례 보기
5. IL-0107 오래된 Kyverno 가 서드파티 인증서 체인 만료로 크래시 루프에 빠졌고, failurePolicy 가 fail 인 웹훅이 응답하지 않아 Service 리소스의 생성, 수정, 삭제가 88분 동안 막혔다.

   DFDS2022

   증상

   2022년 8월 3일 11:38 UTC 에 한 사용자 팀이 해당 쿠버네티스 클러스터에 Service 리소스를 적용하는 데 문제가 있다고 알려 왔다.

   배포 실패컨테이너 재시작 반복

   촉발

   서드파티 애플리케이션이 쓰는 인증서 체인이 만료되면서 Kyverno 가 크래시 루프에 빠졌다. DFDS 쪽에서는 아무것도 바꾸지 않았다.

   원인

   인증서·자격 증명 만료

   구성 요소

   정책 엔진어드미션 웹훅

   기여 요인

   미뤄 둔 업그레이드기본 설정 방치모니터링 사각지대초기 신호 무시

   감지

   11:38 UTC 에 한 사용자 팀이 클러스터에 Service 리소스를 적용하지 못한다고 알려 오면서 장애가 드러났다. 팀은 11:50 UTC 에 조사를 시작했고, 보고서는 탐지까지 걸린 시간을 12분으로 적었다.

   조치

   • 쿠버네티스 샌드박스에서 문제를 재현하고, Kyverno 를 더 새 Helm 차트 버전으로 올리는 수정을 샌드박스에 먼저 배포했다.
   • 13:06 UTC 에 같은 수정을 영향받은 운영 클러스터에 배포했다.

   후속 조치

   • Kyverno 를 모니터링 대상에 넣는다.
   • Kyverno 를 어떻게 구성했는지 내부 문서로 정리한다.
   • 애플리케이션의 인증서에서 정확히 무엇이 문제였는지 조사한다.
   • 앞으로 ClusterPolicy 리소스의 failurePolicy 를 바꿀지 검토한다.

   교훈

   운영 문제는 처음부터 'Ops Day to Day' 보드에 올려야 한다.

   사례 보기

원인별7