Cases2 cases
1 to 2 of 2
IL-0234An onboarding operator deployed without its scope file installed dev applications on other IONOS Kubernetes clustersIONOS Cloud2026- Symptoms
On 8 May 2026 IONOS Cloud reported "K8s Control Planes not available": some Managed Kubernetes customers in DE/TXL, DE/FRA and DE/FRA/2 had trouble connecting to the control plane and saw degraded Kubernetes functionality. Between 15:22 and 16:12 (UTC+2) applications meant for a new internal development cluster were installed on other customer clusters, which were also modified.
- Trigger
A routine internal operation onboarded a new Managed Kubernetes development cluster. The scoping configuration file for the onboarding operator failed to reach the deployment branch because of a merge conflict, and at the same time a second change removed the operator from the exclusion list, which deployed it at once.
- Root cause
- Component
- Contributing factor
- Remediation
- Corrected the onboarding operator so it needs an explicit namespace configuration before acting on any cluster
- Reconfigured the deployment system to fail deployments when required configuration files are missing
- Rolled back the identified changes on the affected resources
- Ran a recovery script, validated in staging, that removed all unintended installations and updates from the affected clusters
- Action items
- Add a mandatory CI/CD step that confirms all required configuration files reached the target branch before any deployment starts
- Require additional peer review and change management approval for every deployment that touches production, whatever its size
- Give teams a way to inform each affected customer in time about the status of post-incident cleanup
- Lessons
IONOS treats the unintended change to cluster configurations as a failure of the controls that should keep internal operations from affecting customer environments.
IL-0464IONOS Managed Kubernetes control planes went unreachable for minutes at a time as their shared etcd grew and fragmentedIONOS Cloud2026- Symptoms
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.
- Root cause
- Component
- Contributing factor
- Remediation
- Defragmented the affected database instances, reclaiming about 3–4 GiB per instance
- Shortened the database compaction intervals on the affected instances
- Deployed a fix for the affected AI Model Hub database services
- Applied final changes to all affected clusters
- Action items
- Expand monitoring dashboards to show control plane health per database instance
- Move the highest-volume clusters to dedicated database backends
- Make incidents of this kind trigger immediate paging
- Roll the updated compaction interval out to all shared control plane database instances
- Run automated, scheduled defragmentation jobs on all instances
- Rebalance clusters across database instances to reduce concentration
- Contact customers whose clusters write disproportionate data, for example to store large security scan reports outside the control plane database
- Introduce per-tenant resource quotas and key-count limits on the shared control plane database
- Re-architect the shared control plane for stronger isolation, with dedicated database instances and better vertical scaling
- Evaluate full database sharding for customers with consistently high data volumes
- Hold regular drills on database resource exhaustion and recovery
These 2 cases involve CI system and etcd. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause2
Faulty deployment1 case
- Contributing factor
- Organisation
Capacity exhaustion1 case
- Contributing factor
- Organisation