사례29건

29건 중 4~8번째

1. IL-0101 자동 업그레이드를 꺼 둔 GKE 클러스터의 컨트롤 플레인이 지원 종료 기한에 1.33.2 로 강제 업그레이드된 뒤 새 노드가 모두 초기화에 실패해, 오토스케일링과 스팟 노드 복구가 15시간 멈췄다.

   Wealthy2025sev1

   증상

   2025년 9월 14일, 이미 떠 있던 노드는 계속 돌았지만 새로 만들어지는 노드는 하나도 클러스터에 제대로 들어오지 못했다. 스팟 인스턴스에서 돌던 백그라운드 워커, 리포트 서비스, 주문 할당 시스템이 완전히 멈췄다. API 는 기존 노드에서 계속 응답했지만 부하가 늘어도 확장할 수 없었다.

   노드 증설 실패컨테이너 재시작 반복서비스 중단DNS 조회 실패

   촉발

   노드 풀의 자동 업그레이드를 꺼 두었는데도 Google 이 버전 지원 종료 기한을 이유로 컨트롤 플레인을 v1.32.x 에서 v1.33.2 로 강제 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   GKE 컨트롤 플레인노드 풀클라이언트 쪽 DNS 리졸버와 캐시영구 볼륨과 스테이트풀셋컨피그맵과 시크릿

   기여 요인

   미뤄 둔 업그레이드단일 장애점롤백 무효여유 용량 부재

   조치

   • 강제 업그레이드와 같은 버전인 v1.33 으로 새 GKE 클러스터를 만들었다.
   • 쿠버네티스 1.33 과 호환되도록 Istio 를 1.27.1 로 올렸다.
   • 쿠버네티스 1.33 에 맞게 cert-manager 설정을 갱신했다.
   • 모든 운영 워크로드를 새 클러스터로 옮기고, 파드 스케줄링, DNS 조회, PVC 마운트, 외부 연동이 정상인지 확인했다.
   • 손상된 기존 클러스터를 폐기했다.

   후속 조치

   • 모든 클러스터를 GKE stable 릴리스 채널로 설정한다.
   • 2025년 4분기까지 Argo CD 와 모니터링 같은 관리용 구성 요소를 따로 돌리는 관리 클러스터를 만든다.
   • 중요한 워크로드의 스팟 인스턴스 사용을 다시 검토하고, 온디맨드 대체 노드 풀을 추가한다.
   • SRE 업그레이드 절차를 문서로 남긴다. 관리 클러스터를 먼저 올리고, 며칠 동안 지켜본 뒤 운영 클러스터를 올린다.
   • 쿠버네티스, Istio, cert-manager 사이의 호환 표를 문서로 남긴다.
   • 업그레이드를 자동으로 시험하는 파이프라인을 만든다.
   • 빠르게 이전할 수 있도록 고정 IP 를 예약해 둔다.
   • Istio, cert-manager, CSI, DNS 애드온의 버전을 고정한다.
   • 지원 종료 기한에 몰리지 않도록 stable 릴리스를 따라 제때 올리고, GKE 알림과 공지를 정기적으로 확인한다.

   교훈

   Google 은 자동 업그레이드를 꺼 두어도 버전 지원 종료 기한이 되면 컨트롤 플레인을 강제로 올린다. 강제 업그레이드를 피하려면 지원 버전 범위 안에 머물러야 한다. 기존 노드가 멀쩡해도 새 노드 초기화는 완전히 실패할 수 있다. 선점된 스팟 노드가 클러스터에 돌아오지 못하면 장애가 연쇄로 번진다. 컨트롤 플레인을 올린 뒤 노드 초기화가 되돌릴 수 없게 망가지면 클러스터를 통째로 다시 만들어야 할 수도 있다. 예측할 수 있고 검증된 릴리스 주기를 원하면 GKE stable 채널을 쓴다. 쿠버네티스를 올릴 때는 Istio, cert-manager 같은 의존 구성 요소를 함께 맞춰야 한다. 같은 클라우드에 대기 클러스터가 없으면 바로 넘어갈 곳이 없다. SRE 가 롤아웃을 단계적으로 관리하면 업그레이드 위험이 줄어든다.

   사례 보기
