Benvenuti nella serie di brevi guide su Kubernetes. Questa è una rubrica regolare con le domande più interessanti che riceviamo online e nei nostri corsi di formazione. Risponde un esperto di Kubernetes.
L'esperto di oggi è Daniel Polencic (). Daniel lavora come istruttore e sviluppatore software in .
Se desideri ricevere una risposta alla tua domanda nel prossimo post, oppure nel .
Hai perso i post precedenti? .
Come collegare cluster Kubernetes in diversi data center?
In sintesi: , e ti consiglio di leggere anche su e .
Spesso l'infrastruttura viene replicata e distribuita in diverse regioni, specialmente in ambienti controllati.
Se una regione non è disponibile, il traffico viene reindirizzato in un'altra per evitare interruzioni.
Con Kubernetes puoi utilizzare una strategia simile e distribuire i carichi di lavoro in diverse regioni.
Puoi avere uno o più cluster per team, regione, ambiente o una combinazione di questi elementi.
I tuoi cluster possono essere ospitati in diverse nuvole e in locale.
Ma come pianificare l'infrastruttura per una tale dispersione geografica?
Devi creare un grande cluster su diverse nuvole attraverso una rete unitaria?
O creare molti piccoli cluster e trovare un modo per controllarli e sincronizzarli?
Un cluster di gestione
Creare un cluster su una rete unitaria non è così semplice.
Immagina di avere un guasto, persa la connettività tra i segmenti del cluster.
Se hai un solo master server, metà delle risorse non sarà in grado di ricevere nuovi comandi, perché non riescono a contattare il master.
E in questo caso hai vecchie tabelle di routing (kube-proxy non può caricare nuove) e nessun pod aggiuntivo (kubelet non può richiedere aggiornamenti).
Cosa ancora peggiore, se Kubernetes non vede un nodo, lo contrassegna come perso e distribuisce i pod mancanti sui nodi esistenti.
Alla fine hai il doppio dei pod.
Se fai un master server per ogni regione, ci saranno problemi con l'algoritmo di consenso nel database etcd. (Nota del redattore — In realtà, il database etcd non deve necessariamente trovarsi sui server master. Può essere avviato su un gruppo separato di server in una regione. Tuttavia, ciò comporta un punto di guasto del cluster. Ma è veloce.)
etcd utilizza , per concordare un valore prima di scriverlo su disco.
Cioè, la maggior parte delle istanze deve raggiungere un consenso prima che lo stato possa essere scritto in etcd.
Se la latenza tra le istanze etcd aumenta drasticamente, come nel caso di tre istanze etcd in regioni diverse, ci vuole molto tempo per concordare il valore e scriverlo su disco.
Ciò si riflette anche nei controller di Kubernetes.
Il manager dei controller ha bisogno di più tempo per apprendere il cambiamento e registrare la risposta nel database.
E poiché ci sono più di un controller, si ottiene una reazione a catena, e l'intero cluster inizia a funzionare molto lentamente..
etcd è così sensibile alla latenza che .
Attualmente non esistono buoni esempi di una rete grande per un unico cluster.
In generale, la comunità degli sviluppatori e il gruppo SIG-cluster stanno cercando di capire come orchestrare i cluster così come Kubernetes orchestra i container.
Opzione 1: federazione di cluster con kubefed
La risposta ufficiale del SIG-cluster è — .
Per la prima volta, la gestione di una collezione di cluster come un'unica entità è stata tentata con lo strumento kube federation.
L'inizio era buono, ma alla fine kube federation non è diventato popolare, poiché non supportava tutte le risorse.
Supportava le distribuzioni aggregate e i servizi, ma, ad esempio, non i StatefulSets.
Inoltre, la configurazione della federazione veniva trasmessa sotto forma di annotazioni e mancava di flessibilità.
Immaginate come si potrebbe descrivere la suddivisione delle repliche per ciascun cluster nella federazione utilizzando solo annotazioni.
È diventato un completo disastro.
SIG-cluster ha fatto un grande lavoro dopo kubefed v1 e ha deciso di affrontare il problema da un'altra prospettiva.
Invece delle annotazioni, hanno deciso di rilasciare un controller che si installa sui cluster. Può essere configurato utilizzando definizioni di risorse personalizzate (Custom Resource Definition, CRD).
Per ogni risorsa che entrerà a far parte della federazione, hai una definizione CRD personalizzata suddivisa in tre sezioni:
- definizione standard della risorsa, come un deployment;
- con l'interruttore della pseudo-classe
placement, dove definisci come la risorsa sarà distribuita nella federazione; - con l'interruttore della pseudo-classe
override, dove per una risorsa specifica è possibile sovrascrivere il peso e i parametri dal placement.
Ecco un esempio di deployment combinato con le sezioni placement e override.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Come puoi vedere, il deployment è distribuito su due cluster: cluster1 e cluster2.
Il primo cluster fornisce tre repliche, mentre al secondo è stato assegnato il valore 5.
Se hai bisogno di maggior controllo sul numero di repliche, kubefed2 fornisce un nuovo oggetto ReplicaSchedulingPreference, dove le repliche possono essere distribuite in base al peso:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2La struttura del CRD e dell'API non è ancora del tutto pronta, e stiamo lavorando attivamente nel repository ufficiale del progetto.
Tieni d'occhio kubefed2, ma ricorda che al momento non è adatto per un ambiente di produzione.
Scopri di più su kubefed2 in nel blog su Kubernetes e nel .
Opzione 2: fusione di cluster in stile Booking.com
Gli sviluppatori di Booking.com non si sono occupati di kubefed v2, ma hanno inventato Shipper—un operatore per le consegne su più cluster, in più regioni e in più cloud.
Simile a kubefed2.
Entrambi gli strumenti consentono di configurare la strategia di distribuzione su più cluster (quali cluster utilizzare e quante repliche hanno).
Ma L'obiettivo di Shipper è ridurre il rischio di errori durante la distribuzione.
In Shipper puoi definire una serie di passaggi che descrivono la suddivisione delle repliche tra il deployment precedente e quello attuale e il volume del traffico in arrivo.
Quando invii una risorsa a un cluster, il controller Shipper distribuisce progressivamente questa modifica su tutti i cluster combinati.
Inoltre, Shipper è molto limitato.
Ad esempio, Accetta Helm charts come input e non supporta le risorse vanilla.
In linea generale, Shipper funziona nel seguente modo.
Invece della fornitura standard, è necessario creare una risorsa applicativa che includa un Helm chart:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper è una buona opzione per gestire più cluster, ma il suo stretto legame con Helm risulta solo un ostacolo.
E se tutti noi passassimo da Helm a o ?
Scopri di più su Shipper e sulla sua filosofia in .
Se vuoi dare un'occhiata al codice, .
Opzione 3: integrazione "magica" dei cluster
Kubefed v2 e Shipper lavorano con gli insiemi di cluster, fornendo nuovi risorse ai cluster tramite definizioni di risorse personalizzate.
Ma se non vuoi riscrivere tutte le forniture, StatefulSets, DaemonSets e così via per integrare?
Come includere un cluster esistente nella federazione senza modificare il YAML?
, che gestisce i carichi di lavoro di programmazione nei cluster.
Ma invece di inventare un nuovo modo di interagire con il cluster e avvolgere le risorse in definizioni personalizzate, multi-cluster-scheduler si integra nel ciclo di vita standard di Kubernetes e intercetta tutte le chiamate che creano pod.
Ogni pod creato viene immediatamente sostituito con un placeholder.
multi-cluster-scheduler utilizza , per intercettare la chiamata e creare un pod-vuoto inattivo.
Il pod originale passa attraverso un ulteriore ciclo di programmazione, dove, dopo aver interrogato tutta la federazione, viene presa una decisione sul posizionamento.
Infine, il pod viene fornito al cluster di destinazione.
Alla fine hai un pod extra, che non fa nulla, occupa solo spazio.
Il vantaggio è che non hai dovuto scrivere nuove risorse per integrare le forniture.
Ogni risorsa che crea un pod è automaticamente pronta per l'integrazione.
È interessante, poiché all'improvviso avete forniture distribuite in più regioni senza nemmeno accorgervene. Tuttavia, è piuttosto rischioso, perché tutto qui si basa su una sorta di magia.
Ma se il Shipper cerca principalmente di attenuare le conseguenze delle forniture, il multi-cluster-scheduler svolge compiti più generali e forse è più adatto per le attività batch.
Non ha un meccanismo avanzato per le forniture graduali.
Potete saperne di più sul multi-cluster-scheduler sulla .
Se volete leggere del multi-cluster-scheduler in azione, Admiralty ha un — processi di lavoro, eventi, CI e CD su Kubernetes.
Altri strumenti e soluzioni
Collegare diversi cluster e gestirli è un compito complesso, non esiste una soluzione universale.
Se desiderate approfondire questo argomento, ecco alcune risorse:
- — uno strumento che collega le overlay network di diversi cluster Kubernetes.
- La rete al dettaglio Target utilizza .
- Provate a utilizzare IPV6 e .
- Si può utilizzare un service mesh, ad esempio .
- Cilium, un plugin per le interfacce di rete dei container, offre , che consente di unire più cluster.
E questo è tutto per oggi.
Grazie per aver letto fino alla fine!
Se sapete come connettere più cluster in modo più efficiente, .
Aggiungeremo il vostro metodo ai link.
Un ringraziamento speciale a Chris Nesbitt-Smith () e Vincent De Smet () (ingegnere della resilienza in ) per aver letto l'articolo e condiviso informazioni utili su come funziona la federazione.
Fonte: habr.com
