Bonvenon al nia serio Kubernetes Quick Start. Ĉi tio estas regula kolumno kun la plej interesaj demandoj, kiujn ni ricevas interrete kaj en niaj trejnadoj. Kubernetes spertaj respondoj.
La hodiaŭa fakulo estas Daniel Polenchik (). Daniel laboras kiel instruisto kaj programisto ĉe .
Se vi volas, ke via demando respondu en la sekva afiŝo, aŭ .
Ĉu vi perdis antaŭajn afiŝojn? .
Kiel konekti Kubernetes-grupojn en malsamaj datumcentroj?
Mallonge: , kaj mi ankaŭ rekomendas legi pri и .
Tre ofte, infrastrukturo estas reproduktita kaj distribuita tra malsamaj regionoj, precipe en kontrolitaj medioj.
Se unu regiono estas neatingebla, trafiko estas redirektita al alia por eviti interrompojn.
Kun Kubernetes, vi povas uzi similan strategion kaj distribui laborŝarĝojn tra malsamaj regionoj.
Vi povas havi unu aŭ plurajn aretojn per teamo, regiono, medio aŭ kombinaĵo de ĉi tiuj elementoj.
Viaj aretoj povas esti gastigitaj en malsamaj nuboj kaj surloke.
Sed kiel vi planas infrastrukturon por tia geografia disvastiĝo?
Ĉu vi bezonas krei unu grandan areton por pluraj nubaj medioj per ununura reto?
Aŭ havas multajn malgrandajn aretojn kaj trovi manieron kontroli kaj sinkronigi ilin?
Unu gvidantaro
Krei unu areton per ununura reto ne estas tiel facila.
Imagu, ke vi havas akcidenton, konektebleco inter aretsegmentoj estas perdita.
Se vi havas unu majstran servilon, duono de la rimedoj ne povos ricevi novajn komandojn ĉar ili ne povos kontakti la majstron.
Kaj samtempe vi havas malnovajn vojtabelojn (kube-proxy ne povas elŝuti novajn) kaj neniujn pliajn podojn (kubelet ne povas peti ĝisdatigojn).
Por plimalbonigi la aferojn, se Kubernetes ne vidas nodon, ĝi markas ĝin kiel orfa kaj distribuas la mankantajn podojn al ekzistantaj nodoj.
Kiel rezulto, vi havas duoble pli da balgoj.
Se vi faras unu majstran servilon por ĉiu regiono, estos problemoj kun la konsenta algoritmo en la datumbazo etcd. (ĉ. red. — Fakte, la datumbazo etcd ne nepre devas troviĝi sur la majstraj serviloj. Ĝi povas ruliĝi sur aparta grupo de serviloj en la sama regiono. Vere, samtempe ricevas punkton de fiasko de la grapolo. Sed rapide.)
etcd-uzoj por negoci la valoron antaŭ skribi ĝin al disko.
Tio estas, plimulto de kazoj devas atingi konsenton antaŭ ol la ŝtato povas esti skribita al ktpd.
Se la latenteco inter etcd-okazoj pliiĝas draste, kiel estas la kazo kun tri etcd-okazoj en malsamaj regionoj, necesas longa tempo por negoci valoron kaj skribi ĝin al disko.
Ĉi tio reflektas en Kubernetes-regiloj.
La regilo-manaĝero bezonas pli da tempo por lerni pri la ŝanĝo kaj skribi la respondon al la datumbazo.
Kaj ĉar ekzistas ne unu regilo, sed pluraj, rezultas ĉenreago kaj la tuta areto komencas labori tre malrapide.
etcd estas tiom latenteca ke .
Nuntempe ne ekzistas bonaj ekzemploj de granda reto por ununura areto.
Esence, la programista komunumo kaj la SIG-cluster-grupo provas eltrovi kiel reĝisori aretojn same kiel Kubernetes reĝisoras ujojn.
Opcio 1: clusterfederacio kun kubefed
Oficiala respondo de SIG-areto - .
Por la unua fojo, ni provis administri kolekton de aretoj kiel ununura objekto per la kube-federacia ilo.
La komenco estis bona, sed finfine kube federacio neniam populariĝis ĉar ĝi ne subtenis ĉiujn rimedojn.
Ĝi subtenis federaciajn liveraĵojn kaj servojn, sed ne StatefulSets, ekzemple.
Ankaŭ, la federacia agordo estis elsendita en formo de komentarioj kaj ne estis fleksebla.
Imagu kiel vi povus priskribi la kopipartigon por ĉiu areto en federacio uzante nur komentadojn.
Estis kompleta malordo.
SIG-cluster faris multe da laboro post kubefed v1 kaj decidis alproksimigi la problemon de malsama angulo.
Anstataŭ komentarioj, ili decidis liberigi regilon kiu estas instalita sur aretoj. Ĝi povas esti personecigita per Propraj Rimedaj Difinoj (CRDs).
Por ĉiu rimedo kiu estos parto de la federacio, vi havas kutiman CRD-difinon kun tri sekcioj:
- norma difino de rimedo, ekzemple deplojo;
- sekcio
placement, kie vi difinas kiel la rimedo estos distribuata en la federacio; - sekcio
override, kie por specifa rimedo vi povas superregi la pezon kaj parametrojn de lokigo.
Jen ekzemplo de kombinita livero kun lokado kaj anstataŭi sekcioj.
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: 5Kiel vi povas vidi, la provizo estas distribuita tra du aretoj: cluster1 и cluster2.
La unua areto provizas tri kopiojn, kaj la dua estas metita al 5.
Se vi bezonas pli da kontrolo pri la nombro da kopioj, kubefed2 disponigas novan ReplicaSchedulingPreference objekton kie kopioj povas esti pezbalancitaj:
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 CRD-strukturo kaj API ankoraŭ ne estas tute pretaj, kaj aktiva laboro estas en la oficiala projektdeponejo.
Rigardu kubefed2, sed memoru, ke ĝi ankoraŭ ne taŭgas por produktado.
Lernu pli pri kubefed2 de en la blogo pri Kubernetes kaj en .
Opcio 2: kombinante aretojn en Booking.com-stilo
La programistoj de Booking.com ne laboris pri kubefed v2, sed ili elpensis Shipper - funkciigisto por livero sur pluraj aretoj, en pluraj regionoj kaj en pluraj nuboj.
iom simila al kubefed2.
Ambaŭ iloj permesas al vi personecigi vian multi-aretan deplojan strategion (kiujn aretojn estas uzataj kaj kiom da kopioj ili havas).
sed La celo de Ekspedisto estas redukti la riskon de eraroj dum livero.
En Ekspedisto, vi povas difini serion da paŝoj, kiuj priskribas la dividon de kopioj inter la antaŭa kaj nuna disfaldiĝo kaj la volumo de envenanta trafiko.
Kiam vi puŝas rimedon al areto, la ekspedisto-regilo pligrandigas tiun ŝanĝon tra ĉiuj kunigitaj aretoj.
Ankaŭ, Ekspedisto estas tre limigita.
Ekzemple, ĝi akceptas stirleterojn kiel enigaĵon kaj ne subtenas vanilajn rimedojn.
Ĝenerale, Ekspedisto funkcias tiel.
Anstataŭ norma livero, vi devas krei aplikan rimedon, kiu inkluzivas Helm-diagramon:
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: 3Ekspedisto estas bona elekto por administri plurajn aretojn, sed ĝia proksima rilato kun Helm nur malhelpas.
Kio se ni ĉiuj ŝanĝus de Helm al aŭ ?
Eksciu pli pri Ekspedisto kaj ĝia filozofio ĉe .
Se vi volas fosi la kodon, .
Opcio 3: "magia" kunfandado
Kubefed v2 kaj Shipper laboras kun clusterfederacio, provizante novajn rimedojn al aretoj per kutima rimeda difino.
Sed kio se vi ne volas reverki ĉiujn liveraĵojn, StatefulSets, DaemonSets, ktp por kunfandi?
Kiel inkludi ekzistantan areton en federacio sen ŝanĝi YAML?
, kiu okupiĝas pri planado de laborkvantoj sur aretoj.
Sed anstataŭ elpensi novan manieron interagi kun la areto kaj envolvi rimedojn en kutimajn difinojn, plurgrupo-planilo estas enigita en la norma vivociklo de Kubernetes kaj kaptas ĉiujn vokojn kiuj kreas podojn.
Ĉiu kreita balgo estas tuj anstataŭigita per maniquí.
multi-cluster-scheduler uzoj por kapti la vokon kaj krei neaktivan imitan podaĵon.
La origina balgo trapasas alian planan ciklon kie, post balotado de la tuta federacio, allokigdecido estas farita.
Fine, la balgo estas liverita al la cela areto.
Kiel rezulto, vi havas kroman pod kiu faras nenion, nur okupas spacon.
La avantaĝo estas, ke vi ne devis skribi novajn rimedojn por kombini provizojn.
Ĉiu rimedo, kiu kreas balgon, estas aŭtomate preta por esti kunfandita.
Ĉi tio estas interesa, ĉar subite vi havas provizojn distribuitajn tra pluraj regionoj, kaj vi eĉ ne rimarkis. Tamen ĉi tio estas sufiĉe riska, ĉar ĉio ĉi tie baziĝas sur magio.
Sed dum Ekspedisto provas plejparte mildigi la efikon de liveraĵoj, plurgrupo-planilo pritraktas pli ĝeneralajn taskojn kaj eble pli taŭgas por grupaj laboroj.
Ĝi ne havas altnivelan laŭgradan liveran mekanismon.
Pli pri multi-cluster-scheduler troveblas ĉe .
Se vi volas legi pri multi-cluster-scheduler en ago, Admiralty havas — laborfluoj, eventoj, CI kaj KD Kubernetes.
Aliaj iloj kaj solvoj
Konekti kaj administri plurajn aretojn estas kompleksa tasko, kaj ne ekzistas universala solvo.
Se vi ŝatus esplori ĉi tiun temon plu, jen kelkaj rimedoj:
- estas ilo, kiu ligas superkovrajn retojn de malsamaj Kubernetes-aretoj.
- Podetala ĉeno Celuzoj .
- Provu uzi IPV6 kaj .
- Vi povas uzi servomaŝon, ekzemple .
- Cilium, ujo retinterfaco kromaĵo, proponas , kiu permesas vin kombini plurajn aretojn
Tio estas ĉio por hodiaŭ
Dankon pro legi ĝis la fino!
Se vi scias kiel konekti plurajn aretojn pli efike, .
Ni aldonos vian metodon al la ligiloj.
Specialan dankon al Chris Nesbitt-Smith () kaj Vincent de Sme () (fidindeĝeniero en ) por legi la artikolon kaj konigi utilajn informojn pri kiel funkcias la federacio.
fonto: www.habr.com