2. IL-0080 트래픽이 몰린 GKE 클러스터에서 kube-dns 가 DNS 질의를 감당하지 못해 여러 서비스의 이름 해석이 실패하고 운영 장애로 번졌다.

   Mercari2025sev1

   증상

   Mercari 의 GKE 클러스터에서 여러 서비스가 한꺼번에 DNS 이름 해석에 실패하기 시작했다. 요청은 타임아웃으로 끝났고, 마이크로서비스가 서로 엮여 있어서 실패가 연쇄로 번지며 운영 장애가 됐다. 회사는 이 장애를 Sev1 로 분류했다.

   DNS 조회 실패간헐적 타임아웃서비스 중단

   촉발

   피크 시간대에 클러스터가 처리하는 초당 요청 수가 크게 늘면서 DNS 질의가 소수의 kube-dns 파드로 몰렸다.

   원인

   용량 한계

   구성 요소

   kube-dns

   기여 요인

   캐시 부재단일 장애점

   감지

   피크 시간대에 NXDOMAIN, 잘린 응답, "failed to refresh DNS cache" 오류가 반복되는 것을 보고 kube-dns 가 한계에 이르렀다는 것을 알았다.

   조치

   • Platform 팀만 내부 시험용으로 쓰는 Laboratory GKE 클러스터에 nodeAffinity 를 걸어 NodeLocal DNSCache 를 배포하고, 전체 워크로드에 영향을 주지 않은 채 효과를 측정했다.
   • 노드 풀에 레이블을 붙여 NodeLocal DNSCache 파드가 뜰 수 있게 하는 방식으로 Dev 와 Prod 환경 전체에 점진적으로 배포했다.

   교훈

   트래픽이 많은 쿠버네티스 클러스터에서는 DNS 를 최적화하는 일이 중요하다. 모든 파드가 몇 개의 kube-dns 파드에 기대는 구조는 피크 시간대에 장애 지점이 됐고, 노드 단위 캐시를 두자 DNS 트래픽과 오류가 크게 줄었다.

   사례 보기
3. IL-0170 설날 이벤트 트래픽이 평소의 3배를 넘자 Istio ingressGateway 가 있는 EKS 노드의 nf_conntrack 테이블이 가득 차 패킷이 버려졌고, 웹과 앱 서비스 전체가 멈췄다.

   Backpackr2025

   증상

   2024년 1월 설날 이벤트 중에 개발자 한 명이 Slack 에 장애가 의심된다고 알렸다. 여러 사람이 상황을 확인하는 사이에 웹과 앱 서비스 전체가 멈췄고, 백패커는 이벤트를 중단하기로 했다.

   서비스 중단

   촉발

   2024년 1월 설날 이벤트로 트래픽이 평소보다 3배 넘게 몰렸다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블인그레스 컨트롤러Istio

   기여 요인

   단일 장애점기본 설정 방치모니터링 사각지대

   감지

   개발자 한 명이 Slack 에 장애가 의심된다고 제보했다. 여러 사람이 확인하는 동안 장애가 웹과 앱 서비스 전체로 번졌다.

   조치

   • 서비스 전체가 멈추자 설날 이벤트를 중단했다.

   후속 조치

   • 모든 노드의 nf_conntrack_max 를 올렸다. 일반 노드는 인스턴스 전체 메모리 바이트를 16384 로 나누고 다시 2로 나눈 값, istio 노드는 그 값의 3배를 쓴다. 메모리 16GB 인스턴스라면 net.netfilter.nf_conntrack_max 가 약 50만이 된다. 이 설정은 nodeOptimizer 데몬셋에 넣어 모든 노드에 자동으로 적용했다.
   • VirtualService 의 gateways 에 mesh 를 넣어 사이드카끼리 ingressGateway 를 거치지 않고 직접 통신하게 했다. HTTPS 로 도메인을 호출하면 TLS 오프로딩 때문에 여전히 ingressGateway 나 NLB 를 거쳐야 하므로, 메시 통신은 HTTP 호출에서 쓴다.
   • istio 노드를 12.5Gbps 의 c6.xlarge 에서 최대 25Gbps 대역폭을 내는 n 타입 인스턴스로 바꿨다.
   • 모니터링을 늘렸다. ENA 의 네트워크 대역폭과 패킷 드롭, ingressGateway 와 사이드카 프로세스 상태, CPU 와 메모리 사용률과 포화 상태를 지켜본다.

   교훈

   모든 트래픽이 노드 하나의 ingressGateway 를 거치면 그 노드가 단일 장애점이 된다. nf_conntrack 테이블은 기본 크기로 두면 트래픽이 갑자기 몇 배로 늘 때 가득 차고, 그 순간부터 패킷이 버려진다. 게이트웨이 노드는 일반 노드보다 conntrack 한도와 네트워크 대역폭을 넉넉하게 잡고, 네트워크 대역폭과 패킷 드롭 지표를 따로 지켜봐야 한다.

   사례 보기
