사례12건

12건 중 1~5번째

1. IL-0092 ingress-nginx 를 1.12.0 에서 1.14.3 으로 올리자 새 ModSecurity 와 OWASP Core Rule Set 이 정상 요청을 오탐으로 막아 HMPPS 사용자가 인증하지 못했다.

   UK Ministry of Justice2026

   증상

   2026년 3월 30일 08:56 에 Cloud Platform 팀은 #hmpps-auth-audit-registers 슬랙 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤다. 같은 날 07:11 에 운영 인그레스 세 개에 새 ingress-nginx 를 배포하기 시작한 뒤였다.

   오류율 상승서비스 중단

   촉발

   Cloud Platform 팀이 ingress-nginx 1.14.3 을 운영 인그레스 세 개에 배포했다. 이 버전에는 새 ModSecurity WAF 와 새 OWASP Core Rule Set 이 들어 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   스테이징 불일치

   감지

   Cloud Platform 팀은 HMPPS Auth 팀 슬랙 채널의 메시지로 장애를 알았다. 팀은 08:56 에 #hmpps-auth-audit-registers 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤고, 09:14 에 장애를 선언했다.

   조치

   • 09:14 에 ingress-nginx 롤백을 시작해 09:43 에 마쳤다.
   • HMPPS 개발자들이 HMPPS Auth 로 가는 트래픽을 막는 규칙을 자기 ModSecurity 설정에서 예외 처리했다.
   • Cloud Platform 팀이 posthog 쿠키가 걸리는 규칙을 플랫폼의 모든 서비스에서 임시로 예외 처리했다.
   • 두 예외를 둔 상태로 새 ingress-nginx 를 다시 배포해 14:00 에 마쳤다.

   후속 조치

   • posthog 쿠키의 범위를 줄여 모든 *.justice.gov.uk 서비스로 가는 요청에 실리지 않게 했다. 다만 이 변경과 CRS 규칙 배포 사이가 짧아 사용자 브라우저의 쿠키가 만료되거나 바뀔 시간이 모자랐다.
   • posthog 쿠키가 충분히 많은 사용자 브라우저에서 만료되면 플랫폼 전체에 넣은 임시 예외를 없앤다.
   • 서비스 팀들에게 개발과 테스트 워크로드에 비운영 인그레스 컨트롤러를 쓰라고 다시 강조해, 이후 ModSecurity 와 CRS 업데이트에서 생길 문제를 미리 찾게 한다.
   • Cloud Platform 3.0 에서는 운영과 비운영 워크로드를 다른 클러스터로 나눠 비운영 워크로드가 반드시 비운영 인그레스를 거치게 한다.

   교훈

   WAF 규칙 세트 업데이트는 보안을 높이려는 변경이어도 정상 트래픽을 막을 수 있다. 베타 인그레스와 비운영 배포로 시험 기회를 줬어도 서비스 팀들이 개발과 테스트에 비운영 인그레스를 실제로 쓰지 않으면 Expect 헤더 같은 오탐은 운영에서야 드러난다. 시험에서 찾은 문제라도 쿠키처럼 사용자 브라우저에 남는 값이면 대응이 효과를 내기까지 시간이 걸린다. 팀은 롤백으로 먼저 영향을 끊고 예외를 준비한 뒤 다시 배포해 같은 날 업그레이드를 마쳤다.

   사례 보기
2. IL-0405 AWS Load Balancer Controller 의 webhook 인증서가 만료돼 US·Canada 지역의 BSEE SaaS 인스턴스가 전부 멈췄다

   PortSwigger2026

   증상

   US 와 Canada 지역 고객이 BSEE SaaS 인스턴스의 Web UI 에 들어가지 못했고 스캔도 시작하지 못했다. 엔지니어는 고객이 지원 창구로 알려 온 뒤에야 장애를 알았다.

   서비스 중단TLS 인증서 오류

   촉발

   PortSwigger 는 2025년 11월 28일 AWS Load Balancer Controller 를 v1.14.1 에서 v1.16.0 으로 올렸다. v1.15.0 의 Helm 차트가 인증서를 관리하는 방식을 바꿨고, 이 업그레이드 뒤에 소유자가 사라진 webhook 용 TLS Secret 이 남았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅cert-managerHelm컨피그맵과 시크릿클라우드 로드 밸런서

   기여 요인

   늦게 드러난 변경모니터링 사각지대

   감지

   엔지니어는 고객이 지원 창구로 신고한 뒤에야 장애를 알았다. 신고는 2026년 1월 12일 09:52 UTC 에 들어왔고, 영향이 시작되고 23시간 52분이 지난 때였다.

   조치

   • US 와 Canada 클러스터에서 소유자가 사라진 aws-load-balancer-tls Secret 을 지웠다.
   • Helm 으로 AWS Load Balancer Controller 설정을 다시 배포했다.
   • 인증서가 새로 만들어졌는지, webhook 이 제대로 동작하는지 확인했다.

   후속 조치

   • 모든 클러스터에서 소유자인 Certificate 리소스가 사라진 Secret 을 찾아 정리한다.
   • SaaS 클러스터마다 외부 프로브가 애플리케이션에 접속할 수 있는지 확인하고, 접속하지 못하면 알림을 보내게 한다.

   사례 보기
3. 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 가 롤아웃을 단계적으로 관리하면 업그레이드 위험이 줄어든다.

   사례 보기
