{"id":"IL-0464","org":"IONOS Cloud","date":"2026-03-14","docs":[],"title":{"en":"IONOS Managed Kubernetes control planes went unreachable for minutes at a time as their shared etcd grew and fragmented","ko":"IONOS 관리형 쿠버네티스의 고객 컨트롤 플레인 일부가 사흘 동안 몇 분씩 되풀이해 끊겼다"},"domain":["kubernetes"],"impact":{"scope":"A subset of customer Managed Kubernetes control planes periodically unreachable; DBaaS (PostgresDB on Kubernetes), the AI Model Hub and the Container Registry were also affected","users":"unknown","region":"DE/FRA (Managed Kubernetes)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.ionos.cloud/incidents/h9x5s66m4r28","kind":"official-status","archived":"https://web.archive.org/web/20260419042754/https://status.ionos.cloud/incidents/h9x5s66m4r28"}],"summary":{"en":"IONOS Managed Kubernetes keeps the state of many customer control planes in shared etcd databases. A few clusters stored unusually large amounts of data there, mainly security scanning reports and policy audit records, along with many event and autoscaling objects; on one affected database instance three clusters held about 64% of the stored data. The compaction interval that reclaims unused space could not keep up with the write rate, so old revisions piled up and the database grew past its normal size, and fragmentation added roughly 40% of allocated space beyond the data in use. This pushed the database toward its hard storage limit, where it would have gone read-only and taken down every control plane on that instance. Together these caused stalls during database maintenance cycles that disrupted the Kubernetes API server for several minutes each time.\n\nOn 16 March the team identified a resource constraint within etcd as the root cause. It defragmented the affected database instances, reclaiming about 3–4 GiB each, shortened their compaction intervals and rolled changes out to the affected clusters; DBaaS, the AI Model Hub and the Container Registry recovered during the day, and the final changes were applied to all affected clusters by 19:59 UTC. The incident was marked resolved on 17 March.","ko":"2026-03-14 부터 03-16 까지 IONOS Cloud 의 관리형 쿠버네티스에서 고객 컨트롤 플레인 일부가 주기적으로 몇 분씩 닿을 수 없었다. 근본 원인은 세 가지가 겹친 것이었다. 첫째, 몇몇 클러스터가 공유 컨트롤 플레인 데이터베이스에 보안 스캔 보고서와 정책 감사 기록을 주로 쌓았고, 이벤트와 오토스케일링 객체도 많이 쌓았다. 한 데이터베이스 인스턴스에서는 클러스터 셋이 저장된 데이터의 약 64% 를 차지했다. 둘째, 데이터베이스는 컴팩션으로 쓰지 않는 공간을 되찾게 설정돼 있었지만, 그 주기가 쓰기 속도를 따라가지 못해 과거 리비전이 쌓였다. 셋째, 데이터베이스가 커지면서 조각화로 실제 할당 크기가 쓰는 데이터보다 약 40% 커졌고, 하드 스토리지 한도에 다가갔다. 한도에 닿았다면 데이터베이스가 읽기 전용이 되어 그 인스턴스의 모든 클러스터에서 컨트롤 플레인이 완전히 멈췄을 것이다. 이 셋이 겹쳐 데이터베이스 유지 보수 주기마다 멈춤이 생겼고, 그때마다 쿠버네티스 API 서버가 흔들려 컨트롤 플레인을 쓸 수 없었다.\n\n03-16 10:04 UTC 에 원인을 etcd 데이터베이스의 자원 제약으로 찾았다. 11:05 UTC 에 DBaaS 와 AI Model Hub 를, 11:57 UTC 에 Container Registry 를 영향 범위에 더했다. 11:37 UTC 에 AI Model Hub 데이터베이스 서비스에 수정을 배포했고, AI Model Hub 는 12:22 UTC, Container Registry 는 12:57 UTC, DBaaS 는 13:56 UTC 에 복구로 표시했다. 영향받은 데이터베이스 인스턴스를 조각 모음해 인스턴스마다 약 3–4 GiB 를 되찾고 컴팩션 주기를 줄였으며, 19:58 UTC 에 영향받은 모든 클러스터에 마지막 변경을 적용했다. 컨트롤 플레인이 안정된 상태를 유지하자 03-17 17:04 UTC 에 해결로 닫았다."},"trigger":null,"severity":"unknown","symptoms":["control-plane-unresponsive","image-pull-failures"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["etcd","kube-apiserver","managed-control-plane"],"root_cause":"capacity","remediation":[{"text":{"en":"Defragmented the affected database instances, reclaiming about 3–4 GiB per instance","ko":"영향받은 데이터베이스 인스턴스를 조각 모음해 인스턴스마다 약 3–4 GiB 를 되찾고 정상 운영 여유를 되돌렸다."}},{"text":{"en":"Shortened the database compaction intervals on the affected instances","ko":"영향받은 인스턴스에서 데이터베이스 컴팩션 주기를 줄였다."}},{"text":{"en":"Deployed a fix for the affected AI Model Hub database services","ko":"03-16 11:37 UTC 에 쿠버네티스 팀이 영향받은 AI Model Hub 데이터베이스 서비스에 수정을 배포했다."}},{"text":{"en":"Applied final changes to all affected clusters","ko":"03-16 19:58 UTC 에 영향받은 모든 클러스터에 마지막 변경을 적용했다."}}],"action_items":[{"text":{"en":"Expand monitoring dashboards to show control plane health per database instance","ko":"데이터베이스 인스턴스별 컨트롤 플레인 상태가 잘 보이도록 모니터링 대시보드를 넓힌다."}},{"text":{"en":"Move the highest-volume clusters to dedicated database backends","ko":"데이터가 가장 많은 클러스터를 전용 데이터베이스 백엔드로 옮겨 그 워크로드가 같은 데이터베이스 인스턴스의 다른 클러스터에 주는 영향을 없앤다."}},{"text":{"en":"Make incidents of this kind trigger immediate paging","ko":"이런 장애가 나면 곧바로 호출 알림이 가서 사람이 제때 개입하도록 알림을 개선한다."}},{"text":{"en":"Roll the updated compaction interval out to all shared control plane database instances","ko":"바꾼 컴팩션 주기를 모든 공유 컨트롤 플레인 데이터베이스 인스턴스에 적용한다."}},{"text":{"en":"Run automated, scheduled defragmentation jobs on all instances","ko":"조각화가 쌓이지 않도록 모든 인스턴스에 정해진 일정으로 도는 자동 조각 모음 작업을 둔다."}},{"text":{"en":"Rebalance clusters across database instances to reduce concentration","ko":"한곳에 몰리는 위험을 줄이도록 데이터베이스 인스턴스 사이의 클러스터 배치를 다시 맞춘다."}},{"text":{"en":"Contact customers whose clusters write disproportionate data, for example to store large security scan reports outside the control plane database","ko":"4주 안에 데이터를 지나치게 많이 만드는 클러스터의 고객에게 직접 연락해, 큰 보안 스캔 보고서를 컨트롤 플레인 데이터베이스가 아닌 외부 스토리지 백엔드에 두는 것 같은 워크로드 최적화를 논의한다."}},{"text":{"en":"Introduce per-tenant resource quotas and key-count limits on the shared control plane database","ko":"1~3개월 안에 공유 컨트롤 플레인 데이터베이스에 테넌트별 자원 쿼터와 키 개수 한도를 두어, 클러스터 하나가 다른 클러스터에 영향을 주지 못하게 한다."}},{"text":{"en":"Re-architect the shared control plane for stronger isolation, with dedicated database instances and better vertical scaling","ko":"2026년 2분기부터 공유 컨트롤 플레인을 다시 설계해 전용 데이터베이스 인스턴스를 두고 수직 확장을 개선해 고객 워크로드 사이의 격리를 강화한다."}},{"text":{"en":"Evaluate full database sharding for customers with consistently high data volumes","ko":"데이터가 꾸준히 많은 고객을 위해 데이터베이스를 완전히 샤딩하는 방안을 검토한다."}},{"text":{"en":"Hold regular drills on database resource exhaustion and recovery","ko":"다음 장애의 대응 시간을 줄이도록 데이터베이스 자원 고갈과 복구를 다루는 운영 훈련을 정기적으로 한다."}}],"contributing":["blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"From 14 to 16 March 2026 a subset of customer control planes on IONOS Managed Kubernetes (MK8s) became unavailable again and again, each time for several minutes. While a cluster was unreachable, operations that depend on the Kubernetes API, such as deployments, scaling and health checks, did not work reliably.\n\nOn 16 March the incident widened to other services: an increased error count from PostgresDB on Kubernetes in DBaaS, the AI Model Hub, and the Container Registry, where customers had trouble pulling and pushing images. The stalls came during database maintenance cycles of the shared control plane database, and the team described the remaining problem as recurring load spikes.","ko":"2026-03-14 부터 고객의 관리형 쿠버네티스 컨트롤 플레인 일부가 주기적으로 응답하지 않았다. 영향받은 클러스터에는 그때마다 몇 분씩 닿을 수 없었고, 배포, 스케일링, 헬스체크처럼 쿠버네티스 API 에 기대는 작업이 제대로 동작하지 않았다. 상태 페이지에는 2026-03-16 08:24 UTC 에 일부 고객이 컨트롤 플레인 연결 문제와 쿠버네티스 기능 저하를 겪을 수 있다고 처음 올라왔다.\n\n끊김은 컨트롤 플레인 데이터베이스의 유지 보수 주기에 맞춰 되풀이됐다. 데이터베이스가 유지 보수 중에 멈출 때마다 쿠버네티스 API 서버가 잠시 흔들렸다.\n\n장애는 다른 서비스로 번졌다. 11:05 UTC 에 PostgresDB on Kubernetes 에서 오류가 늘어 DBaaS 와 AI Model Hub 가 영향 범위에 들어갔고, 11:57 UTC 에는 Container Registry 가 더해져 고객이 레지스트리에서 이미지를 풀하고 푸시하는 데 문제를 겪을 수 있었다. 영향은 DE/FRA 의 Managed Kubernetes 에 미쳤다."},"updated_at":"2026-11-14T12:34:11.197814Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0464","org_slug":"ionos-cloud"}