Bun venit la seria noastră Kubernetes Quick Start. Aceasta este o rubrică obișnuită cu cele mai interesante întrebări pe care le primim online și în cadrul cursurilor noastre. Răspunsurile experților Kubernetes.
Expertul de astăzi este Daniel Polenchik (). Daniel lucrează ca instructor și dezvoltator de software la .
Dacă doriți să răspundeți la întrebarea dvs. în următoarea postare, sau .
Ați ratat postările anterioare? .
Cum se conectează clustere Kubernetes în diferite centre de date?
scurt: și vă recomand să citiți despre и .
Destul de des, infrastructura este replicată și distribuită în diferite regiuni, în special în medii controlate.
Dacă o regiune nu este disponibilă, traficul este redirecționat către alta pentru a evita întreruperile.
Cu Kubernetes, puteți utiliza o strategie similară și puteți distribui sarcinile de lucru în diferite regiuni.
Puteți avea unul sau mai multe clustere per echipă, regiune, mediu sau o combinație a acestor elemente.
Clusterele dvs. pot fi găzduite în diferite cloud și local.
Dar cum planificați infrastructura pentru o astfel de răspândire geografică?
Trebuie să creați un cluster mare pentru mai multe medii cloud într-o singură rețea?
Sau aveți multe grupuri mici și găsiți o modalitate de a le controla și sincroniza?
Un singur grup de conducere
Crearea unui cluster într-o singură rețea nu este atât de ușoară.
Imaginați-vă că aveți un accident, conectivitatea între segmentele cluster este pierdută.
Dacă aveți un server master, jumătate din resurse nu vor putea primi comenzi noi, deoarece nu vor putea contacta masterul.
Și, în același timp, aveți tabele de rutare vechi (kube-proxy nu pot descărca altele noi) și fără poduri suplimentare (kubelet nu poate solicita actualizări).
Pentru a înrăutăți lucrurile, dacă Kubernetes nu vede un nod, îl marchează ca orfan și distribuie podurile lipsă nodurilor existente.
Drept urmare, aveți de două ori mai multe păstăi.
Dacă faceți un server master pentru fiecare regiune, vor exista probleme cu algoritmul de consens în baza de date etcd. (aproximativ ed. — De fapt, baza de date etcd nu trebuie neapărat să fie localizată pe serverele master. Poate fi rulat pe un grup separat de servere din aceeași regiune. Adevărat, în același timp obținerea unui punct de eșec al clusterului. Dar repede.)
utilizări etcd pentru a negocia valoarea înainte de a o scrie pe disc.
Adică, majoritatea cazurilor trebuie să ajungă la un consens înainte ca statul să poată fi scris la etcd.
Dacă latența dintre instanțele etcd crește dramatic, așa cum este cazul cu trei instanțe etcd din regiuni diferite, este nevoie de mult timp pentru a negocia o valoare și a o scrie pe disc.
Acest lucru se reflectă în controlerele Kubernetes.
Managerul controlorului are nevoie de mai mult timp pentru a afla despre schimbare și pentru a scrie răspunsul în baza de date.
Și din moment ce nu există un singur controler, ci mai multe, rezultă o reacție în lanț și întregul cluster începe să funcționeze foarte lent.
etcd este atât de sensibil la latență încât .
În prezent, nu există exemple bune de rețea mare pentru un singur cluster.
Practic, comunitatea de dezvoltatori și grupul SIG-cluster încearcă să descopere cum să orchestreze clusterele în același mod în care Kubernetes orchestrează containerele.
Opțiunea 1: federarea clusterului cu kubefed
Răspuns oficial de la SIG-cluster - .
Pentru prima dată, am încercat să gestionăm o colecție de clustere ca un singur obiect folosind instrumentul de federație kube.
Începutul a fost bun, dar până la urmă federația kube nu a devenit populară pentru că nu a susținut toate resursele.
A acceptat livrări și servicii federate, dar nu StatefulSets, de exemplu.
De asemenea, configurația federației a fost transmisă sub formă de adnotări și nu a fost flexibilă.
Imaginați-vă cum ați putea descrie partiționarea replica pentru fiecare cluster dintr-o federație folosind doar adnotări.
A fost o mizerie completă.
SIG-cluster a lucrat mult după kubefed v1 și a decis să abordeze problema dintr-un unghi diferit.
În loc de adnotări, au decis să lanseze un controler care este instalat pe clustere. Poate fi personalizat folosind definiții personalizate de resurse (CRD).
Pentru fiecare resursă care va face parte din federație, aveți o definiție CRD personalizată cu trei secțiuni:
- definiția standard a unei resurse, de exemplu implementarea;
- secțiune
placement, unde definiți cum va fi distribuită resursa în federație; - secțiune
override, unde pentru o anumită resursă puteți suprascrie greutatea și parametrii din plasare.
Iată un exemplu de livrare combinată cu secțiuni de plasare și înlocuire.
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: 5După cum puteți vedea, oferta este distribuită în două grupuri: cluster1 и cluster2.
Primul cluster furnizează trei replici, iar al doilea este setat la 5.
Dacă aveți nevoie de mai mult control asupra numărului de replici, kubefed2 oferă un nou obiect ReplicaSchedulingPreference unde replicile pot fi ponderate:
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: 2Structura CRD și API-ul nu sunt încă pregătite, iar lucrările active sunt în desfășurare în depozitul oficial al proiectului.
Fiți cu ochii pe kubefed2, dar amintiți-vă că nu este încă potrivit pentru producție.
Aflați mai multe despre kubefed2 de la în blogul despre Kubernetes și în .
Opțiunea 2: combinarea clusterelor în stilul Booking.com
Dezvoltatorii Booking.com nu au lucrat pe kubefed v2, dar au venit cu Shipper - un operator de livrare pe mai multe clustere, în mai multe regiuni și în mai multe nori.
oarecum asemănător cu kubefed2.
Ambele instrumente vă permit să vă personalizați strategia de implementare multi-cluster (ce clustere sunt utilizate și câte replici au).
Dar Scopul expeditorului este de a reduce riscul de erori în timpul livrării.
În Shipper, puteți defini o serie de pași care descriu împărțirea replicilor între implementarea anterioară și cea actuală și volumul de trafic de intrare.
Când împingeți o resursă într-un cluster, controlerul Shipper lansează treptat acea modificare în toate clusterele unite.
De asemenea, Expeditorul este foarte limitat.
De exemplu, acceptă diagrame de cârmă ca intrare și nu acceptă resurse de vanilie.
În termeni generali, Expeditorul funcționează așa.
În loc de livrare standard, trebuie să creați o resursă de aplicație care include o diagramă 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: 3Expeditorul este o opțiune bună pentru gestionarea mai multor clustere, dar relația sa strânsă cu Helm nu face decât să împiedice.
Dacă trecem cu toții de la Helm la sau ?
Aflați mai multe despre Shipper și filosofia sa la .
Dacă vrei să sapi în cod, .
Opțiunea 3: fuziunea clusterului „magic”.
Kubefed v2 și Shipper lucrează cu federarea clusterelor, oferind noi resurse clusterelor prin definirea personalizată a resurselor.
Dar dacă nu doriți să rescrieți toate livrările, StatefulSets, DaemonSets etc. pentru a fuziona?
Cum să includeți un cluster existent într-o federație fără a schimba YAML?
, care se ocupă cu programarea sarcinilor de lucru pe clustere.
Dar, în loc să vină cu o nouă modalitate de a interacționa cu clusterul și de a include resursele în definiții personalizate, planificatorul multi-cluster este încorporat în ciclul de viață standard Kubernetes și interceptează toate apelurile care creează pod-uri.
Fiecare pod creată este imediat înlocuită cu un manechin.
utilizări multi-cluster-scheduler pentru a intercepta apelul și a crea un pod inactiv.
Podul original trece printr-un alt ciclu de planificare în care, după sondarea întregii federații, se ia o decizie de plasare.
În cele din urmă, pod-ul este livrat clusterului țintă.
Drept urmare, aveți un pod suplimentar care nu face nimic, doar ocupă spațiu.
Avantajul este că nu a fost nevoie să scrii resurse noi pentru a combina proviziile.
Fiecare resursă care creează un pod este gata automat pentru a fi îmbinată.
Acest lucru este interesant, pentru că dintr-o dată ai provizii distribuite în mai multe regiuni și nici nu ai observat. Cu toate acestea, acest lucru este destul de riscant, deoarece totul aici se bazează pe magie.
Dar, în timp ce Expeditorul încearcă în mare parte să atenueze impactul livrărilor, planificatorul multi-cluster se ocupă de sarcini mai generale și este probabil mai potrivit pentru sarcinile pe lot.
Nu are un mecanism avansat de livrare graduală.
Mai multe despre multi-cluster-scheduler pot fi găsite la .
Dacă doriți să citiți despre multi-cluster-scheduler în acțiune, Amiralty are — fluxuri de lucru, evenimente, CI și CD Kubernetes.
Alte instrumente și soluții
Conectarea și gestionarea mai multor clustere este o sarcină complexă și nu există o soluție universală.
Dacă doriți să explorați acest subiect în continuare, iată câteva resurse:
- este un instrument care conectează rețele suprapuse ale diferitelor clustere Kubernetes.
- Lanțul de vânzare cu amănuntul Utilizări țintă .
- Încercați să utilizați IPV6 și .
- Puteți utiliza o plasă de serviciu, de exemplu .
- Cilium, un plugin de interfață de rețea de containere, oferă , care vă permite să combinați mai multe clustere
Asta e tot pentru azi
Mulțumesc că ai citit până la capăt!
Dacă știți cum să conectați mai multe clustere mai eficient, .
Vom adăuga metoda dvs. la linkuri.
Mulțumiri speciale lui Chris Nesbitt-Smith () și Vincent de Sme () (inginer de fiabilitate în ) pentru citirea articolului și împărtășirea informațiilor utile despre modul în care funcționează federația.
Sursa: www.habr.com