4. IL-0027 CoreDNS 파드가 모두 한 노드에 몰린 채 그 노드의 메모리가 고갈되자 DNS 가 응답하지 못해 아이디어스 서비스 전체가 멈췄다

   Backpackr2025

   증상

   프로덕션 EKS 클러스터에서 원인을 바로 알기 어려운 서비스 에러가 간헐적으로 났다. RDS 나 Redis 같은 외부 서비스를 호출할 때 연결이 가끔 실패했다. DNS 요청이 몰릴 때는 도메인 조회 응답이 늦어지거나 조회가 아예 실패했다.

   DNS 조회 실패간헐적 연결 실패지연 시간 증가OOMKilled서비스 중단

   촉발

   모든 CoreDNS 파드가 같은 노드에 배치되었고, 그 노드의 메모리 사용률이 급증해 메모리가 고갈됐다.

   원인

   용량 한계

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시kubelet컨테이너 메모리 한도노드 풀

   기여 요인

   기본 설정 방치단일 장애점캐시 부재

   감지

   글은 전면 장애를 어떻게 알아챘는지 적지 않았다. 그 전의 DNS 문제는 원인을 알기 어려운 서비스 에러가 간헐적으로 나면서 드러났다. 팀은 RDS 와 Redis 호출이 가끔 실패하는 현상을 추적하다가 DNS 이름 해석 실패가 근본 원인이라는 것을 확인했다.

   조치

   • CoreDNS 앞에서 DNS 질의를 받아 노드마다 캐시하는 NodeLocalDNS Cache 를 데몬셋으로 배포해 CoreDNS 부하를 줄였다.
   • CoreDNS 에 maxUnavailable: 1 인 PodDisruptionBudget 과 topology.kubernetes.io/zone 기준의 topologySpreadConstraints 를 적용해 파드가 한 곳에 몰리지 않게 했다.
   • Deployment 의 dnsConfig 로 ndots 값을 5 에서 2 로 낮춰 불필요한 DNS 조회를 줄였다.

   교훈

   쿠버네티스의 ndots:5 기본값은 점이 적은 외부 도메인을 조회할 때마다 질의를 여러 번 만든다. 이 부하는 트래픽이 큰 프로덕션 환경에서야 드러난다. CoreDNS 를 파드 2개의 기본 구성으로 두면 클러스터 전체의 단일 장애점이 된다. CoreDNS 파드는 노드와 가용 영역에 흩어 둔다. 별도 노드 그룹이나 Fargate 로 분리하면 다른 워크로드와 자원을 다투지 않는다. Affinity 와 PriorityClassName 으로 우선순위를 주면 더 안정적이다. CoreDNS 의 캐시와 bufsize 조정은 증상을 잠깐 줄였을 뿐이다. ndots 값은 여러 자료가 1이나 2를 권하지만 각 환경에 맞춰 정해야 한다.

   사례 보기
