Benvenuti nella nostra serie Kubernetes Quick Start. Questa è una rubrica regolare con le domande più interessanti che riceviamo online e durante i nostri corsi di formazione. Risposte degli esperti Kubernetes.
L'esperto di oggi è Daniel Polenchik (). Daniel lavora come istruttore e sviluppatore di software presso .
Se vuoi che la tua domanda riceva una risposta nel prossimo post, o .
Ti sei perso i post precedenti? .
Come connettere i cluster Kubernetes in diversi data center?
brevemente: , e consiglio anche di leggere и .
Molto spesso, l’infrastruttura viene replicata e distribuita in diverse regioni, soprattutto in ambienti controllati.
Se una regione non è disponibile, il traffico viene reindirizzato a 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 diversi cloud e on-premise.
Ma come si pianificano le infrastrutture per una tale diffusione geografica?
Hai bisogno di creare un cluster di grandi dimensioni per diversi ambienti cloud su un'unica rete?
Oppure hai molti piccoli cluster e trovi un modo per controllarli e sincronizzarli?
Un cluster di leadership
Creare un cluster su una singola rete non è così semplice.
Immagina di avere un incidente, la connettività tra i segmenti del cluster viene persa.
Se hai un server master, metà delle risorse non potranno ricevere nuovi comandi perché non potranno contattare il master.
E allo stesso tempo hai vecchie tabelle di routing (kube-proxy non è possibile scaricarne di nuovi) e nessun pod aggiuntivo (kubelet non può richiedere aggiornamenti).
A peggiorare le cose, se Kubernetes non vede un nodo, lo contrassegna come orfano e distribuisce i pod mancanti ai nodi esistenti.
Di conseguenza, hai il doppio dei pod.
Se crei un server master per ciascuna regione, si verificheranno problemi con l'algoritmo di consenso nel database etcd. (ca. ed. — Infatti, il database etcd non deve necessariamente trovarsi sui server master. Può essere eseguito su un gruppo separato di server nella stessa regione. È vero, ottenendo allo stesso tempo il punto di fallimento del cluster. Ma velocemente.)
eccd utilizza per negoziare il valore prima di scriverlo su disco.
Cioè, la maggioranza delle istanze deve raggiungere il consenso prima che lo stato possa essere scritto in etcd.
Se la latenza tra le istanze etcd aumenta notevolmente, come nel caso di tre istanze etcd in regioni diverse, è necessario molto tempo per negoziare un valore e scriverlo su disco.
Ciò si riflette nei controller Kubernetes.
Il gestore del controller ha bisogno di più tempo per conoscere la modifica e scrivere la risposta nel database.
E poiché non esiste un controller, ma diversi, Ne risulta una reazione a catena e l'intero cluster inizia a funzionare molto lentamente.
etcd è così sensibile alla latenza che .
Al momento non esistono buoni esempi di rete di grandi dimensioni per un singolo cluster.
Fondamentalmente, la comunità degli sviluppatori e il gruppo SIG-cluster stanno cercando di capire come orchestrare i cluster nello stesso modo in cui Kubernetes orchestra i contenitori.
Opzione 1: federazione del cluster con kubefed
Risposta ufficiale dal cluster SIG - .
Per la prima volta abbiamo provato a gestire una raccolta di cluster come un unico oggetto utilizzando lo strumento di federazione kube.
L'inizio è stato buono, ma alla fine la federazione kube non è mai diventata popolare perché non supportava tutte le risorse.
Supportava consegne e servizi federati, ma non StatefulSet, ad esempio.
Inoltre, la configurazione della federazione veniva trasmessa sotto forma di annotazioni e non era flessibile.
Immagina come potresti descrivere il partizionamento della replica per ciascun cluster in una federazione utilizzando solo annotazioni.
Era un disastro completo.
SIG-cluster ha lavorato molto dopo kubefed v1 e ha deciso di affrontare il problema da una prospettiva diversa.
Invece delle annotazioni, hanno deciso di rilasciare un controller installato sui cluster. Può essere personalizzato utilizzando le definizioni di risorse personalizzate (CRD).
Per ogni risorsa che farà parte della federazione, avrai una definizione CRD personalizzata con tre sezioni:
- definizione standard di una risorsa, ad esempio distribuzione;
- sezione
placement, dove definisci come verrà distribuita la risorsa nella federazione; - sezione
override, dove per una risorsa specifica è possibile sovrascrivere il peso e i parametri dal posizionamento.
Ecco un esempio di pubblicazione combinata con sezioni di posizionamento e sostituzione.
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, la fornitura è distribuita su due cluster: cluster1 и cluster2.
Il primo cluster fornisce tre repliche e il secondo è impostato su 5.
Se hai bisogno di un maggiore controllo sul numero di repliche, kubefed2 fornisce un nuovo oggetto ReplicaSchedulingPreference in cui è possibile pesare le repliche:
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 CRD e l'API non sono ancora del tutto pronte e è in corso un lavoro attivo nel repository ufficiale del progetto.
Tieni d'occhio kubefed2, ma ricorda che non è ancora adatto alla produzione.
Ulteriori informazioni su kubefed2 da nel blog su Kubernetes e in .
Opzione 2: combinare i cluster in stile Booking.com
Gli sviluppatori di Booking.com non hanno lavorato su kubefed v2, ma hanno inventato Shipper, un operatore per la consegna su diversi cluster, in diverse regioni e in diversi cloud.
in qualche modo simile a kubefed2.
Entrambi gli strumenti ti consentono di personalizzare la tua strategia di distribuzione multi-cluster (quali cluster vengono utilizzati e quante repliche hanno).
Ma L'obiettivo del mittente è ridurre il rischio di errori durante la consegna.
In Shipper è possibile definire una serie di passaggi che descrivono la divisione delle repliche tra la distribuzione precedente e quella corrente e il volume del traffico in entrata.
Quando si invia una risorsa a un cluster, il controller Shipper implementa in modo incrementale tale modifica su tutti i cluster uniti.
Inoltre, il mittente è molto limitato.
Per esempio, accetta le carte timone come input e non supporta le risorse Vanilla.
In termini generali, Shipper funziona in questo modo.
Invece della consegna standard, devi creare una risorsa dell'applicazione che includa un grafico Helm:
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 la gestione di più cluster, ma la sua stretta relazione con Helm è solo d'intralcio.
E se passassimo tutti da Helm a o ?
Scopri di più su Shipper e la sua filosofia su .
Se vuoi approfondire il codice, .
Opzione 3: fusione “magica” dei cluster
Kubefed v2 e Shipper funzionano con la federazione dei cluster, fornendo nuove risorse ai cluster attraverso la definizione di risorse personalizzate.
Ma cosa succede se non si desidera riscrivere tutte le consegne, StatefulSet, DaemonSet, ecc. per unirle?
Come includere un cluster esistente in una federazione senza modificare YAML?
, che si occupa della pianificazione dei carichi di lavoro sui cluster.
Ma invece di trovare un nuovo modo di interagire con il cluster e racchiudere le risorse in definizioni personalizzate, lo scheduler multi-cluster è incorporato nel ciclo di vita standard di Kubernetes e intercetta tutte le chiamate che creano pod.
Ogni pod creato viene immediatamente sostituito con un manichino.
usi dello scheduler multi-cluster per intercettare la chiamata e creare un pod fittizio inattivo.
Il pod originale passa attraverso un altro ciclo di pianificazione in cui, dopo aver interrogato l'intera federazione, viene presa una decisione sul posizionamento.
Infine, il pod viene consegnato al cluster di destinazione.
Di conseguenza, hai un pod extra che non fa nulla, occupa solo spazio.
Il vantaggio è che non è necessario scrivere nuove risorse per combinare le forniture.
Ogni risorsa che crea un pod è automaticamente pronta per essere unita.
Questo è interessante, perché all’improvviso hai forniture distribuite in diverse regioni e non te ne sei nemmeno accorto. Tuttavia, questo è piuttosto rischioso, perché qui tutto si basa sulla magia.
Ma mentre Shipper cerca di mitigare principalmente l'impatto delle consegne, lo scheduler multi-cluster gestisce attività più generali ed è forse più adatto per lavori batch.
Non dispone di un meccanismo avanzato di erogazione graduale.
Maggiori informazioni sullo scheduler multi-cluster possono essere trovate su .
Se vuoi leggere informazioni sullo scheduler multi-cluster in azione, Admiralty ha — flussi di lavoro, eventi, CI e CD Kubernetes.
Altri strumenti e soluzioni
Collegare e gestire più cluster è un compito complesso e non esiste una soluzione universale.
Se desideri approfondire questo argomento, ecco alcune risorse:
- è uno strumento che collega reti overlay di diversi cluster Kubernetes.
- Usi target della catena di vendita al dettaglio .
- Prova a utilizzare IPV6 e .
- Puoi utilizzare una rete di servizi, ad esempio .
- Cilium, un plugin per l'interfaccia di rete di contenitori, offre , che consente di combinare più cluster
È tutto per oggi
Grazie per aver letto fino alla fine!
Se sai come connettere più cluster in modo più efficiente, .
Aggiungeremo il tuo metodo ai collegamenti.
Un ringraziamento speciale a Chris Nesbitt-Smith () e Vincent de Smé () (ingegnere dell'affidabilità in ) per leggere l'articolo e condividere informazioni utili sul funzionamento della federazione.
Fonte: habr.com