Architettura Gardener

Il nostro servizio Kubernetes gestito si basa su Gardener, una piattaforma open source Kubernetes-as-a-Service che ci consente di gestire cluster Kubernetes su larga scala. Questa pagina spiega l'architettura, così da comprendere cosa accade dietro le quinte quando si crea un cluster nel Cloud Services Portal.

Che cos'è Gardener?

Gardener è un progetto open source che fornisce cluster Kubernetes come servizio. Invece di gestire il piano di controllo di ogni singolo cluster su nodi master dedicati, Gardener consolida i piani di controllo su un cluster di gestione condiviso. Questo consente di gestire in modo efficiente decine di cluster con aggiornamenti, monitoraggio e backup centralizzati.

Seed e Shoot

Gardener utilizza due concetti chiave:

Come funziona

1. Crei un cluster nel Cloud Services Portal.
2. Il portale chiama l'API Gardener sul cluster Seed.
3. Gardener fornisce un piano di controllo (API server, etcd, scheduler, controller-manager) per il Suo shoot come insieme di pod in un namespace dedicato sul Seed.
4. Gardener fornisce i nodi worker come VM OpenStack nella regione selezionata.
5. Il Suo cluster shoot è pronto: si connette con kubectl utilizzando il kubeconfig fornito dal portale.

L'aspetto fondamentale: il piano di controllo del Suo cluster viene eseguito sul Seed, non sui Suoi nodi worker. I nodi worker eseguono solo i Suoi carichi di lavoro (pod). Questa separazione è ciò che rende il servizio "gestito": noi ci occupiamo degli aggiornamenti del piano di controllo, della HA e dei backup etcd; Lei si occupa delle Sue applicazioni.

%%{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;

Shoot multi-regione

La piattaforma opera in due regioni svizzere:

Quando crea uno shoot, sceglie la regione in cui vengono eseguiti i nodi worker. Il piano di controllo viene sempre eseguito sul cluster Seed, indipendentemente dalla regione dei worker. Può creare shoot in entrambe le regioni, ad esempio un cluster di produzione a Zurigo e un cluster di disaster recovery a Ginevra.

Endpoint API

Ogni cluster shoot riceve un endpoint API univoco secondo il seguente schema:

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

Questo endpoint è raggiungibile pubblicamente ed è quello a cui si connette kubectl. È supportato dal piano di controllo in esecuzione sul Seed.

Piano di controllo e piano dati

Vantaggi

• Nessuna gestione del piano di controllo: gestiamo i backup etcd, gli aggiornamenti dell'API server e lo stato di salute dei controller.
• Multi-regione: distribuire shoot a Zurigo, Ginevra o in entrambe.
• Aggiornamenti automatici: aggiornare le versioni di Kubernetes con un clic nel portale.
• HA per la produzione: gli shoot con scopo produzione ricevono un piano di controllo ad alta disponibilità.
• Integrazione OpenStack: i nodi worker utilizzano OpenStack Cinder per lo storage persistente, Octavia per i load balancer e Neutron per la rete.
• Efficienza delle risorse: il modello seed-and-shoot significa che i piani di controllo sono leggeri e non richiedono nodi master dedicati per ogni cluster.

Passo successivo

Ora che ha compreso l'architettura, scopra come creare e gestire i cluster o come i servizi LoadBalancer si integrano con Octavia.