Benvenuti alla serie di brevi guide su Kubernetes. Questa è una rubrica regolare con le domande più interessanti che riceviamo online e durante i nostri corsi di formazione. Risponde un esperto di Kubernetes.
L'esperto di oggi è Daniele Polencic (). Daniele è un istruttore e sviluppatore software presso .
Se vuoi ricevere una risposta alla tua domanda nel prossimo post, o su .
Hai perso i post precedenti? .
Come collegare cluster Kubernetes in diversi data center?
In breve: , e ti consiglio di leggere anche su e .
Spesso l'infrastruttura è 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 è possibile utilizzare una strategia simile e distribuire i carichi di lavoro in diverse regioni.
Puoi avere uno o più cluster per team, regione, ambiente o per una combinazione di questi elementi.
I tuoi cluster possono essere ospitati in diverse nuvole e nell'ambiente locale.
Ma come pianificare l'infrastruttura per una tale distribuzione geografica?
È necessario creare un grande cluster su più ambienti cloud attraverso una rete unificata?
Oppure è meglio avere molti piccoli cluster e trovare un modo per controllarli e sincronizzarli?
Un cluster di gestione
Creare un cluster su una rete unificata non è così semplice.
Immaginate di avere un guasto, perdendo la connettività tra i segmenti del cluster.
Se avete un solo server master, metà delle risorse non potranno ricevere nuovi comandi, perché non riusciranno a contattare il master.
E nel frattempo avete tabelle di routing obsolete (kube-proxy non possono caricare nuove) e nessun pod aggiuntivo (kubelet non può richiedere aggiornamenti).
Cosa ancora peggio, se Kubernetes non vede un nodo, lo segna come perso e distribuisce i pod mancanti sugli altri nodi esistenti.
In questo modo avrete il doppio dei pod.
Se fate un server master per ogni regione, ci saranno problemi con l'algoritmo di consenso nel database etcd.Nota dell'editore — In effetti, il database etcd non deve necessariamente trovarsi sui server master. Può essere avviato su un gruppo separato di server in una stessa regione. Tuttavia, in questo modo si crea un punto di failure per il 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 aree geografiche diverse, ci vuole molto tempo per concordare il valore e scriverlo su disco.
Questo influisce anche sui controller Kubernetes.
Il gestore dei controller ha bisogno di più tempo per rilevare la modifica e scrivere la risposta nel database.
E dato che ci sono più controller, si genera 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 grande rete per un singolo cluster.
Fondamentalmente, 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 dei cluster con kubefed
Risposta ufficiale da SIG-cluster — .
La prima volta che si è provato a gestire una collezione di cluster come un unico oggetto è stato tramite lo strumento kube federation.
L'inizio è stato promettente, ma alla fine kube federation non è mai diventato popolare perché non supportava tutte le risorse.
Supportava le distribuzioni unificate e i servizi, ma, ad esempio, non gli StatefulSets.
Inoltre, la configurazione della federazione veniva fornita sotto forma di annotazioni ed era poco flessibile.
Immaginate come si possa descrivere la distribuzione delle repliche per ogni cluster nella federazione utilizzando solo annotazioni.
È venuto fuori un completo disastro.
SIG-cluster ha svolto un gran lavoro dopo kubefed v1 e ha deciso di affrontare il problema da un'altra angolazione.
Invece delle annotazioni, hanno deciso di rilasciare un controller che si installa sui cluster. Può essere configurato tramite Custom Resource Definitions (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'implementazione;
- sezione
placement, dove definisci come la risorsa sarà distribuita nella federazione; - sezione
override, dove è possibile sovrascrivere il peso e i parametri di placement per una risorsa specifica.
Ecco un esempio di implementazione combinata 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, l'implementazione è distribuita su due cluster: cluster1 e cluster2.
Il primo cluster fornisce tre repliche, mentre nel secondo è impostato il valore 5.
Se hai bisogno di maggiore controllo sul numero di repliche, kubefed2 offre 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 completamente pronta, e sono in corso lavori attivi nel repository ufficiale del progetto.
Seguite kubefed2, ma ricordate che per l'ambiente di produzione non è ancora adatto.
Scoprite di più su kubefed2 in nel blog di Kubernetes e in .
Opzione 2: unione dei cluster in stile Booking.com
Gli sviluppatori di Booking.com non si sono occupati di kubefed v2, ma hanno creato Shipper — un operatore per il deploy su più cluster, in più regioni e in più cloud.
è in qualche modo simile a kubefed2.
Entrambi gli strumenti permettono di configurare la strategia di distribuzione su più cluster (quali cluster vengono utilizzati e quante repliche hanno).
Ma l'obiettivo di Shipper è ridurre il rischio di errori durante la distribuzione.
In Shipper è possibile definire una serie di passaggi che descrivono la suddivisione delle repliche tra il deploy precedente e quello attuale e il volume del traffico in entrata.
Quando invii una risorsa al cluster, il controller Shipper distribuisce progressivamente questa modifica a tutti i cluster aggregati.
Inoltre, Shipper è molto limitato.
Ad esempio, accetta grafici Helm come input e non supporta risorse vanilla.
In generale, Shipper funziona nel seguente modo.
Invece di fornire normalmente, è necessario creare una risorsa dell'applicazione che includa il 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 gestire più cluster, ma la sua stretta integrazione con Helm è solo un ostacolo.
E se tutti noi passassimo da Helm a o ?
Scopri di più su Shipper e sulla sua filosofia in .
Se vuoi esplorare il codice, .
Opzione 3: unione "magica" dei cluster
Kubefed v2 e Shipper lavorano con la federazione dei cluster, fornendo ai cluster nuove risorse tramite definizioni di risorse personalizzate.
Ma se non vuoi riscrivere tutte le deployment, StatefulSet, DaemonSet, ecc. per unire?
Come includere un cluster esistente nella federazione senza modificare il YAML?
, che gestisce i carichi di lavoro di pianificazione nei cluster.
Ma invece di inventare un nuovo modo di interagire con il cluster e incapsulare 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 pod vuoto.
multi-cluster-scheduler utilizza , per intercettare la chiamata e creare un pod vuoto inattivo.
Il pod originale passa attraverso un ulteriore ciclo di pianificazione, dove dopo aver interrogato l'intera federazione si prende una decisione sulla ubicazione.
Infine, il pod viene consegnato al cluster di destinazione.
Risultato: hai un pod extra che non fa nulla, semplicemente occupa spazio.
Il vantaggio è che non è stato necessario scrivere nuove risorse per unire le forniture.
Ogni risorsa che crea un pod è automaticamente pronta per l'unione.
È interessante, poiché all'improvviso hai forniture distribuite in diverse regioni senza nemmeno accorgertene. Tuttavia, è piuttosto rischioso, poiché tutto si basa su magia.
Ma se Shipper cerca soprattutto di mitigare le conseguenze delle forniture, il multi-cluster-scheduler svolge compiti più generali e potrebbe essere più adatto per i job batch.
Non dispone di meccanismi avanzati per le forniture graduali.
Puoi saperne di più sul multi-cluster-scheduler nella .
Se desideri leggere del multi-cluster-scheduler in azione, Admiralty ha un — flussi di lavoro, eventi, CI e CD in Kubernetes.
Altri strumenti e soluzioni
Collegare e gestire più cluster è una sfida complessa e non esiste una soluzione universale.
Se desideri approfondire l'argomento, ecco alcune risorse:
- — uno strumento che collega overlay network tra diversi cluster Kubernetes.
- La rete retail Target utilizza .
- Prova a utilizzare IPV6 e .
- Puoi usare un service mesh, come ad esempio .
- Cilium, un plugin per l'interfaccia di rete dei container, offre , che permette di unire più cluster
Tutto per oggi
Grazie per aver letto fino alla fine!
Se conosci un modo più efficace per collegare più cluster, .
Aggiungeremo il tuo metodo ai link.
Un ringraziamento speciale a Chris Nesbitt-Smith () e Vincent De Smet () (ingegnere di affidabilità presso ) per aver letto l'articolo e condiviso informazioni utili su come funziona la federazione.
Fonte: habr.com