4. IL-0079 GKE 노드가 새 ubuntu_containerd 이미지로 자동 업그레이드된 뒤 커널에서 kube-proxy 가 쓰는 iptables 확장이 빠져, 여러 GKE 클러스터의 인그레스 트래픽이 완전히 끊겼다.

   Altinity2025

   증상

   토요일인 5월 17일 이른 시각에 OpsGenie 알림이 울렸다. Altinity.Cloud 의 ClickHouse 클러스터 하나가 갑자기 조용해졌다. 쿼리도, 지표도, 접속하려는 고객의 로그도 들어오지 않았다. 파드는 모두 Running 이었고 노드도 정상으로 보였지만 데이터베이스까지 오는 트래픽이 없었다.

   서비스 중단

   촉발

   GKE 가 노드를 ubuntu_containerd 1.32.3-gke.1785003 이미지와 커널 6.8.0-1022-gke 로 자동 업그레이드했다. 이 커널은 nf_tables 모듈의 패키징이나 로딩 방식에 회귀가 있어 kube-proxy 가 쓰는 iptables 확장을 지원하지 않았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   kube-proxy노드 운영체제 이미지리눅스 커널클라우드 로드 밸런서

   기여 요인

   미패치 알려진 버그단계적 배포 부재

   감지

   OpsGenie 알림으로 알았다. ClickHouse 클러스터 하나에서 쿼리, 지표, 고객 접속 로그가 모두 끊겼고, 곧 다른 클러스터들도 같은 상태가 됐다.

   조치

   • 아직 영향받지 않은 클러스터에 유지보수 제외를 걸어 업그레이드를 모두 멈췄다. 이 조치로 문제가 GKE 에서 운영하는 모든 클러스터로 번지는 것을 막았다.
   • 로드밸런서 헬스 체크 정책을 바꿔 kube-proxy 헬스 체크 실패를 무시하게 했다. kube-proxy 에 필요한 확장이 없는 노드로도 트래픽이 흐르면서 서비스가 회복됐다.
   • 영향받은 클러스터 전부를 ubuntu_containerd 에서 nf_tables 문제가 없는 다른 커널을 쓰는 cos_containerd 이미지로 옮기기 시작했다. 노드를 새 이미지로 다시 만들어야 해서 짧은 다운타임이 생겼다.

   후속 조치

   • 회귀를 더 일찍 잡도록 이미지 사전 테스트 파이프라인을 넓힌다.
   • GKE 자동 업그레이드 예정 알림을 켜서 미리 대비한다.
   • 모든 클러스터에 GKE 유지보수 기간을 반드시 설정해 업그레이드가 배포되는 시점을 직접 정한다.
   • Google 이슈 트래커에 올린 커뮤니티 이슈를 추적하며 고쳐진 Ubuntu 이미지를 기다린다.

   교훈

   관리형 Kubernetes 의 노드 자동 업그레이드는 사용자가 검증하지 않은 커널을 운영 노드에 올린다. 클라우드 업체의 이미지 검증만 믿으면 이런 회귀를 막지 못한다. IPv6 를 쓰지 않아도 kube-proxy 는 IPv6 iptables 규칙을 적용하므로, 그 적용이 실패하면 로드밸런서 헬스 체크도 실패해 모든 인그레스가 끊길 수 있다. 영향받은 버전이 확인되면 아직 업그레이드되지 않은 클러스터의 업그레이드부터 멈춰야 피해가 번지지 않는다. Altinity 는 영향받은 사용자에게 externalTrafficPolicy: Cluster 로 바꿔 kube-proxy 헬스 체크를 끄고, 운영 노드 이미지를 cos_containerd 로 바꾸고, 고쳐진 이미지가 확인될 때까지 자동 업그레이드를 멈추라고 권한다.

   사례 보기
5. IL-0404 Karpenter 가 운영 EKS 노드를 Bottlerocket v1.26.0 으로 바꾼 뒤 BSEE SaaS 고객 인스턴스의 파드가 모두 crash loop back off 에 빠졌다

   PortSwigger2024

   증상

   2024년 10월 24일 BSEE SaaS 고객 인스턴스가 모두 Environment Unavailable 메시지를 띄웠다. 04:45 에 SaaS Uptime Over Time 지표의 가용률이 크게 떨어졌고, 08:07 에 Growth 팀이 장애를 채널에 알렸다.

   컨테이너 재시작 반복서비스 중단

   촉발

   2024년 10월 24일 eu-west-1 에 Bottlerocket v1.26.0 이 최신 AMI 로 나오자, Karpenter 가 이를 알아채고 04:00 부터 운영 EKS 클러스터의 EC2 노드를 새 버전으로 바꾸기 시작했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   노드 운영체제 이미지Karpenter

   기여 요인

   버전 미고정

   감지

   04:45 에 SaaS Uptime Over Time 지표의 가용률이 크게 떨어졌다. 08:07 에 Growth 팀이 BSEE cloud onboarding issues 채널에 장애를 알렸고, 08:15 에 Product 팀원이 기술팀에 구두로 알렸다.

   조치

   • 기술팀이 SaaS 운영 계정의 EC2 인스턴스를 모두 Bottlerocket v1.25.0 으로 되돌리기 시작했고, 09:15 에 고객 인스턴스가 다시 올라와 서비스가 복구됐다.
   • 모든 EKS 클러스터에 Bottlerocket 1.25.0 을 배포하고 새 EKS 노드로 교체했다.

   후속 조치

   • Karpenter 리소스를 바꿔 최신 AMI 대신 버전을 고정한 Bottlerocket AMI 를 배포하게 했다. 이 방식은 기술팀의 유지 보수 부담을 늘리고 중요한 보안 패치 배포를 늦출 수 있다.
   • Bottlerocket 릴리스 ATOM 피드를 내부 도구 릴리스 대시보드에 넣었다.
   • 고객에게 투명하게 알리는 공개 상태 페이지를 만든다.

   사례 보기

원인별1