Mikil tiltækileiki í Kubernetes tryggir að klasinn þinn haldist starfhæfur jafnvel við bilun. Þessi handbók útskýrir hvernig á að hanna og setja upp villuþolinn Kubernetes klasa, þar sem fjallað er um nauðsynlega íhluti, afritunaraðferðir og stillingarskref.

Helstu veitingar:

• Af hverju mikil aðgengi skiptir máliKoma í veg fyrir niðurtíma vegna bilana í vélbúnaði, netvandamála eða viðhalds.
• Kjarnaáætlanir:
  • Notið marga stjórnunarplanshnúta til að útrýma einstökum bilunarpunktum.
  • Dreifðu starfsmannahnútum yfir svæði eða landsvæði til að auka seiglu.
  • Innleiða álagsjafnari til að stjórna umferð og tryggja greiðar yfirfærslur.
• Mikilvægir þættir:
  • API-þjónn, etcd gagnagrunnur, tímaáætlunarstjóri og stjórnendur þurfa afritun.
  • Veldu á milli staflaðra eða ytri etcd-gröftunarkerfa byggt á flækjustigi og umfangi uppsetningarinnar.
• Skref í dreifingu:
  • Notaðu kubeadm til að setja upp klasa.
  • Stilla álagsjafnara, heilsufarsathuganir og vinnuhnútar.
  • Prófaðu reglulega yfirfærslur og afritunarferla.

Mikil tiltækileiki krefst vandlegrar skipulagningar, trausts innviða og stöðugra prófana til að tryggja stöðuga afköst og spenntíma.

[ Kube 1.5 ] Setja upp Kubernetes klasa með mikilli aðgengileika skref fyrir skref | Keepalived og Haproxy

Að skipuleggja Kubernetes klasa með mikilli tiltækileika

Þegar þú býrð til Kubernetes klasa með mikilli tiltækileika (HA) er mikilvægt að samræma hönnunina við skýr viðskipta- og tæknileg markmið. Án ígrundaðrar skipulagningar gætirðu endað með kerfi sem er annað hvort of flókið eða of brothætt til að uppfylla tiltækileikaþarfir þínar. Hér að neðan munum við skoða helstu atriði og ákvarðanir varðandi arkitektúr til að hjálpa þér að finna rétta jafnvægið.

Mat á viðskipta- og tæknilegum kröfum

Byrjaðu á að skilgreina þol þitt gagnvart niðurtíma og gagnatapi. Þessir þættir munu móta allar tæknilegar ákvarðanir sem þú tekur fyrir klasa þinn.

• Endurheimtartímamarkmið (RTO)Þetta mælir hversu hratt kerfin þín þurfa að jafna sig eftir bilun. Til dæmis, ef fyrirtæki þitt krefst þess að kerfi séu starfhæf innan 5 mínútna, þá þarftu sjálfvirk ferli fyrir bilun og fyrirfram stilltar biðtímaauðlindir. Hins vegar, ef lengri batatími er ásættanlegur, gætirðu valið einfaldari og hagkvæmari lausnir sem fela í sér handvirka íhlutun.
• Recovery Point Objective (RPO)Þetta ákvarðar hversu mikið gagnatap er ásættanlegt. Til dæmis gæti fjármálaviðskiptavettvangur krafist alls gagnataps, sem gæti leitt til samstilltrar gagnaafritunar. Á sama tíma gæti netverslunarvettvangur þola lítið gagnagall til að draga úr flækjustigi kerfisins.

Þú þarft einnig að skilgreina markmið þitt um tiltækileika. Til viðmiðunar:

• 99.9% spenntur leyfir um 8,77 klukkustundir af niðurtíma árlega.
• 99.99% spenntur minnkar það niður í um það bil 52,6 mínútur.

Að auki skaltu hafa umferðarmynstur forritsins þíns og þarfir þess að stækka það. Fyrirsjáanlegar umferðartoppa krefjast annarra aðferða samanborið við forrit sem upplifa skyndilegar, ófyrirsjáanlegar aukningar. Auðlindafrekt vinnuálag getur kallað á sérhæfða hnútahópa með sérsniðnum vélbúnaðaruppsetningum, sem mun hafa áhrif á hvernig þú dreifir vinnuálagi milli svæða.

Þessir mælikvarðar mynda grunninn að klasaarkitektúrnum þínum og vega og meta tæknilega skilvirkni og kröfur fyrirtækisins. Næsta skref er að ákvarða hvernig landfræðileg dreifing hefur áhrif á hönnunina.

Að velja svæðisbundna vs. svæðisbundna arkitektúr

Dreifing klasa landfræðilega skiptir miklu máli fyrir seiglu hans. Bæði svæðisbundin og svæðabundin arkitektúr býður upp á mismunandi kosti eftir þörfum.

