사례32건

32건 중 1~5번째

1. IL-0069 공격자가 탈취한 서비스 어카운트 토큰으로 운영 쿠버네티스 클러스터에서 클라우드 백엔드와 금융 인프라까지 옮겨 가 암호화폐 거래소의 자금을 훔쳤다.

   Unnamed cryptocurrency exchange2026

   증상

   운영 쿠버네티스 클러스터에 공격자가 배포한 악성 파드가 올라왔다. 이 파드는 마운트된 서비스 어카운트 토큰을 밖으로 빼내도록 만들어져 있었다.

   무단 접근과 낯선 워크로드

   촉발

   공격자는 스피어피싱으로 거래소 개발자의 워크스테이션에 발판을 마련했다. 그 개발자의 권한 높은 클라우드 세션이 열려 있는 것을 이용해 운영 쿠버네티스 클러스터에 악성 파드를 배포했다.

   원인

   자격 증명 유출

   구성 요소

   RBAC 와 서비스 어카운트쿠버네티스 API 서버

   기여 요인

   과도한 영향 범위

   교훈

   RBAC 가 잘못됐거나 너무 넓으면 쿠버네티스 신원 하나가 클라우드 전체로 옮겨 가는 발판이 된다. Unit 42 는 RBAC 역할을 좁게 잡고 Restricted Pod Security 프로필을 쓰라고 권한다. 서비스 어카운트 토큰은 파드 수명에 묶이고 유효 기간이 짧은 projected 토큰으로 바꿔서, 빼앗기더라도 금방 쓸 수 없게 해야 한다. 쿠버네티스 감사 로그와 런타임 모니터링으로 ClusterRoleBinding 수정 시도, 낯선 IP 에서 쓰인 서비스 어카운트 토큰, 민감한 네임스페이스에 나타난 파드를 지켜봐야 한다.

   사례 보기
2. IL-0464 IONOS 관리형 쿠버네티스의 고객 컨트롤 플레인 일부가 사흘 동안 몇 분씩 되풀이해 끊겼다

   IONOS Cloud2026

   증상

   2026-03-14 부터 고객의 관리형 쿠버네티스 컨트롤 플레인 일부가 주기적으로 응답하지 않았다. 영향받은 클러스터에는 그때마다 몇 분씩 닿을 수 없었고, 배포, 스케일링, 헬스체크처럼 쿠버네티스 API 에 기대는 작업이 제대로 동작하지 않았다. 상태 페이지에는 2026-03-16 08:24 UTC 에 일부 고객이 컨트롤 플레인 연결 문제와 쿠버네티스 기능 저하를 겪을 수 있다고 처음 올라왔다.

   컨트롤 플레인 무응답이미지 풀 실패

   원인

   용량 한계

   구성 요소

   etcd쿠버네티스 API 서버관리형 쿠버네티스 컨트롤 플레인과 제공자 API

   기여 요인

   과도한 영향 범위

   조치

   • 영향받은 데이터베이스 인스턴스를 조각 모음해 인스턴스마다 약 3–4 GiB 를 되찾고 정상 운영 여유를 되돌렸다.
   • 영향받은 인스턴스에서 데이터베이스 컴팩션 주기를 줄였다.
   • 03-16 11:37 UTC 에 쿠버네티스 팀이 영향받은 AI Model Hub 데이터베이스 서비스에 수정을 배포했다.
   • 03-16 19:58 UTC 에 영향받은 모든 클러스터에 마지막 변경을 적용했다.

   후속 조치

   • 데이터베이스 인스턴스별 컨트롤 플레인 상태가 잘 보이도록 모니터링 대시보드를 넓힌다.
   • 데이터가 가장 많은 클러스터를 전용 데이터베이스 백엔드로 옮겨 그 워크로드가 같은 데이터베이스 인스턴스의 다른 클러스터에 주는 영향을 없앤다.
   • 이런 장애가 나면 곧바로 호출 알림이 가서 사람이 제때 개입하도록 알림을 개선한다.
   • 바꾼 컴팩션 주기를 모든 공유 컨트롤 플레인 데이터베이스 인스턴스에 적용한다.
   • 조각화가 쌓이지 않도록 모든 인스턴스에 정해진 일정으로 도는 자동 조각 모음 작업을 둔다.
   • 한곳에 몰리는 위험을 줄이도록 데이터베이스 인스턴스 사이의 클러스터 배치를 다시 맞춘다.
   • 4주 안에 데이터를 지나치게 많이 만드는 클러스터의 고객에게 직접 연락해, 큰 보안 스캔 보고서를 컨트롤 플레인 데이터베이스가 아닌 외부 스토리지 백엔드에 두는 것 같은 워크로드 최적화를 논의한다.
   • 1~3개월 안에 공유 컨트롤 플레인 데이터베이스에 테넌트별 자원 쿼터와 키 개수 한도를 두어, 클러스터 하나가 다른 클러스터에 영향을 주지 못하게 한다.
   • 2026년 2분기부터 공유 컨트롤 플레인을 다시 설계해 전용 데이터베이스 인스턴스를 두고 수직 확장을 개선해 고객 워크로드 사이의 격리를 강화한다.
   • 데이터가 꾸준히 많은 고객을 위해 데이터베이스를 완전히 샤딩하는 방안을 검토한다.
   • 다음 장애의 대응 시간을 줄이도록 데이터베이스 자원 고갈과 복구를 다루는 운영 훈련을 정기적으로 한다.

   사례 보기
