Skip to main content

High availability

In a Kubernetes cluster, high availability affects two independent levels: the control plane and your workloads. These must be considered separately – a highly available control plane does not make a single application instance fault-tolerant.

High-availability control plane​

By default, a cluster’s control plane runs as a single instance. If it fails, pods that have already been started continue to run on the worker nodes, but the Kubernetes API is unavailable: it is not possible to roll out changes, reschedule pods or perform scaling operations.

With the High Availability option, the centron replicates the central control plane components. The built-in failover mechanism thus eliminates the single point of failure in the control plane.

PropertyValue
PricePer cluster per month, see the Kubernetes price overview
Service Level AgreementNo separate SLA commitment; see note below
ActivationUpon cluster creation or at a later date
RemovalNot possible
Availability

centron Managed Kubernetes comes with a guaranteed availability of 99.9%. The highly available control plane additionally reduces the technical risk of downtime by eliminating the single point of failure. The Managed Kubernetes service specification is the authoritative document.

Warnung

Once a high-availability control plane has been added, it cannot be removed from the cluster. The costs apply permanently to this cluster from the moment of activation.

High availability is recommended for production clusters. For test, development and training environments, the standard control plane is usually sufficient.

For information on how to activate this feature, see Enable High Availability.

High-availability workloads​

You determine the availability of your applications yourself through their configuration. The key points are:

Multiple replicas​

An application with only one replica is not fault-tolerant – neither in the event of a node failure nor during an upgrade. Run production services with at least two replicas.

At least two nodes per pool​

During upgrades and maintenance, nodes are restarted one after the other. With only one node in the pool, your application will be unavailable during this time. We therefore recommend at least 2 nodes per node pool.

Force distribution across nodes​

Without any further specifications, the scheduler may place several replicas on the same node – the failure of that single node would then affect all instances simultaneously. With topologySpreadConstraints or Pod Anti-Affinity, you can distribute replicas specifically across different nodes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: web
      containers:
        - name: web
          image: nginx:stable

Set an interruption budget​

A PodDisruptionBudget specifies how many pods from an application may be removed simultaneously during voluntary interruptions – such as when emptying a node as part of an upgrade:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

Defining Readiness Probes​

Without a readiness probe, Kubernetes forwards traffic to a pod as soon as its container has started – even if the application is not yet ready. Define readiness probes to ensure that only pods that are ready receive requests during a rollout.

Surge Upgrades​

When Surge Upgrades are enabled, centron temporarily provision additional nodes (up to 10) during an upgrade, before the old nodes are removed. This ensures that the cluster’s capacity is maintained throughout the upgrade. You can find this setting in the Settings tab of the cluster.

Hinweis

All prices are exclusive of VAT.

Last updated on