5. IL-0085 Hetzner Cloud 의 k3s 컨트롤 플레인 노드가 메모리 부족으로 꺼진 뒤 클러스터가 Hetzner API 호출 한도를 다 써 버려 모든 고객 사이트가 약 7.5시간 멈췄다.

   Magic Pages2025

   증상

   2025-04-14 09:33 UTC 쯤 Magic Pages 의 컨트롤 플레인 노드 세 대 중 한 대가 갑자기 오프라인이 됐다. 노드를 살펴보니 메모리가 바닥나 있었다. 운영자는 평소 절차대로 고장 난 노드를 빼고 메모리가 조금 더 큰 서버로 바꾸려 했다.

   서비스 중단노드 NotReady클라우드 API 호출 한도 소진

   촉발

   컨트롤 플레인 노드 한 대가 메모리 부족으로 오프라인이 됐다. 이 노드를 교체하는 배포가 실패해 다시 시도하는 동안, 클러스터 내부 구성 요소들이 Hetzner API 를 계속 호출해 시간당 3600건 한도를 소진했다.

   원인

   용량 한계

   구성 요소

   클라우드 컨트롤러 매니저영구 볼륨과 스테이트풀셋

   기여 요인

   한계 미인지재시도 폭주모니터링 사각지대디버그 접근 제한단일 장애점런북 부재

   감지

   모니터링 경보가 쏟아지면서 고객 웹사이트에 접속할 수 없다는 것을 알았다. API 호출 한도가 원인이라는 것은 30분쯤 조사한 뒤에야 찾았다. hetzner-k3s 가 Hetzner API 오류를 감춰서 원인 파악이 늦어졌다.

   조치

   • API 호출을 확실히 멈추려고 서버 전원을 내려 쿠버네티스 클러스터 전체를 껐다.
   • Hetzner API 의 ratelimit-remaining 값이 다시 오르는 것을 지켜보면서, 복구 중에 다시 한도에 걸리지 않도록 여유분이 쌓일 때까지 기다렸다.
   • API 호출 여유가 생긴 뒤 컨트롤 플레인 서버를 다시 켰다.
   • 워커 노드를 올린 뒤 Longhorn 의 핵심 구성 요소를 손으로 띄워 스토리지 볼륨이 스스로 복구되게 했다.
   • 17:00 UTC 쯤 사이트의 95% 가 돌아온 뒤, 남은 사이트를 손으로 다시 시작했다.

   후속 조치

   • 클러스터 노드에서 나가는 Hetzner API 호출량을 따로 모니터링해서 사용량이 높아지면 미리 알 수 있게 한다.
   • Hetzner 와 협의해 API 호출 한도를 늘린다.
   • API 하나에 기대는 구조를 줄일 방법을 찾고, hetzner-k3s 로는 그렇게 하기 어렵다면 다른 도구를 검토한다.
   • 클러스터 전체가 꺼진 뒤 Longhorn 스토리지를 복구하는 절차를 더 탄탄하게 문서로 만들고 시험한다.

   교훈

   Hetzner 의 기본 API 한도인 시간당 3600건은 장애나 복구 상황에서 클러스터가 쓰는 양에 비해 부족했다. 운영자는 배포에 쓰는 API 사용량만 봤고, 실행 중인 클러스터 내부에서 나가는 호출은 지켜보지 않았다. 네트워킹 같은 핵심 기능이 클라우드 API 하나에 기대고 있으면, 그 API 가 막히는 순간 클러스터 전체가 약해진다. hetzner-k3s 의 추상화는 API 오류를 감춰 문제 해결을 늦췄다. 클러스터가 비정상 종료된 뒤 Longhorn 을 살리는 데 손이 많이 가서 장애가 길어졌다.

   사례 보기

원인별11