Gardener Architecture

Our managed Kubernetes service is built on Gardener — an open-source Kubernetes-as-a-Service platform that lets us run Kubernetes clusters at scale. This page explains the architecture so you understand what happens behind the scenes when you create a cluster in the Cloud Services Portal.

What is Gardener?

Gardener is an open-source project that provides Kubernetes clusters as a service. Instead of managing each cluster's control plane individually on dedicated master nodes, Gardener consolidates control planes onto a shared management cluster. This makes it possible to operate dozens of clusters efficiently with centralised updates, monitoring, and backups.

Seed and Shoot

Gardener uses two key concepts:

How it works

1. You create a cluster in the Cloud Services Portal.
2. The portal calls the Gardener API on the Seed cluster.
3. Gardener provisions a control plane (API server, etcd, scheduler, controller-manager) for your shoot as a set of pods in a dedicated namespace on the Seed.
4. Gardener provisions worker nodes as OpenStack VMs in the region you selected.
5. Your shoot cluster is ready — you connect with kubectl using the kubeconfig from the portal.

The key insight: your cluster's control plane runs on the Seed, not on your worker nodes. The worker nodes only run your workloads (pods). This separation is what makes the service "managed" — we handle control plane updates, HA, and etcd backups; you handle your applications.

%%{init: {'themeVariables': {'textColor': '#333333', 'edgeLabelBackground': '#ffffff', 'clusterBkg': 'transparent', 'clusterBorder': '#999999'}}}%%
flowchart TD
    Portal["Cloud Services Portal"]

    subgraph Seed ["Gardener Seed Cluster (managed)"]
        CP1["Shoot A · Control Plane<br>API server · etcd · scheduler"]
        CP2["Shoot B · Control Plane<br>API server · etcd · scheduler"]
    end

    subgraph ZH ["OpenStack · ch-zh1 · Zurich"]
        W1["Worker Node"]
        W2["Worker Node"]
    end

    subgraph GE ["OpenStack · ch-ge1 · Geneva"]
        W3["Worker Node"]
        W4["Worker Node"]
    end

    Portal -->|"Gardener API"| CP1
    Portal -->|"Gardener API"| CP2
    CP1 -->|"manages"| W1
    CP1 -->|"manages"| W2
    CP2 -->|"manages"| W3
    CP2 -->|"manages"| W4

    classDef portal fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
    classDef cp fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    classDef worker fill:#fff3e0,stroke:#e65100,color:#bf360c;
    class Portal portal;
    class CP1,CP2 cp;
    class W1,W2,W3,W4 worker;
    linkStyle 0,1 stroke:#1565c0,stroke-width:2px;
    linkStyle 2,3,4,5 stroke:#2e7d32,stroke-width:2px;

%%{init: {'themeVariables': {'textColor': '#e0e0e0', 'edgeLabelBackground': '#2a2a2a', 'clusterBkg': 'transparent', 'clusterBorder': '#666666'}}}%%
flowchart TD
    Portal["Cloud Services Portal"]

    subgraph Seed ["Gardener Seed Cluster (managed)"]
        CP1["Shoot A · Control Plane<br>API server · etcd · scheduler"]
        CP2["Shoot B · Control Plane<br>API server · etcd · scheduler"]
    end

    subgraph ZH ["OpenStack · ch-zh1 · Zurich"]
        W1["Worker Node"]
        W2["Worker Node"]
    end

    subgraph GE ["OpenStack · ch-ge1 · Geneva"]
        W3["Worker Node"]
        W4["Worker Node"]
    end

    Portal -->|"Gardener API"| CP1
    Portal -->|"Gardener API"| CP2
    CP1 -->|"manages"| W1
    CP1 -->|"manages"| W2
    CP2 -->|"manages"| W3
    CP2 -->|"manages"| W4

    classDef portal fill:#1a3a5c,stroke:#64b5f6,color:#e3f2fd;
    classDef cp fill:#1b3a2a,stroke:#66bb6a,color:#c8e6c9;
    classDef worker fill:#3e2723,stroke:#ff9800,color:#ffe0b2;
    class Portal portal;
    class CP1,CP2 cp;
    class W1,W2,W3,W4 worker;
    linkStyle 0,1 stroke:#64b5f6,stroke-width:2px;
    linkStyle 2,3,4,5 stroke:#66bb6a,stroke-width:2px;

Multi-Region Shoots

The platform operates in two Swiss regions:

When you create a shoot, you choose which region the worker nodes run in. The control plane always runs on the Seed cluster, regardless of the worker region. You can create shoots in both regions — for example, a production cluster in Zurich and a disaster-recovery cluster in Geneva.

API Endpoint

Each shoot cluster gets a unique API endpoint following this pattern:

https://api.<cluster-name>.<project>.gardener.ewcs.ch

This endpoint is publicly reachable and is what kubectl connects to. It is backed by the control plane running on the Seed.

Control Plane vs Data Plane

Benefits

• No control plane management — we handle etcd backups, API server updates, and controller health.
• Multi-region — deploy shoots in Zurich, Geneva, or both.
• Automatic updates — upgrade Kubernetes versions with a click in the portal.
• HA for production — production-purpose shoots get a highly available control plane.
• OpenStack integration — worker nodes use OpenStack Cinder for persistent storage, Octavia for load balancers, and Neutron for networking.
• Resource efficiency — the seed-and-shoot model means control planes are lightweight and don't require dedicated master nodes per cluster.

Next step

Now that you understand the architecture, learn how to create and manage clusters or how LoadBalancer services integrate with Octavia.