Gardener-Architektur

Unser Managed-Kubernetes-Service basiert auf Gardener — einer Open-Source-Kubernetes-as-a-Service-Plattform, die es uns ermöglicht, Kubernetes-Cluster im grossen Massstab zu betreiben. Diese Seite erklärt die Architektur, damit Sie verstehen, was hinter den Kulissen passiert, wenn Sie einen Cluster im Cloud Services Portal erstellen.

Was ist Gardener?

Gardener ist ein Open-Source-Projekt, das Kubernetes-Cluster als Service bereitstellt. Anstatt die Control Plane jedes Clusters einzeln auf dedizierten Master-Nodes zu verwalten, konsolidiert Gardener die Control Planes auf einem gemeinsamen Management-Cluster. Das macht es möglich, Dutzende von Clustern effizient mit zentralen Updates, Monitoring und Backups zu betreiben.

Seed und Shoot

Gardener verwendet zwei zentrale Konzepte:

Wie es funktioniert

1. Sie erstellen einen Cluster im Cloud Services Portal.
2. Das Portal ruft die Gardener-API auf dem Seed-Cluster auf.
3. Gardener stellt eine Control Plane (API-Server, etcd, Scheduler, Controller-Manager) für Ihren Shoot als Pods in einem dedizierten Namespace auf dem Seed bereit.
4. Gardener provisioniert Worker-Nodes als OpenStack-VMs in der von Ihnen gewählten Region.
5. Ihr Shoot-Cluster ist bereit — Sie verbinden sich mit kubectl über die Kubeconfig aus dem Portal.

Der entscheidende Punkt: Die Control Plane Ihres Clusters läuft auf dem Seed, nicht auf Ihren Worker-Nodes. Die Worker-Nodes führen nur Ihre Workloads (Pods) aus. Diese Trennung macht den Service "managed" — wir kümmern uns um Updates der Control Plane, HA und etcd-Backups; Sie kümmern sich um Ihre Anwendungen.

%%{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 · Zürich"]
        W1["Worker-Node"]
        W2["Worker-Node"]
    end

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

    Portal -->|"Gardener-API"| CP1
    Portal -->|"Gardener-API"| CP2
    CP1 -->|"verwaltet"| W1
    CP1 -->|"verwaltet"| W2
    CP2 -->|"verwaltet"| W3
    CP2 -->|"verwaltet"| 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 · Zürich"]
        W1["Worker-Node"]
        W2["Worker-Node"]
    end

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

    Portal -->|"Gardener-API"| CP1
    Portal -->|"Gardener-API"| CP2
    CP1 -->|"verwaltet"| W1
    CP1 -->|"verwaltet"| W2
    CP2 -->|"verwaltet"| W3
    CP2 -->|"verwaltet"| 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

Die Plattform betreibt zwei Schweizer Regionen:

Wenn Sie einen Shoot erstellen, wählen Sie, in welcher Region die Worker-Nodes laufen. Die Control Plane läuft immer auf dem Seed-Cluster, unabhängig von der Worker-Region. Sie können Shoots in beiden Regionen erstellen — zum Beispiel einen Produktionscluster in Zürich und einen Disaster-Recovery-Cluster in Genf.

API-Endpunkt

Jeder Shoot-Cluster erhält einen eindeutigen API-Endpunkt nach folgendem Muster:

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

Dieser Endpunkt ist öffentlich erreichbar und ist das Ziel, mit dem kubectl verbindet. Er wird von der Control Plane auf dem Seed bedient.

Control Plane vs Data Plane

Vorteile

• Keine Verwaltung der Control Plane — wir übernehmen etcd-Backups, API-Server-Updates und Controller-Gesundheit.
• Multi-Region — deployen Sie Shoots in Zürich, Genf oder beiden.
• Automatische Updates — upgraden Sie Kubernetes-Versionen mit einem Klick im Portal.
• HA für Produktion — Produktions-Shoots erhalten eine hoch verfügbare Control Plane.
• OpenStack-Integration — Worker-Nodes nutzen OpenStack Cinder für persistenten Storage, Octavia für Loadbalancer und Neutron für Netzwerke.
• Ressourceneffizienz — das Seed-and-Shoot-Modell bedeutet, dass Control Planes leichtgewichtig sind und keine dedizierten Master-Nodes pro Cluster benötigen.

Nächster Schritt

Jetzt, wo Sie die Architektur verstehen, lernen Sie, wie Sie Cluster erstellen und verwalten oder wie LoadBalancer-Services mit Octavia integrieren.