Architecture Gardener

Notre service Kubernetes géré repose sur Gardener, une plateforme open source Kubernetes-as-a-Service qui nous permet d'exploiter des clusters Kubernetes à grande échelle. Cette page explique l'architecture afin que vous compreniez ce qui se passe en arrière-plan lorsque vous créez un cluster dans le Cloud Services Portal.

Qu'est-ce que Gardener ?

Gardener est un projet open source qui fournit des clusters Kubernetes en tant que service. Au lieu de gérer le plan de contrôle de chaque cluster individuellement sur des nœuds master dédiés, Gardener consolide les plans de contrôle sur un cluster de gestion partagé. Cela permet d'exploiter efficacement des dizaines de clusters avec des mises à jour, une surveillance et des sauvegardes centralisées.

Seed et Shoot

Gardener utilise deux concepts clés :

Fonctionnement

1. Vous créez un cluster dans le Cloud Services Portal.
2. Le portail appelle l'API Gardener sur le cluster Seed.
3. Gardener provisionne un plan de contrôle (serveur API, etcd, scheduler, controller-manager) pour votre shoot sous forme d'un ensemble de pods dans un namespace dédié sur le Seed.
4. Gardener provisionne les nœuds worker en tant que VM OpenStack dans la région que vous avez choisie.
5. Votre cluster shoot est prêt : vous vous connectez avec kubectl à l'aide du kubeconfig fourni par le portail.

L'essentiel à retenir : le plan de contrôle de votre cluster s'exécute sur le Seed, et non sur vos nœuds worker. Les nœuds worker n'exécutent que vos charges de travail (pods). Cette séparation est ce qui rend le service « géré » : nous prenons en charge les mises à jour du plan de contrôle, la HA et les sauvegardes etcd ; vous vous occupez de vos 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;

Shoots multi-régions

La plateforme opère dans deux régions suisses :

Lorsque vous créez un shoot, vous choisissez la région dans laquelle les nœuds worker s'exécutent. Le plan de contrôle s'exécute toujours sur le cluster Seed, quelle que soit la région des workers. Vous pouvez créer des shoots dans les deux régions, par exemple un cluster de production à Zurich et un cluster de reprise après sinistre à Genève.

Endpoint API

Chaque cluster shoot reçoit un endpoint API unique selon le schéma suivant :

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

Cet endpoint est accessible publiquement et c'est celui auquel kubectl se connecte. Il est pris en charge par le plan de contrôle exécuté sur le Seed.

Plan de contrôle et plan de données

Avantages

• Aucune gestion du plan de contrôle : nous gérons les sauvegardes etcd, les mises à jour du serveur API et l'état de santé des contrôleurs.
• Multi-régions : déployez des shoots à Zurich, Genève ou les deux.
• Mises à jour automatiques : mettez à niveau les versions de Kubernetes en un clic dans le portail.
• HA pour la production : les shoots de type production disposent d'un plan de contrôle hautement disponible.
• Intégration OpenStack : les nœuds worker utilisent OpenStack Cinder pour le stockage persistant, Octavia pour les load balancers et Neutron pour le réseau.
• Efficacité des ressources : le modèle seed-and-shoot signifie que les plans de contrôle sont légers et ne nécessitent pas de nœuds master dédiés par cluster.

Étape suivante

Maintenant que vous comprenez l'architecture, apprenez à créer et gérer des clusters ou comment les services LoadBalancer s'intègrent avec Octavia.