• SvæðisarkitektúrÞetta kerfi dreifir auðlindum yfir mörg tiltækileikasvæði innan sama svæðis. Þau vernda gegn bilunum í einstökum gagnaverum en viðhalda jafnframt lágri seinkun milli íhluta. Þessi uppsetning hentar vel til að takast á við staðbundin vandamál eins og rafmagnsleysi eða netbilun innan tiltekins svæðis.
• Svæðisbundin byggingarlistÞetta dreifir auðlindum yfir mörg landfræðileg svæði og býður upp á vörn gegn stórfelldum hamförum eins og náttúruhamförum eða svæðisbundnum nettruflunum. Hins vegar hefur þessi aðferð oft í för með sér meiri seinkun, sem getur haft áhrif á afköst íhluta eins og etcd og almenna svörun klasa.

Svæðisbundnar dreifingar virka best fyrir forrit með alþjóðlega notendagrunna eða þegar reglugerðir krefjast þess að gögn séu geymd í tilteknum löndum. Þær eru einnig tilvaldar fyrir fyrirtæki sem þurfa strangar kröfur um bata eftir hamfarir.

Fyrir flestar HA uppsetningar, a fjölsvæðis stjórnunarplan býður upp á jafnvægisaðferð. Með því að setja stjórnunarplanshnúta yfir þrjú tiltækileikasvæði innan eins svæðis er tryggt að etcd geti viðhaldið tiltækum kerfum jafnvel þótt eitt svæði bili. Þessi aðferð býður upp á bilunarþol án þess að hafa áhyggjur af töfum sem fylgja samskiptum milli svæða.

Vinnuhnútar geta fylgt svipuðum dreifingarmynstrum, en sveigjanleikinn er meiri hér. Ríkislaus forrit geta keyrt á hvaða hnút sem er, en ríkjandi vinnuálag getur þurft vandlega staðsetningu til að tryggja að gögn séu aðgengileg og afköst séu stöðug.

Netkerfi og kröfur um afritun

Öflug netkerfisstefna er lykillinn að því að styðja bæði norður-suður umferð (viðskiptavinur til klasa) og austur-vestur umferð (samskipti milli klasaþátta). Óumbeðin um afritun á mörgum lögum er óumflýjanleg.

• Notaðu margfeldi álagsjafnara með /heilsa eftirlit dreift yfir svæði. Hver álagsjafnari ætti að geta tekist á við allt umferðarálagið til að útrýma einstökum bilunarpunktum.
• Tryggja fjölbreytni netleiða til að verjast vandamálum með tengingu. Umferð milli svæða ætti að hafa margar líkamlegar leiðir og þinn skýjaveitandi eða gagnaver verður að bjóða upp á afritunarnetkerfi.
• Fyrir DNS og þjónustuleit, setjið upp marga DNS-þjóna með viðeigandi TTL-stillingum fyrir klasaendapunkta. Þó að DNS-byggð álagsjöfnun bæti við afritun, skal hafa í huga að skyndiminni DNS á biðlarahlið getur tafið greiningu á yfirfærslu.

Þegar unnið er með viðvarandi magn, tryggja að geymsla sé aðgengileg við bilun í svæðum. Þetta gæti falið í sér afritun milli svæða eða dreifð geymslukerfi. Einnig skal skipuleggja nægilega netbandvídd til að meðhöndla gagnasamstillingu við endurheimtartilvik, sérstaklega fyrir stór gagnasöfn.

Ef þú ert að íhuga Innviðir Serverion, alþjóðlegar gagnaverstöðvar þeirra bjóða upp á sterkan stuðning fyrir bæði svæðisbundna og svæðisbundna arkitektúr. VPS og sérþjónavalkostir þeirra veita traustan grunn fyrir reikniafl fyrir klasahnúta þína, en samnýtingarþjónusta þeirra gerir kleift að nota blönduð kerfi sem sameina sveigjanleika skýsins við stjórn á uppsetningum á staðnum. Auk þess er afritunarnetkerfi þeirra smíðað til að takast á við tengikröfur klasa með mikilli tiltækileika, sem tryggir að Kubernetes-uppsetningin þín haldist endingargóð og áreiðanleg.

Kjarnaþættir og uppbygging fyrir mikla tiltækileika

Að búa til Kubernetes klasa með mikla aðgengileika þýðir að skilja nauðsynlega þætti sem halda kerfinu þínu gangandi og ákveða hvernig á að raða þeim. Þessar ákvarðanir hafa bein áhrif á áreiðanleika, afköst og flækjustig klasans.

Lykilþættir Kubernetes fyrir HA

Stjórnunarplanið er burðarás Kubernetes klasans þíns. Það inniheldur API-þjónn, tímaáætlun, stjórnendur stjórnenda, og o.s.frv., sem öll gegna mikilvægu hlutverki í að viðhalda rekstri.

