How managed Kubernetes limits outages

When a critical application goes down, every second counts. For Swiss organisations under FINMA regulation or handling sensitive data, an outage can cost far more than a service interruption. It can compromise compliance, customer trust and the company's reputation. That is precisely why managed Kubernetes becomes a strategic asset for limiting the risk of failure.

This article covers three things: preventing an outage, diagnosing it when it happens, and knowing what comes back on its own. The architecture that makes it possible, replicated control plane, etcd quorum, storage across three sites, is explained in Multi-datacenter Kubernetes HA. The procedure for spreading a workload across the three sites is in the guide Kubernetes across three datacenters.

Key points: how managed Kubernetes limits outages

• Kubernetes watches pod health and restarts those that fail their probes, provided a healthy node can take them.
• Storage replication protects your data. It does not make your applications available: those are two distinct layers.
• A managed control plane removes the operational complexity of etcd, certificates and upgrades.
• Hikube replicates the control plane and, depending on the replication mode chosen, persistent volumes across Geneva, Gland and Lucerne. Spreading your pods across sites remains yours to configure: topology spread and PodDisruptionBudget.
• Liveness and readiness probes catch anomalies before they reach your users, if their thresholds are set to the application's real behaviour.

Diagnosing, the three layers where a failure happens

A failure in Kubernetes takes one of three forms, and the first question is which one. A pod, a node, or the control plane: the answer determines who acts and what can be expected.

A pod failure

The application crashes or stops responding. The pod fails its probe, the scheduler redeploys it on a healthy node. This is the most common case, and the one the platform handles without you, as long as capacity remains elsewhere.

A node failure

Hardware fault, network failure or resource exhaustion. Every pod hosted on that node becomes unavailable until it restarts elsewhere. The telltale sign: several services fail at once, with no functional link between them.

A control plane failure

The API server, scheduler, controller manager and etcd form the cluster's brain. If the control plane is unavailable you can no longer deploy or change anything, but the pods already running keep running. On Hikube this layer is operated by Hidora SA: it is the one case of the three where the diagnosis is not yours.

Preventing, what gets configured before the outage

High availability is not improvised. It is declared, in your manifests, before the incident.

Health probes: liveness and readiness

Liveness probes check whether the application is alive; if a container fails that test, Kubernetes restarts it. Readiness probes indicate whether the pod is ready to accept connections, and pull those that are not out of service.

For regulated applications where every millisecond counts, these probes need thresholds matched to the workload. Too long an interval delays detection. Too short an interval produces false positives and needless restarts.

Replicas, PodDisruptionBudget and anti-affinity

This is the part that falls to you, and nothing replaces it. Start by defining several replicas for every critical deployment: a minimum of three keeps the service up if two instances go down. Use PodDisruptionBudgets to guarantee a minimum number of pods stays available during maintenance.

Affinity and anti-affinity control how pods spread across nodes, and topology spread constraints control how they spread across sites. An anti-affinity rule stops two replicas of the same service from running on the same physical node. Without these declarations, nothing stops your replicas from sharing the node, or the datacenter, that is about to fail.

Storage replication

Persistent volumes hold the data of your stateful applications, such as databases and message queues. A storage failure can mean irreversible data loss.

The replicated storage class distributes data across several nodes and several independent datacenters. Hikube offers synchronous or asynchronous replication of persistent volumes across Geneva, Gland and Lucerne; the mode you choose determines your RPO. If a site fails, the copies remain readable from the operational sites.

For workloads that need regular backups, pair Velero with S3 object storage. Replication protects against a site failure; it does not protect against an accidental deletion, which replicates too.

Monitoring and alerting

Catching anomalies early keeps minor incidents from becoming major outages. An effective monitoring system collects metrics, aggregates logs and fires alerts before users are affected.

Deploy a full observability stack with Grafana for visualisation, VictoriaMetrics for metrics and VictoriaLogs for centralised logs. These tools integrate natively with Kubernetes and ship preconfigured dashboards for each resource type.

Set alerts on the key indicators: node CPU and memory usage, pod error rate, API request latency. An alert firing at 80% usage leaves time to act before full saturation.

