Welkom bij onze Kubernetes Quick Start-serie. Dit is een vaste column met de meest interessante vragen die wij online en in onze trainingen ontvangen. Antwoorden van Kubernetes-experts.
De expert van vandaag is Daniel Polenchik (). Daniel werkt als instructeur en softwareontwikkelaar bij .
Als je wilt dat je vraag beantwoord wordt in het volgende bericht, of .
Eerdere berichten gemist? .
Hoe Kubernetes-clusters in verschillende datacenters verbinden?
Kort: , en ik raad ook aan om hierover te lezen и .
Heel vaak wordt de infrastructuur gerepliceerd en gedistribueerd over verschillende regio's, vooral in gecontroleerde omgevingen.
Als een regio niet beschikbaar is, wordt het verkeer omgeleid naar een andere regio om onderbrekingen te voorkomen.
Met Kubernetes kunt u een vergelijkbare strategie gebruiken en de werklast over verschillende regio's verdelen.
Per team, regio, omgeving of een combinatie hiervan kun je één of meerdere clusters hebben.
Uw clusters kunnen worden gehost in verschillende clouds en on-premises.
Maar hoe plan je de infrastructuur voor een dergelijke geografische spreiding?
Moet u één groot cluster creëren voor meerdere cloudomgevingen over één netwerk?
Of heb je veel kleine clusters en vind je een manier om deze te controleren en te synchroniseren?
Eén leiderschapscluster
Het creëren van één cluster over één netwerk is niet zo eenvoudig.
Stel je voor dat je een ongeluk krijgt, waarbij de connectiviteit tussen clustersegmenten verloren gaat.
Als u één masterserver heeft, kan de helft van de bronnen geen nieuwe opdrachten ontvangen omdat ze geen contact kunnen opnemen met de master.
En tegelijkertijd heb je oude routeringstabellen (kube-proxy kan geen nieuwe downloaden) en geen extra pods (kubelet kan geen updates aanvragen).
Om het nog erger te maken: als Kubernetes een knooppunt niet ziet, markeert het dit als verweesd en distribueert het de ontbrekende pods naar bestaande knooppunten.
Het resultaat is dat je twee keer zoveel peulen hebt.
Als u voor elke regio één masterserver maakt, zullen er problemen zijn met het consensusalgoritme in de etcd-database. (ca. red. — In feite hoeft de etcd-database niet noodzakelijkerwijs op de masterservers te staan. Het kan worden uitgevoerd op een afzonderlijke groep servers in dezelfde regio. Het is waar dat tegelijkertijd een punt van falen van het cluster wordt verkregen. Maar snel.)
enz. gebruikt om over de waarde te onderhandelen voordat deze naar schijf wordt geschreven.
Dat wil zeggen dat een meerderheid van de instanties consensus moet bereiken voordat de staat naar etcd kan worden geschreven.
Als de latentie tussen etcd-instanties dramatisch toeneemt, zoals het geval is met drie etcd-instanties in verschillende regio's, duurt het lang om over een waarde te onderhandelen en deze naar schijf te schrijven.
Dit zie je terug in Kubernetes-controllers.
De controllermanager heeft meer tijd nodig om de wijziging te leren kennen en het antwoord naar de database te schrijven.
En aangezien er niet één controller is, maar meerdere, er ontstaat een kettingreactie en het hele cluster begint heel langzaam te werken.
etcd is zo latentiegevoelig dat .
Er zijn momenteel geen goede voorbeelden van een groot netwerk voor één cluster.
Kortom, de ontwikkelaarsgemeenschap en de SIG-clustergroep proberen erachter te komen hoe clusters op dezelfde manier kunnen worden georkestreerd als Kubernetes containers orkestreert.
Optie 1: clusterfederatie met kubefed
Officieel antwoord van SIG-cluster - .
Voor het eerst hebben we geprobeerd een verzameling clusters als één object te beheren met behulp van de Kube Federation-tool.
Het begin was goed, maar uiteindelijk werd de Kube-federatie nooit populair omdat ze niet alle middelen ondersteunde.
Het ondersteunde federatieve leveringen en diensten, maar bijvoorbeeld geen StatefulSets.
Bovendien werd de federatieconfiguratie verzonden in de vorm van annotaties en was deze niet flexibel.
Stel je voor hoe je de replicapartitionering voor elk cluster in een federatie zou kunnen beschrijven met alleen annotaties.
Het was een complete puinhoop.
SIG-cluster heeft veel werk verricht na kubefed v1 en besloot het probleem vanuit een andere hoek te benaderen.
In plaats van annotaties hebben ze besloten een controller uit te brengen die op clusters is geïnstalleerd. Het kan worden aangepast met behulp van Custom Resource Definitions (CRD's).
Voor elke resource die deel gaat uitmaken van de federatie beschikt u over een aangepaste CRD-definitie met drie secties:
- standaarddefinitie van een hulpbron, bijvoorbeeld inzet;
- sectie
placement, waar u definieert hoe de bron binnen de federatie wordt gedistribueerd; - sectie
override, waar u voor een specifieke resource het gewicht en de parameters van plaatsing kunt overschrijven.
Hier ziet u een voorbeeld van een gecombineerde levering met plaatsings- en override-secties.
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 het aanbod verdeeld over twee clusters: cluster1 и cluster2.
Het eerste cluster levert drie replica's en het tweede is ingesteld op vijf.
Als u meer controle over het aantal replica's nodig hebt, biedt kubefed2 een nieuw ReplicaSchedulingPreference-object waarmee replica's kunnen worden gewogen:
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 CRD-structuur en API zijn nog niet helemaal gereed en er wordt actief gewerkt aan de officiële projectrepository.
Houd kubefed2 in de gaten, maar bedenk dat deze nog niet geschikt is voor productie.
Lees meer over kubefed2 van in de blog over Kubernetes en in .
Optie 2: clusters combineren in Booking.com-stijl
De ontwikkelaars van Booking.com werkten niet aan kubefed v2, maar bedachten Shipper – een operator voor bezorging op meerdere clusters, in meerdere regio’s en in meerdere clouds.
enigszins vergelijkbaar met kubefed2.
Met beide hulpprogramma's kunt u uw implementatiestrategie voor meerdere clusters aanpassen (welke clusters worden gebruikt en hoeveel replica's ze hebben).
Maar Het doel van de verzender is om de kans op fouten tijdens de bezorging te verkleinen.
In Shipper kunt u een reeks stappen definiëren die de verdeling van replica's tussen de vorige en huidige implementatie en het volume van inkomend verkeer beschrijven.
Wanneer u een bron naar een cluster pusht, rolt de Shipper-controller die wijziging stapsgewijs uit over alle aangesloten clusters.
Ook is de verzender zeer beperkt.
Bijvoorbeeld het accepteert roerkaarten als invoer en ondersteunt geen vanillebronnen.
Over het algemeen werkt Shipper als volgt.
In plaats van standaardlevering moet u een toepassingsresource maken die een Helm-diagram bevat:
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 relatie met Helm staat dat alleen maar in de weg.
Wat als we allemaal overstappen van Helm naar of ?
Lees meer over Shipper en zijn filosofie op .
Als je in de code wilt duiken, .
Optie 3: “magische” clusterfusie
Kubefed v2 en Shipper werken met clusterfederatie en bieden nieuwe bronnen aan clusters via aangepaste resourcedefinitie.
Maar wat als u niet alle leveringen, StatefulSets, DaemonSets, etc. wilt herschrijven om samen te voegen?
Hoe kan ik een bestaand cluster in een federatie opnemen zonder YAML te wijzigen?
, dat zich bezighoudt met het plannen van werklasten op clusters.
Maar in plaats van een nieuwe manier te bedenken om met het cluster te communiceren en bronnen in aangepaste definities te verpakken, is de multi-cluster-scheduler ingebed in de standaard Kubernetes-levenscyclus en onderschept alle oproepen die pods creëren.
Elke gemaakte pod wordt onmiddellijk vervangen door een dummy.
multi-cluster-scheduler-gebruik om het gesprek te onderscheppen en een inactieve dummy-pod te maken.
De oorspronkelijke pod doorloopt nog een planningscyclus waarin, na ondervraging van de hele federatie, een plaatsingsbeslissing wordt genomen.
Ten slotte wordt de pod afgeleverd bij het doelcluster.
Het resultaat is dat je een extra pod hebt die niets doet, alleen maar ruimte in beslag neemt.
Het voordeel is dat je geen nieuwe bronnen hoefde te schrijven om voorraden te combineren.
Elke bron die een pod maakt, is automatisch klaar om te worden samengevoegd.
Dit is interessant, want opeens heb je voorraden verspreid over verschillende regio’s, zonder dat je het in de gaten hebt. Dit is echter behoorlijk riskant, omdat alles hier op magie berust.
Maar terwijl Shipper vooral de impact van leveringen probeert te verzachten, voert multi-clusterscheduler meer algemene taken uit en is misschien beter geschikt voor batchtaken.
Het beschikt niet over een geavanceerd mechanisme voor geleidelijke uitvoering.
Meer over multi-cluster-scheduler vindt u op .
Als je meer wilt lezen over multi-cluster-scheduler in actie, dan heb je dat bij Admiralty — workflows, evenementen, CI en CD Kubernetes.
Andere tools en oplossingen
Het verbinden en beheren van meerdere clusters is een complexe taak en er bestaat geen universele oplossing.
Als u dit onderwerp verder wilt onderzoeken, vindt u hier enkele bronnen:
- is een tool die overlay-netwerken van verschillende Kubernetes-clusters met elkaar verbindt.
- Winkelketen Doelgebruik .
- Probeer IPV6 en .
- U kunt bijvoorbeeld een servicemesh gebruiken .
- Cilium, een plug-in voor een containernetwerkinterface, biedt , waarmee u meerdere clusters kunt combineren
Dat is alles voor vandaag
Bedankt voor het lezen tot het einde!
Als je weet hoe je meerdere clusters efficiënter kunt verbinden, .
Wij voegen uw werkwijze toe aan de links.
Speciale dank aan Chris Nesbitt-Smith () en Vincent de Sme () (betrouwbaarheidsingenieur in ) voor het lezen van het artikel en het delen van nuttige informatie over hoe de federatie werkt.
Bron: www.habr.com