• API-þjónnAPI-þjónninn er miðlæga miðstöðin sem vinnur úr beiðnum frá kubectl, vinnuhnútar og aðrir innri íhlutir. Að keyra marga API-þjóna á milli svæða tryggir að tap á einum þjóni raski ekki klasanum.
• TímaáætlunarstjóriÁætlunarstjórinn úthlutar hnútum hylki út frá tiltækum auðlindum og skilgreindum takmörkunum. Þó að þú getir sett upp marga áætlanastjóra fyrir afritun, tekur aðeins einn virkan ákvarðanir í einu. Ef virki áætlanastjórinn bilar, grípur annar til aðgerða.
• Stjórnendur eftirlitsaðilaÞessir kerfi fylgjast stöðugt með stöðu klasans og tryggja að auðlindir séu í samræmi við æskilega stillingu. Þeir nota leiðtogaval, þannig að aðeins eitt tilvik stýrir auðlindum virkt, á meðan afrit eru tilbúin til að taka við ef þörf krefur.
• o.s.frv.Þessi dreifða lykil-gildisgeymsla geymir stillingargögn, leyndarmál og stöðuupplýsingar. Hún notar samstöðualgrím sem krefst meirihluta hnúta (quorum) til að virka. Til dæmis getur þriggja hnúta etcd klasi tekist á við að missa einn hnút án þess að missa virkni.
• KúbeletKubelet-ið keyrir á hverjum vinnuhnút og hefur samskipti við API-þjóninn til að taka við upplýsingum um pod-ið og tilkynna stöðu hnúta. Þó að kubelet-ið sjálft sé ekki klasað til að hámarka tiltækileika, þá tryggir það að hafa marga vinnuhnúta að vinnuálag haldi áfram jafnvel þótt einhverjir hnútar bili.

Þegar þú hefur skilið þessa þætti er næsta skref að velja þá topology sem hentar þínum þörfum best.

HA-upprunafræði: Staflað vs. Ytri o.s.frv.

Þegar þú skipuleggur íhluti stjórnplans eru tveir meginvalkostir í boði, hvor með sínum eigin málamiðlunum hvað varðar áreiðanleika og flækjustig.

• Staflað etcd TopologyHér eru etcd tilvik staðsett samhliða stjórnunarplansþáttum á sömu hnútum. Þessi uppsetning er einfaldari í uppsetningu og krefst færri netþjóna. Hins vegar hefur hún í för með sér áhættu: ef stjórnunarplans hnútur bilar, tapast bæði stjórnunarplansþjónustan og etcd meðlimur.
• Ytri etcd TopologyÍ þessari aðferð keyrir etcd á sérstökum hnútum sem eru aðskildir frá stjórnunarplaninu. Þessi aðskilnaður veitir betri einangrun og gerir kleift að stækka auðlindir óháð hverfandi stigstærð, sem gerir það að góðum valkosti fyrir stærri eða krefjandi umhverfi.

Eiginleiki	Staflað o.s.frv.	Ytri o.s.frv.
Uppsetningarflækjustig	Auðveldara að dreifa og stjórna	Krefst fleiri hnúta og stjórnunar
Auðlindaeinangrun	Sameiginlegar auðlindir með stjórnunarplani	Sérstök úrræði fyrir etcd
Áhrif bilunar	Bæði etcd og stjórnunarplan hafa áhrif	Bilunum stjórnað sjálfstætt
Stærð	Takmarkað af sameiginlegum auðlindum	Óháð stigstærð möguleg

Fyrir minni uppsetningar býður staflað grannfræði upp á einfaldari upphafspunkt með nægilegri afritun. Hins vegar geta stærri klasar eða þeir sem þurfa strangar spenntímakröfur notið góðs af aukinni seiglu utanaðkomandi etcd uppsetningar.

Þegar þú hefur valið grannfræðina er næsta skref að stilla álagsjafnara til að tryggja greiðan rekstur.

Stillingar álagsjafnara

Álagsjafnarar gegna lykilhlutverki við að dreifa API-beiðnum yfir marga API-þjóna og stjórna yfirfærslum þegar netþjónar bila. Án slíks þyrftu viðskiptavinir að rekja einstaka API-endapunkta, sem flækir ferlið.

Rétt stilltur álagsjöfnunarbúnaður ætti að:

• Framkvæma heilsufarsskoðanir á /heilsa Endapunktur hvers API-þjóns. HTTP 200 svar gefur til kynna tilbúning, en HTTP 500 svar gefur til kynna vandamál. Ástandsskoðanir ættu að keyra á 10–15 sekúndna fresti með 5 sekúndna biðtíma til að tryggja skjóta greiningu vandamála.
• Dreifðu beiðnum jafnt, þar sem Kubernetes API-þjónar eru ástandslausir. Tengsl við lotur eru yfirleitt ekki nauðsynleg, sem gerir umferð kleift að flæða greiðlega jafnvel við bilun á þjónum.
• Meðhöndla SSL-lokun. Þú getur aflétt TLS-vinnslu við álagsjöfnunina til að draga úr vinnuálagi API-þjónanna eða sent dulkóðaða umferð í gegn fyrir dulkóðun frá enda til enda ef samræmi krefst þess.

Til að auka umframmagn, setjið upp marga álagsjöfnunaraðila á mismunandi svæði. DNS-byggð álagsjöfnun getur veitt annað lag af failover, en hafið í huga að DNS skyndiminni getur valdið töfum við umskipti.