Recovering: what comes back on its own, what does not

What the platform handles without you

A container failing its liveness probe is restarted. A pod whose node disappears is rescheduled elsewhere if a healthy node has the capacity to take it. The control plane is replicated and updated by Hidora SA: you do not manage etcd, do not watch the quorum, do not trigger its failover.

What does not come back on its own

A single-replica deployment, there is nothing to fail over to while it restarts. Replicas that all sat on the site that went down, for lack of topology spread. A pod the PodDisruptionBudget forbids moving, or that no remaining node can host. A volume whose replication mode was never enabled. In each of these cases the platform behaves exactly as designed and your application is down: the difference is in the configuration, not the infrastructure.

Replication, application availability, RPO and RTO

Four distinct notions, often conflated. Replication sits at the volume level: your data exists in several copies. Application availability sits at your pods: it comes from spread and PDB, not from replication. RPO, the amount of data lost, depends on the replication mode, synchronous or asynchronous. RTO, the time to restore service, is not covered by the SLA: repair times are not guaranteed and no MTTR is published; a committed deadline is contracted case by case. The exact scope is on security and compliance.

What are the specific requirements for regulated applications?

Finance, healthcare and government impose strict constraints on availability and data residency. A Kubernetes cluster intended for these workloads must meet GDPR, nFADP and FINMA compliance requirements.

Data sovereignty guarantees your information stays under Swiss jurisdiction. US hyperscalers are subject to the Cloud Act, which can compel them to disclose data to foreign authorities. A Swiss provider such as Hikube operates exclusively under Swiss law, one of the most protective in the world.

ISO 27001 certification attests that security and incident management processes meet international standards. It covers the full chain, from the datacenters to the operational procedures.

How do you optimise latency between the three sites?

Synchronous replication introduces network latency between datacenters. For latency-sensitive applications, that cost has to be measured on your own write profile before it is traded away.

Use zone-affinity routing to steer traffic to pods in the same datacenter. This reduces network hops and improves response times for end users, at the price of a less even spread.

For workloads needing minimal latency, consider dedicated GPU resources with direct hardware access. Hikube offers L40S, A100 and H100 GPUs attached directly to the nodes for native performance without virtualisation.

Conclusion: building a resilient Kubernetes infrastructure

Limiting outages in a Kubernetes environment takes a systematic approach and a clear split of responsibilities. Probes, monitoring and storage replication reduce the chance of an incident. Replicas, spread and PDB determine what survives when one happens.

For Swiss organisations in regulated sectors, sovereign managed Kubernetes removes an entire layer of that work: the control plane is operated and updated, and the data stays in Switzerland under local law.

Hikube replicates the control plane and volumes, depending on the mode chosen, across Geneva, Gland and Lucerne, and targets recovery of the control plane without intervention. Application recovery times depend on your configuration, and are not the subject of a published commitment.

FAQ on managed Kubernetes and failure handling

How long does it take to recover from a node failure?

Kubernetes reschedules the pods onto healthy nodes with no manual intervention. The delay depends on the probe, the image size and the remaining capacity; Hikube publishes no RTO.

Does multi-site replication affect performance?

Synchronous replication adds write latency between sites. Measure it on your real profile rather than on a generic figure. Zone-affinity routing limits that impact for latency-sensitive applications.

How does Hikube handle the complete loss of a datacenter?

The control plane keeps its quorum on the two remaining sites and carries on scheduling. The worker nodes of the other two sites remain, and the copies of your replicated volumes stay readable there. Your applications, though, survive only if you declared several replicas, topology spread constraints and a PodDisruptionBudget: application failover is not automatic by default.

Which compliance certifications are available?

Hikube and its datacenters are ISO 27001 certified. The platform is GDPR and nFADP compliant, with data stored exclusively in Switzerland under Swiss jurisdiction.

Can I test my cluster's resilience before production?

Yes, you can simulate node failures and check how your applications behave in a staging environment. Tools such as Chaos Mesh inject failures in a controlled way to validate your high-availability configuration.