Incident Library

IL-0234 IONOS Cloud · 2026-05-08kubernetes

내부 배포 자동화가 개발용 애플리케이션을 고객의 Managed Kubernetes 클러스터들에 잘못 설치해 컨트롤 플레인 연결과 쿠버네티스 기능에 문제가 났다

2026-05-08 UTC+2 기준 15:22 에서 16:12 사이에, 새 Managed Kubernetes 개발 클러스터를 등록하는 정기 내부 작업 때문에 배포 자동화 시스템이 다른 클러스터들까지 대상으로 삼았다. 자동화는 그 클러스터들의 구성을 바꾸고 개발 클러스터용 애플리케이션을 설치했다. 일부 고객은 컨트롤 플레인 연결 문제와 쿠버네티스 기능 저하를 겪었고, 영향은 DE/TXL, DE/FRA, DE/FRA/2 의 Managed Kubernetes 에 미쳤다. 설치된 애플리케이션은 필요한 image pull secret 이 없어 실행되지 못했다.

onboarding operator 는 클러스터를 배포 시스템에 등록하는 일을 하며, 범위 설정 파일로 작업 대상을 정해진 클러스터로 제한한다. 이번 등록 작업에서 이 파일은 배포 브랜치로 자동 전파되어야 했다. 하지만 병합 충돌로 전파가 아무 경고 없이 실패했다. cherry-pick 실패는 로그에 남았지만 파이프라인을 막지 않았다. 같은 때 다른 변경이 onboarding operator 를 제외 목록에서 뺐고, 곧바로 배포가 시작되었다. 배포 시스템은 설정이 빠졌을 때 동기화를 멈추도록 구성되어 있지 않아, operator 가 범위 제한 없이 배포되었다. 제한이 없는 operator 는 cluster-api 기반의 다른 클러스터들도 등록 대상으로 여겼다. IONOS 는 원인으로 두 가지를 들었다. 하나는 operator 의 소프트웨어 버그였다. 다른 하나는 필요한 설정 파일이 대상 브랜치에 다 들어갔는지 배포 전에 확인하는 장치가 파이프라인에 없었다는 점이었다. 배포를 지켜보던 팀에게는 모든 것이 정상으로 보였다.

팀은 원인을 찾은 뒤 operator 를 고치고 배포 시스템 설정을 강화했다. 영향을 받은 리소스의 변경을 되돌리는 롤백을 5월 8일 저녁에 마쳤고, 5월 11일에 장애를 해결로 표시했다. 복구 스크립트를 만들어 스테이징에서 검증한 뒤 운영의 모든 영향 클러스터에 돌렸고, 5월 15일까지 의도하지 않은 설치와 변경을 모두 지웠다.

심각도
–
영향 범위
Additional Managed Kubernetes clusters were modified and received applications meant for a development cluster; some customers had control plane connection problems and degraded Kubernetes functionality, and cleanup ran until 15 May 2026
영향 사용자
Some Managed Kubernetes customers
지역
DE/TXL, DE/FRA and DE/FRA/2
감지까지
–
복구까지
–

증상

2026-05-08 15:15 UTC 에 상태 페이지에 공지가 올라왔다. 일부 고객이 컨트롤 플레인에 연결하지 못하고 쿠버네티스 기능이 떨어질 수 있다는 내용이었다. 영향을 받은 곳은 DE/TXL, DE/FRA, DE/FRA/2 의 Managed Kubernetes 였다.

영향을 받은 클러스터에는 개발 클러스터용 애플리케이션이 설치되고 클러스터 구성이 바뀌어 있었다. 이 애플리케이션들은 그 환경에 필요한 image pull secret 이 없어 이미지를 받지도 실행하지도 못했다.

15:52 UTC 에 쿠버네티스 엔지니어링 팀이 구성 필터링 방식의 결함을 원인으로 찾았다고 알렸다. 그 뒤 팀은 영향을 받은 리소스를 점검해 남은 잘못된 구성 변경이 모두 되돌려졌는지 확인했다.

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

원인

원인 배포 결함

구성 요소 CI 시스템컨테이너 레지스트리와 자격 증명
기여 요인 설정 테스트 부재과도한 영향 범위리뷰 누락
촉발
새 Managed Kubernetes 개발 클러스터를 등록하는 정기 내부 작업에서 onboarding operator 를 제외 목록에서 빼는 변경이 들어가자 곧바로 배포가 시작되었다. 이때 operator 의 대상 범위를 정하는 설정 파일은 병합 충돌로 배포 브랜치에 들어가지 못한 상태였다.

감지

–

조치

후속 조치

교훈

클러스터 구성이 의도하지 않게 바뀐 것은 내부 작업이 고객 환경에 영향을 주지 못하게 막아야 할 통제가 실패했기 때문이다. 정리 작업 동안 영향을 받은 고객에게 진행 상황을 제대로 알리지 않아 불확실성이 더 커졌다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: CI 시스템, 컨테이너 레지스트리와 자격 증명. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.