Ef þú notar innviði Serverion, þá er þeirra hollur netþjóna veita öfluga afköst í stjórnunarplani, en VPS valkostir eru tilvaldir fyrir minni uppsetningar. Með gagnaver um allan heim styður Serverion fjölsvæða stillingar og býður upp á verkfæri til að stjórna umferðardreifingu á skilvirkan hátt, jafnvel við krefjandi netaðstæður.

sbb-itb-59e1987

Leiðbeiningar skref fyrir skref: Að setja upp HA Kubernetes með kubeadm

Nú þegar þú ert kunnugur íhlutunum og kerfisuppsetningunum er kominn tími til að byggja upp Kubernetes klasa með mikilli aðgengileika. Við munum nota kubeadm í þessari handbók – það einfaldar uppsetninguna en leyfir þér samt að stjórna stillingunum.

Uppsetning innviða og forkröfur

Byrjaðu á að undirbúa innviði þína til að takast á við framleiðsluálag.

Þú þarft að minnsta kosti þrjá stjórnunarhnúta (lágmark: 2 örgjörvakjarna og 4 GB vinnsluminni; mælt er með: 4 kjarnar og 8 GB vinnsluminni) og tvo eða fleiri vinnuhnúta (lágmark: 1 kjarni og 2 GB vinnsluminni). Settu upp studda Linux dreifingu, eins og Ubuntu 20.04/22.04, CentOS 8 eða Rocky Linux 9, á alla hnúta. Gakktu úr skugga um að hver hnútur hafi einstakt hýsingarheiti og geti átt samskipti við aðra í gegnum netið.

Slökkva á skipti á öllum hnútum þar sem Kubernetes styður það ekki. Keyra sudo skipti -a og útskýrðu allar skiptifærslur í /etc/fstab Til að gera breytinguna varanlega. Opnaðu nauðsynleg tengi: 6443 (API-þjónn), 2379-2380 (etcd), 10250 (kubelet) og 10251-10252 (tímaáætlunargerð/stýringarstjóri).

Setja upp keyrslutími gáms á hverjum hnút. Flestir notendur kjósa containerd, sem er vel stutt. Stilltu það til að nota systemd sem cgroup-rekla til að samræma það við sjálfgefnar stillingar Kubernetes. Settu síðan upp kubeadm, kubelet og kubectl á alla hnúta og vertu viss um að þeir keyri allir sömu Kubernetes útgáfuna til að forðast samhæfingarvandamál.

Settu upp álagsjafnari áður en klasinn er frumstilltur. Álagsjöfnunarkerfið getur verið vélbúnaðarbundið, hluti af þjónustuframboði skýjafyrirtækis eða hugbúnaðarlausn eins og HAProxy. Það ætti að hlusta á tengi 6443 og áframsenda umferð til API-þjóna á stjórnunarplanshnútum þínum.

Til að fá alþjóðlega bilunarþolna uppsetningu skaltu íhuga að nota sérstaka netþjóna fyrir stjórnunarplanshnúta og VPS tilvik fyrir vinnuhnúta.

Uppsetning stjórnunarplanshnúta

Fyrsti hnúturinn á stjórnunarplaninu er grunnurinn að klasanum þínum. Í stað þess að nota skipanalínumerki skaltu búa til kubeadm stillingarskrá til að skilgreina HA stillingar þínar.

Búðu til skrá sem heitir kubeadm-stillingar.yaml og innihalda klasastillingar þínar. Stilltu stjórnunarplansendapunktur á heimilisfang og tengi álagsjöfnunarbúnaðarins. Fyrir staflaða etcd-toppfræði mun kubeadm stilla etcd sjálfkrafa á hnúta stjórnunarplansins. Ef þú ert að nota utanaðkomandi etcd skaltu tilgreina endapunktana í þessari skrá.

Frumstillið fyrsta stjórnunarplanshnútinn með eftirfarandi skipun:
sudo kubeadm init --stillingar=kubeadm-stillingar.yaml --upphleðsluvottorð
The --upphleðsluvottorð „flag“ einfaldar ferlið við að dreifa vottorðum til annarra hnúta í stjórnunarplani. Þetta skref tekur nokkrar mínútur og mun senda frá sér skipanir um að bæta við fleiri hnútum.

Geymið þessar sameiningarskipanir á öruggan hátt – þær innihalda viðkvæm tákn. Næst skal stilla kubectl á fyrsta stjórnunarplanshnútnum:
mkdir -p $HOME/.kube && sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config

Áður en fleiri hnútum er bætt við skaltu setja upp CNI viðbót sem hentar umhverfi þínu.

Notið skipunina „join“ úr upphafsúttakinu til að bæta við eftirstandandi hnútum stjórnunarplansins:
sudo kubeadm join load-balancer-ip:6443 --token --uppgötvunar-tákn-ca-cert-kjöllu sha256: --stjórnarplan --vottorðslykill
Keyrðu þessa skipun á hverjum viðbótar stjórnunarplanshnúti.

