Welkom bij de serie korte handleidingen over Kubernetes. Dit is een reguliere kolom met de meest interessante vragen die we online en tijdens onze trainingen ontvangen. Beantwoord door een Kubernetes-expert.
De expert van vandaag is Daniele Polencic (). Daniele werkt als instructeur en softwareontwikkelaar bij .
Als u een antwoord op uw vraag wilt krijgen in de volgende post, of naar .
Heeft u eerdere berichten gemist? .
Hoe verbindt u Kubernetes-clusters in verschillende datacentra?
Kort: , en ik raad ook aan om te lezen over en .
Infrastructuur wordt vaak gerepliceerd en verspreid over verschillende regio's, vooral in gecontroleerde omgevingen.
Als Ć©Ć©n regio niet beschikbaar is, wordt het verkeer omgeleid naar een andere om onderbrekingen te voorkomen.
Met Kubernetes kunt u een soortgelijke strategie gebruiken en werkbelasting over verschillende regio's verdelen.
U kunt Ć©Ć©n of meerdere clusters hebben per team, regio, omgeving of een combinatie van deze elementen.
Uw clusters kunnen worden gehost in verschillende clouds en op een lokale omgeving.
Maar hoe plant u de infrastructuur voor een dergelijke geografische spreiding?
Moet u ƩƩn grote cluster creƫren over meerdere clouds via een enkel netwerk?
Of meerdere kleine clusters maken en een manier vinden om deze te beheren en te synchroniseren?
EĆ©n leidende cluster
Een cluster over een enkel netwerk creƫren is niet zo eenvoudig.
Stel je voor dat er een storing optreedt, de connectiviteit tussen segmenten van de cluster is verloren gegaan.
Als u Ć©Ć©n masterserver heeft, kunnen de helft van de bronnen geen nieuwe opdrachten ontvangen, omdat ze geen contact kunnen opnemen met de master.
En ondertussen heeft u oude routetabellen (kube-proxy kan geen nieuwe laden) en geen extra pods (kubelet kan geen updates aanvragen).
Wat nog erger is, als Kubernetes een knooppunt niet ziet, markeert het het als verloren en verspreidt het de ontbrekende pods over de bestaande knooppunten.
U heeft uiteindelijk dubbel zoveel pods.
Als u voor elke regio een masterserver maakt, ontstaan er problemen met het consensusalgoritme in de etcd-database. (op. red. ā Eigenlijk hoeft de etcd-database niet per se op de masterservers te staan. Deze kan worden uitgevoerd op een aparte groep servers in dezelfde regio. Dit creĆ«ert echter wel een enkel punt van falen in de cluster. Maar het is snel.)
etcd gebruikt , om een waarde te bevestigen voordat deze op schijf wordt vastgelegd.
Dat wil zeggen dat de meeste instanties consensus moeten bereiken voordat de status in etcd kan worden vastgelegd.
Als de vertraging tussen de etcd-instanties plotseling toeneemt, zoals bij drie etcd-instanties in verschillende regio's, duurt het lang om een waarde te bevestigen en deze op schijf vast te leggen.
Dit heeft ook invloed op de Kubernetes-controllers.
De manager van de controllers heeft meer tijd nodig om op een wijziging te reageren en deze in de database vast te leggen.
En aangezien er niet Ć©Ć©n maar meerdere controllers zijn, ontstaat er een kettingreactie en begint de hele cluster erg langzaam te werken..
etcd is zo gevoelig voor vertraging dat .
Momenteel bestaan er geen goede voorbeelden van een groot netwerk voor Ć©Ć©n cluster.
Over het algemeen proberen de ontwikkelaarsgemeenschap en de SIG-clustergroep te begrijpen hoe clusters te orkestreren, net zoals Kubernetes containers orkestreert.
Optie 1: federatie van clusters met kubefed
Het officiƫle antwoord van SIG-cluster is .
Voor het eerst werd geprobeerd een verzameling clusters als Ć©Ć©n object te beheren met behulp van het hulpmiddel kube federation.
Het begin was goed, maar uiteindelijk werd kube federation niet populair, omdat het niet alle bronnen ondersteunde.
Het ondersteunde gecombineerde afleveringen en services, maar bijvoorbeeld geen StatefulSets.
Bovendien werd de configuratie van de federatie doorgegeven in de vorm van annotaties en had deze niet de noodzakelijke flexibiliteit.
Stel je voor hoe je de splitsing van replica's voor elke cluster in de federatie zou kunnen beschrijven met behulp van slechts enkele annotaties.
Het resulteerde in totale chaos.
SIG-cluster heeft veel werk verzet na kubefed v1 en besloot het probleem vanuit een andere hoek aan te pakken.
In plaats van annotaties besloten ze een controller uit te geven die op de clusters wordt geĆÆnstalleerd. Deze kan worden geconfigureerd met behulp van Custom Resource Definitions (CRD).
Voor elke resource die deel uitmaakt van de federatie, heeft u een aangepaste definitie CRD bestaande uit drie secties:
- een standaard resource-definitie, zoals een deployment;
- sectie
plaatsing, waar u definieert hoe de resource in de federatie wordt verdeeld; - sectie
override, waar voor een specifieke resource het gewicht en de parameters uit de plaatsing kunnen worden overschreven.
Hier is een voorbeeld van een gecombineerde levering met de secties plaatsing en 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: 5Zoals u ziet, is de levering verdeeld over twee clusters: cluster1 en cluster2.
De eerste cluster levert drie replicas, terwijl de tweede een waarde van 5 heeft.
Als u meer controle wilt over het aantal replicas, biedt kubefed2 een nieuw object ReplicaSchedulingPreference, waar replicas op gewicht kunnen worden verdeeld:
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: 2De structuur van de CRD en API is nog niet helemaal klaar, en er wordt actief aan gewerkt in de officiƫle projectrepository.
Houd kubefed2 in de gaten, maar onthoud dat het nog niet geschikt is voor productie-omgevingen.
Leer meer over kubefed2 uit in de Kubernetes-blog en in .
Optie 2: clusters samenvoegen in de stijl van Booking.com
De ontwikkelaars van Booking.com hebben zich niet beziggehouden met kubefed v2, maar hebben Shipper bedacht - een operator voor levering over meerdere clusters, in meerdere regio's en in meerdere clouds.
het lijkt een beetje op kubefed2.
Beide tools stellen u in staat om de implementatiestrategie over meerdere clusters in te stellen (welke clusters worden gebruikt en hoeveel replicas ze hebben).
Maar de taak van Shipper is om het risico op fouten bij de levering te verkleinen.
In Shipper kunt u een reeks stappen definiƫren die de verdeling van replicas tussen de vorige en de huidige deployment en de hoeveelheid binnenkomend verkeer beschrijven.
Wanneer u een resource naar een cluster verzendt, implementeert de Shipper-controller deze wijziging stap voor stap over alle samengevoegde clusters.
Bovendien is Shipper zeer beperkt.
Bijvoorbeeld, het accepteert Helm-charts als invoer. en ondersteunt geen vanilla-resources.
In het kort werkt Shipper als volgt.
In plaats van de standaardlevering moet je een applicatieresource maken, inclusief een 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 is een goede optie voor het beheren van meerdere clusters, maar de nauwe koppeling met Helm is alleen maar een hinder.
Wat als we allemaal overstappen van Helm naar of ?
Ontdek meer over Shipper en zijn filosofie in .
Als je in de code wilt duiken, .
Optie 3: 'magische' clustering van clusters
Kubefed v2 en Shipper werken met clusterfederaties, waarbij nieuwe resources aan clusters worden geleverd via gebruikersgedefinieerde resources.
Maar misschien wil je niet alle leveringen, StatefulSets, DaemonSets, enz. herschrijven voor de clustering?
Hoe een bestaand cluster in de federatie in te schakelen zonder YAML te wijzigen?
, dat zich bezighoudt met planningswerkbelasting in clusters.
Maar in plaats van een nieuwe manier te verzinnen om met de cluster te communiceren en resources in gebruikersdefinities te wikkelen, integreert multi-cluster-scheduler in de standaard levenscyclus van Kubernetes en onderschept alle aanroepen die pods aanmaken.
Elke aangemaakte pod wordt direct vervangen door een lege pod.
multi-cluster-scheduler gebruikt , om de aanroep te onderscheppen en een inactieve lege pod te creƫren.
De originele pod doorloopt nog een planningscyclus, waarin na raadpleging van de hele federatie een beslissing over de plaatsing wordt genomen.
Uiteindelijk wordt de pod geleverd aan het doelcluster.
Uiteindelijk heb je een extra pod die niets doet, gewoon ruimte in beslag neemt.
Het voordeel is dat je geen nieuwe resources hoefde te schrijven voor de clustering van leveringen.
Elke resource die een pod creƫert, is automatisch klaar voor clustering.
Dit is interessant, want je krijgt plotseling leveringen verdeeld over verschillende regio's, en je hebt het niet eens opgemerkt. Toch is dit behoorlijk riskant, want alles hier hangt af van magie.
Maar als Shipper probeert voornamelijk de gevolgen van leveringen te verzachten, dan voert de multi-cluster-scheduler meer algemene taken uit en is deze mogelijk beter geschikt voor batchopdrachten.
Hij heeft geen geavanceerd mechanisme voor geleidelijke leveringen.
Meer over de multi-cluster-scheduler kun je vinden op .
Als je wilt lezen over de multi-cluster-scheduler in actie, heeft Admiralty een ā workflows, gebeurtenissen, CI en CD van Kubernetes.
Andere tools en oplossingen
Het verbinden en beheren van meerdere clusters is een complexe taak, er bestaat geen universele oplossing.
Als je deze kwestie dieper wilt onderzoeken, hier zijn een paar middelen:
- ā een tool die overlay-netwerken van verschillende Kubernetes-clusters verbindt.
- Het retailnetwerk Target maakt gebruik van .
- Probeer IPV6 te gebruiken en .
- Je kunt een service mesh gebruiken, bijvoorbeeld .
- Cilium, een plug-in voor de containernetwerkinterface, biedt , die het mogelijk maakt om meerdere clusters te combineren.
Dat was het voor vandaag.
Bedankt dat je tot het einde hebt gelezen!
Als je weet hoe je meerdere clusters effectiever kunt verbinden, .
We zullen jouw methode toevoegen aan de links.
Speciale dank aan Chris Nesbitt-Smith () en Vincent De Smet () (reliability engineer bij ) voor het lezen van het artikel en het delen van nuttige informatie over hoe federatie werkt.
Bron: habr.com