3. IL-0183 kubeadm 으로 만든 클러스터의 1년짜리 인증서가 만료되어 kube-apiserver 가 etcd 와 TLS 연결을 맺지 못하고 재시작을 반복했고, 클러스터에 접속할 수 없게 됐다.

   ckck8032026

   증상

   외부에서 쿠버네티스 클러스터에 접속할 수 없었다. 작성자는 컨트롤 플레인 노드로 들어가 sudo systemctl status kubelet 으로 kubelet 로그를 확인했다.

   컨트롤 플레인 무응답컨테이너 재시작 반복

   촉발

   kubeadm 이 만든 하위 인증서의 기본 유효기간 1년이 2026-02-20 16:16 UTC 에 끝났다.

   원인

   인증서·자격 증명 만료

   구성 요소

   쿠버네티스 API 서버etcdkubeletCalico

   기여 요인

   기본 설정 방치

   감지

   외부에서 클러스터에 접속이 안 되는 것으로 알아챘다. 컨트롤 플레인 노드에서 kubelet 로그, containerd 로그, kube-apiserver 컨테이너 로그를 차례로 보다가 kube-apiserver 로그의 x509 만료 오류에서 원인을 확인했다.

   조치

   • sudo kubeadm certs renew all 로 만료된 인증서를 한 번에 갱신했다.
   • containerd 와 kubelet 을 재시작해 Static Pod 로 도는 컨트롤 플레인 컴포넌트를 새 인증서로 다시 띄웠다.
   • /etc/kubernetes/admin.conf 를 $HOME/.kube/config 로 복사하고 소유자를 바꿔 kubeconfig 를 새 인증서로 바꿨다.

   교훈

   sudo kubeadm certs check-expiration 으로 만료일을 주기적으로 확인하고, 만료 30일 전부터 갱신하는 것이 좋다. kubeadm upgrade apply 를 실행하면 인증서도 함께 갱신되므로, 1년에 한 번 이상 쿠버네티스 버전을 올리는 클러스터는 이 문제를 자연스럽게 피한다. 버전을 올리지 않고 오래 운영하는 클러스터라면 kubeadm certs renew all 과 kubelet 재시작을 cron 으로 매년 걸어 둘 수 있다. 작성자가 든 예시에서는 매년 1월 1일 새벽 3시에 실행한다.

   사례 보기
4. IL-0138 nvidia-dkms-390 드라이버 빌드 실패로 망가진 커널 헤더가 몇 주 동안 방치됐다가, 정전 뒤 재부팅하자 하나뿐인 마스터 노드가 커널 패닉에 빠져 홈랩 쿠버네티스 클러스터가 6일 동안 멈췄다.

   Barush Mendez2025

   증상

   2025년 3월 3일 14:15:34부터 홈랩 쿠버네티스에 올린 서비스에 접속되지 않았다. 운영자가 서비스에 들어가려다 직접 알아챘고, 알아채기까지 3시간이 걸렸다.

   컨트롤 플레인 무응답서비스 중단모니터링 중단

   촉발

   정전 때문에 마스터 노드가 재부팅됐다.

   원인

   소프트웨어 결함

   구성 요소

   GPU 드라이버리눅스 커널쿠버네티스 API 서버

   기여 요인

   초기 신호 무시늦게 드러난 변경단일 장애점모니터링 사각지대

   감지

   운영자가 서비스에 접속하려다 직접 알아챘다. 자동 알림이 없어서 알아채기까지 3시간이 걸렸다.

   조치

   • 원격 접속이 되지 않아 모니터를 연결해 부팅 로그를 보고 커널 패닉을 확인했다.
   • 이전 커널 버전으로 부팅해 시스템을 되살렸다.
   • sudo apt-get remove --purge '^nvidia-.*' 로 망가진 패키지를 지우고 sudo dpkg --configure -a 로 패키지 설정 문제를 고쳤다.
   • dpkg -l | grep -v ^ii 로 남은 망가진 패키지를 찾아 sudo apt-get remove --purge <package_name> 으로 하나씩 지웠다.
   • sudo apt-get install -f 로 빠진 의존성을 채우고 sudo apt-get install --reinstall linux-headers-$(uname -r) 로 커널 헤더를 다시 설치했다.
   • 머신을 재부팅해 커널 패닉이 사라진 것을 확인했다.

   후속 조치

   • GPU 드라이버 설치가 완전히 성공했는지 확인하고, 오류가 나면 바로 변경을 되돌린다.
   • 단일 장애 지점을 없애도록 클러스터를 고가용성 구성으로 옮긴다.
   • 고가용성 구성에서 Kube-API 를 로드 밸런서 뒤에 둔다.
   • 장애를 기록하고 해결 과정을 추적할 티켓 시스템을 만든다.
   • 미리 정해 둔 문제 해결 절차를 만들어 홈랩 장애 대응 시간을 줄인다.
   • Prometheus 와 Grafana 같은 인프라 모니터링을 넣어 문제를 미리 잡는다.
   • 주요 서비스에 HTTP, TCP 검사를 거는 블랙박스 모니터링을 넣어 쿠버네티스 클러스터 밖에서도 장애를 잡는다.

   교훈

   드라이버 빌드 실패를 그대로 두면 몇 주 뒤 재부팅 때 터질 수 있다. 자동 알림이 없어서 발견과 복구가 늦었다. 마스터 노드가 하나뿐이라 노드 하나의 고장이 클러스터 전체 장애가 됐다. 원인을 찾은 뒤에는 비교적 간단히 고쳤고, 데이터 손실은 없었다.

   사례 보기
5. 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 가 재시작될 수 있었다.

   사례 보기

원인별9