Staðfestið að allir hnútar í stýrifleti séu virkir með því að keyra:
kubectl fá hnúta
Þú ættir að sjá alla hnúta skráða með stöðuna „Tilbúinn“.

Að stilla etcd og álagsjafnara

Fínstilltu stillingar fyrir etcd og álagsjafnari til að ljúka HA uppsetningunni.

Ef þú ert að nota staflaða etcd-toppfræði, þá stillir kubeadm hana sjálfkrafa. Fyrir utanaðkomandi etcd-klasa þarftu að setja upp etcd á sérstökum hnútum, búa til örugg samskiptavottorð og stilla hvert etcd-meðlim til að þekkja hina. Notaðu alltaf oddatölu af etcd-meðlimum (t.d. 3, 5 eða 7) til að viðhalda lögmætum fjölda við bilanir.

Athugaðu heilsu etcd með því að keyra:
sudo kubectl exec -n kube-system etcd- -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endapunktheilsa
Allir endapunktar ættu að vera skráðir sem heilbrigðir.

Fyrir álagsjafnara, stilltu heilsufarsathuganir til að fylgjast með /heilsa endapunktur á porti 6443 á hverjum API-þjóni. Stilltu tímabilið á 10 sekúndur með 5 sekúndna biðtíma og tryggðu að óheilbrigðir þjónar séu sjálfkrafa fjarlægðir og bættir við aftur þegar þeir ná sér á strik.

Til að prófa álagsjöfnunarkerfið, stöðvaðu API-þjóninn á einum hnút í stjórnunarplani (sudo systemctl stöðva kubelet) og staðfestu að kubectl skipanirnar virki enn. Endurræstu þjónustuna og vertu viss um að hnúturinn tengist klasanum aftur.

Ef þú notar marga álagsjöfnunaraðila skaltu stilla þá í virkri og óvirkri uppsetningu eða nota DNS-hringrás fyrir upphaflega álagsdreifingu. Skráðu verklagsreglur um failover til að leiðbeina teyminu þínu við að takast á við vandamál með álagsjöfnun.

Bæta við vinnuhnútum og prófa heilbrigði klasa

Vinnuhnútar eru burðarás klasans þíns og veita forritunum þínum reikniafl. Það er einfalt að bæta þeim við, en prófanir tryggja að klasinn sé seigur.

Notið skipunina „worker node join“ sem gefin var upp við upphaflega uppsetningu kubeadm:
sudo kubeadm join load-balancer-ip:6443 --token --uppgötvunar-tákn-ca-cert-kjöllu sha256:
Ef táknið er útrunnið geturðu búið til nýtt.

Gakktu úr skugga um að tenging vinnuhnútanna hafi tengst með því að keyra:
kubectl fá hnúta
Allir hnútar ættu að sýna stöðuna „Tilbúinn“. Ef hnútur er enn í „Ekki tilbúinn“ skal skoða kubelet-skrárnar með:
sudo journalctl -u kublett -f

Settu upp prufuforrit til að staðfesta heilbrigði klasans. Til dæmis, búðu til nginx dreifingu með mörgum eftirlíkingum:
kubectl búa til dreifingu nginx-próf --mynd=nginx --afrit=5
Athugaðu síðan dreifingu pods yfir hnúta:
kubectl fá hylki -o breitt

Herma eftir bilunum til að prófa virkni HA. Fyrir hnúta í stjórnunarplani, stöðvaðu kubelet þjónustuna á einum hnút og staðfestu að kubectl skipanirnar virki enn. Ef þú ert með fleiri en þrjá hnúta í stjórnunarplani, reyndu að stöðva tvo hnúta samtímis - klasinn ætti að vera virkur svo lengi sem meirihluti hnúta er heilbrigður.

Fyrir vinnuhnúta, hermið eftir bilun með því að girða af og tæma hnúta:
kubectl-strengur && kubectl frárennsli --ignore-daemonsets --delete-tómarmöppur-gögn
Fylgist með þegar Kubernetes endurraðar hylki á aðra hnúta.

Fylgstu með íhlutum klasans með:
kubectl fá stöðu íhluta og kubectl fá fræbelgur -n kube-kerfi
Öll kerfishylki ættu að vera í gangi og íhlutir ættu að vera skráðir sem heilbrigðir. Til að fylgjast með ávallt skal nota verkfæri eins og Prometheus til að fylgjast með mælingum með tímanum.

Ekki gleyma að setja upp afrit af etcd og vottorðumPrófið reglulega afritunar- og endurheimtarferla í óframleiðsluumhverfi til að tryggja að þeir séu skilvirkir.

Þegar Kubernetes klasinn þinn er með mikla aðgengileika er hann starfhæfur og prófaður og þú ert tilbúinn/in til að styðja við samfelldan rekstur og framkvæma reglubundið viðhald af öryggi.

Bestu starfsvenjur fyrir HA Kubernetes rekstur

Að setja upp Kubernetes klasa með mikla aðgengileika er aðeins fyrsta skrefið. Til að halda honum gangandi á skilvirkan og áreiðanlegan hátt þarftu að einbeita þér að stöðugu eftirliti, prófunum og bestu starfsvenjum í rekstri. Þessi skref munu hjálpa þér að viðhalda afköstum, forðast niðurtíma og tryggja að klasinn þinn haldist seigur.

Eftirlit og viðhald

Árangursrík vöktun er grunnurinn að mikilli tiltækileika (HA). Notið verkfæri eins og Prómeþeifs og Grafana til að fylgjast með lykilmælingum eins og örgjörvanotkun, minnisnotkun, netseinkun og afköstum etcd. Fylgstu vel með heilsu etcd með því að eftirlitsmælikvarðar eins og leiðtogakosningar, tillögur sem mistakast og seinkun á diska-I/O. Setjið upp viðvaranir fyrir mikilvæg þröskulda - til dæmis ef örgjörvanotkun fer yfir 80% á mörgum hnútum eða ef seinkun á etcd fer yfir 100ms, þarf að grípa til tafarlausra aðgerða. Notið reglulega staða endapunkts etcdctl skipun til að tryggja að allir etcd meðlimir séu samstilltir og virki rétt.

Haltu Kubernetes íhlutunum þínum uppfærðum með skipulögðu áætlun. Skipuleggðu ársfjórðungslegar uppfærslur fyrir minniháttar útgáfur og settu þær í framkvæmd. öryggisuppfærslur um leið og þær eru tiltækar. Prófið alltaf uppfærslur í vinnsluumhverfi áður en þær eru settar í framleiðslu. Þegar uppfært er skal meðhöndla etcd og Kubernetes sérstaklega til að lágmarka áhættu – uppfærið aldrei bæði á sama tíma.

Stjórnun vottorða er annað mikilvægt svið. Kubernetes vottorð renna venjulega út eftir eitt ár, sem gerir sjálfvirka endurnýjun nauðsynlega. Notið verkfæri eins og kubeadm eða vottunarstjóri að meðhöndla endurnýjanir og fylgjast náið með gildistíma. Prófið endurnýjunarferla mánaðarlega til að forðast óvænta niðurtíma af völdum útruninna vottorða.

Miðlægðu skráningarsöfnun með verkfærum eins og Fljótandi eða Fljótandi bitiÞetta auðveldar að tengja saman atburði milli hnúta og íhluta við viðbrögð við atvikum. Með því að innleiða þessar eftirlits- og viðhaldsaðferðir muntu greina hugsanleg vandamál snemma og hjálpa til við að tryggja tiltækileika klasans þíns.

Prófun á verklagsreglum fyrir yfirfærslu og afritun

Eftirlit eitt og sér er ekki nóg – þú þarft einnig að prófa yfirfærslu- og afritunarferla þína vandlega. Framkvæmdu mánaðarlegar bilunarprófanir til að líkja eftir raunverulegum bilunum. Til dæmis skaltu slökkva á stjórnunarhnútum, búa til netsneiðingar eða ofhlaða vinnuhnútum til að sjá hvernig kerfið þitt bregst við. Fylgstu með endurheimtartíma fyrir hvert atburðarás og vinndu að því að stytta hann.

Prófið reglulega afritunar- og endurheimtarferla fyrir etcd til að tryggja gagnaheilindi. Framkvæmið þessar prófanir í sérstöku umhverfi til að staðfesta nákvæmni og mæla endurheimtartímann. Ef endurheimtarferlið fer yfir endurheimtartímamarkmiðið (RTO) skaltu íhuga hraðari geymslulausnir eða hagræða ferlum. Sjálfvirknivæðið afrit af etcd á sex tíma fresti og geymið þau á dreifðum stöðum til að auka öryggi.

Prófun á yfirfærslum á forritastigi er jafn mikilvæg. Notið verkfæri eins og Kaos api eða Lakkmús að loka fyrir handahófskennda notkun á hylki eða hnútum á opnunartíma. Þetta hjálpar til við að bera kennsl á hvort forritin þín geti tekist á við bilanir án þess að hafa áhrif á notendur.

Búið til ítarlegar keyrslubækur fyrir algeng bilunartilvik. Þessar bækur ættu að innihalda skref-fyrir-skref leiðbeiningar um endurheimt, tengiliði fyrir stigvaxandi aðstæður og ákvarðanatré fyrir mismunandi gerðir atvika. Uppfærið þessi skjöl eftir hvert atvik og prófið þau með ýmsum teymismeðlimum til að tryggja skýrleika og notagildi.

Staðfesting á afritunarafritum nær lengra en bara að búa til afrit. Endurheimtið reglulega stöðu klasa í einangruðum umhverfum og staðfestið að forrit virki eins og búist er við. Prófið fulla endurheimt klasa sem og einstakar endurheimtir nafnrýma til að undirbúa sig fyrir fjölbreyttar hamfarir.

Hönnun forrita fyrir HA

Til þess að forrit dafni í HA umhverfi þarf að hanna þau með tiltækileika í huga. Fjárhagsáætlanir vegna truflana á raforkuframleiðslu (PDB) hjálpa til við að tryggja að lágmarksfjöldi afrita sé tiltækur meðan á viðhaldi eða uppskalun stendur. Fyrir mikilvæga þjónustu, stilltu mínAðgengilegt við ákveðinn fjölda afrita frekar en prósentu.

Notið reglur gegn skyldleika til að koma í veg fyrir staka bilunarpunkta. podAntiAffinity, þú getur dreift afritum yfir mismunandi hnúta eða tiltækileikasvæði. Fyrir stöðubundin forrit eins og gagnagrunna, sameinaðu mót-skyldleika við takmarkanir á dreifingu grannfræðinnar til að dreifa vinnuálagi jafnt.

Stilltu beiðnir og takmarkanir um auðlindir út frá raunverulegum notkunargögnum. Þetta tryggir að Kubernetes tímaáætlunin geti tekið betri ákvarðanir um staðsetningu og komið í veg fyrir árekstra í auðlindum. Farðu yfir og leiðréttu þessi gildi ársfjórðungslega út frá eftirlitsgögnum þínum.

Heilsufarsathuganir gegna lykilhlutverki í að viðhalda tilbúnum forritum. Notið virkniprófanir til að greina óvirk ferli og tilbúningsprófanir til að stjórna umferðarleiðsögn. Fínstillið tímamörk til að finna jafnvægi – of árásargjarnar stillingar geta valdið óþarfa endurræsingum, en vægar stillingar geta leyft biluðum hylkjum að halda áfram að fá umferð.

Þegar mögulegt er, hannaðu forrit þannig að þau séu ástandslaus. Geymdu lotugögn í ytri kerfum eins og Redis eða gagnagrunna í stað þess að nota í minni. Þetta gerir hylki kleift að endurræsa eða stækka án þess að hafa áhrif á notendalotur. Fyrir forrit sem krefjast stöðu, notaðu StatefulSets með varanlegum geymslum og tryggðu að gögn séu afrituð á milli svæða. Þessar aðferðir, ásamt seiglu innviðum, hjálpa til við að tryggja að forritin þín séu áfram tiltæk.

Notar ServerionInnviðir fyrir HA Kubernetes

Alþjóðlegt gagnavernet Serverion einfaldar landfræðilega dreifingu, sem er lykilþáttur í mikilli tiltækileika. Dreifið stjórnunarhnútum yfir mörg svæði til að ná raunverulegri afritun. Sérstakir netþjónar þeirra veita stöðuga afköst sem þarf fyrir etcd klasa, en VPS tilvik bjóða upp á hagkvæma stigstærð fyrir vinnuhnúta.

Sérstakir netþjónar frá Serverion eru tilvaldir fyrir stjórnunarhnúta því þeir útrýma „hávaðasömum nágranna“-áhrifum og tryggja fyrirsjáanlega afköst. Fyrir fyrirtæki með kröfur um reglufylgni eða núverandi fjárfestingar í vélbúnaði, gerir samnýtingarþjónusta Serverion kleift að nota blendingaarkitektúr. Þessi uppsetning gerir þér kleift að sameina innviði á staðnum við gagnaver þeirra, studd af tengingum með mikilli bandbreidd fyrir rauntíma gagnaafritun og óaðfinnanlega yfirfærslu.

Fjölmargar staðsetningar gagnavera Serverion gera einnig endurheimt eftir hamfarir öflugri. Settu upp biðklasa á mismunandi svæðum og notaðu verkfæri eins og Velero fyrir afrit á forritastigi sem hægt er að endurheimta á milli klasa. DNS-hýsingarþjónusta þeirra gerir kleift að framkvæma sjálfvirka yfirfærslu með því að uppfæra DNS-færslur þegar aðalsíða fer án nettengingar.

Að auki býður Serverion upp á vernd á innviðastigi og SSL vottunarþjónusta til að tryggja bæði ytri og innri umferð. Þjónusta þeirra sem stjórna netþjónum sér um eftirlit með vélbúnaði, uppfærslur á stýrikerfum og grunnöryggisverkefni, sem gerir teyminu þínu kleift að einbeita sér að Kubernetes-sértækum rekstri. Þessi samsetning eiginleika veitir sterkan grunn að viðhaldi HA Kubernetes-klasa.

Niðurstaða

Sérhver hönnunarvalkostur og rekstrarskref stuðlar að því að skapa áreiðanlegt Kubernetes-klasa. Að byggja upp Kubernetes-uppsetningu með mikilli aðgengileika krefst ígrundaðrar skipulagningar, traustra framkvæmdar og stöðugs viðhalds til að viðhalda bæði seiglu og afköstum hennar.

Að velja rétta kerfislýsingu og setja upp áreiðanlegan álagsjöfnunarbúnað tryggir ótruflaðan aðgang að API. Fyrir margar stofnanir nær staflað stjórnunarplan líkan góðu jafnvægi milli einfaldleika og áreiðanleika. Tól eins og kubeadm auðvelda uppsetningu og hjálpa til við að stjórna vottorðum á skilvirkan hátt.

Rekstrarleg velgengni veltur á fyrirbyggjandi eftirliti, reglulegum æfingum á yfirfærslum og hönnun forrita með eiginleikum eins og fjárhagsáætlunum fyrir truflanir á hleðslutækjum og reglum gegn skyldleika. Þessar ráðstafanir hjálpa vinnuálagi að haldast stöðugt við vandamál í innviðum og tryggja áreiðanlega afköst.

Alþjóðleg innviði Serverion bætir enn einu lagi áreiðanleika við þessa stefnu. Með því að bjóða upp á landfræðilega fjölbreytni og sterka möguleika á að endurheimta gögn eftir hamfarir, ásamt sérstökum netþjónum, hjálpa þeir til við að viðhalda stöðugri afköstum stjórnunarplans í mörgum gagnaverum.

Algengar spurningar

Hver er munurinn á stacked og external etcd uppsetningum í Kubernetes, og hvernig vel ég þá bestu fyrir klasa minn?

Lykilmunurinn á milli staflað og ytri o.s.frv. Stillingarnar felast í því hvar etcd gagnagrunnurinn starfar og hvernig honum er stjórnað. Í staflaðri uppsetningu keyrir etcd á sömu hnútum og stjórnunarfletirnir í Kubernetes. Þessi aðferð er auðveldari í framkvæmd og ódýrari, en hún hefur í för með sér málamiðlun: bilun í hnúti getur haft áhrif á bæði stjórnunarfletinn og etcd, sem gæti valdið verulegum truflunum.

Aftur á móti setur ytri etcd-gerð etcd á aðskildar, sérstakar vélar. Þessi aðferð eykur seiglu og afköst, sérstaklega fyrir stærri eða framleiðsluþyrpingar. Hins vegar felur hún einnig í sér meiri flækjustig hvað varðar stillingar og viðhald.

Fyrir minni eða minna mikilvæg Kubernetes umhverfi uppfyllir staflað uppsetning venjulega þarfirnar. En þegar kemur að stórum eða tiltækum framleiðsluklösum er utanaðkomandi etcd ákjósanlegur kostur til að viðhalda áreiðanleika og stöðugleika.

Hverjar eru bestu starfsvenjur til að fylgjast með og viðhalda mjög tiltækum Kubernetes klasa til að ná markmiðum um spenntíma?

Til að halda Kubernetes klasanum þínum gangandi og uppfylla væntingar um spenntíma þarftu að fylgjast með þremur mikilvægum lögum: innviðir, pallur, og forritVerkfæri eins og Prometheus geta hjálpað þér að fylgjast með mikilvægum mælikvörðum, en Grafana auðveldar að sjá gögnin fyrir þér. Fylgstu vel með mælikvörðum eins og örgjörvanotkun, minnisnotkun, endurræsingum á hlaðborðum og villutíðni. Með því að setja upp viðvaranir geturðu fljótt komið auga á og leyst öll vandamál áður en þau stigmagnast.

Þegar þú setur upp klasa skaltu fylgja bestu starfsvenjum. Virkja hlutverkatengd aðgangsstýring (RBAC) til að stjórna heimildum á skilvirkan hátt, skipuleggja auðlindir í nafnrými fyrir betri uppbyggingu og setja upp marga stjórnunarhnúta með álagsjöfnun til að auka bilanaþol. Regluleg uppfærsla í nýjustu Kubernetes útgáfuna og skipulagning fyrirbyggjandi viðhalds er jafn mikilvæg. Þessar ráðstafanir draga ekki aðeins úr niðurtíma heldur tryggja einnig að klasinn þinn geti stækkað til að mæta viðskiptaþörfum þínum.

Hvernig get ég hannað forritin mín fyrir mikla tiltækileika í Kubernetes klasa?

Til að halda forritunum þínum gangandi vel í Kubernetes klasa skaltu byrja á að setja upp margar eftirlíkingar forritsins þíns í gegnum Kubernetes Deployments. Þetta dreifir vinnuálaginu og tryggir að forritið þitt geti tekist á við bilanir í pod-um án truflana.

Annað gagnlegt tól er Fjárhagsáætlun fyrir truflun á hylkiÞessi eiginleiki hjálpar til við að viðhalda lágmarksfjölda virkra hylkja við uppfærslur eða viðhald, sem dregur úr niðurtíma. Fyrir enn meiri áreiðanleika skaltu dreifa klasanum þínum yfir... mörg svæði eða landsvæðiÞessi uppsetning verndar forritin þín gegn staðbundnum truflunum og eykur afritunargetu.

Með þessum aðferðum verður Kubernetes uppsetningin þín seigari og tryggir stöðuga afköst jafnvel þegar truflanir eiga sér stað.

Tengdar bloggfærslur

• Bilunarþolin geymsla fyrir streymigögn: Grunnatriði
• Gagnagrunnsbilunarprófun: Lykilskref
• NGINX Config fyrir DevOps: Bragð Serverion til að núllstilla dreifinguna
• Sjálfvirk stigstærð fyrir Kubernetes vinnuálag