Pavel Selivanov, Southbridge lausnaarkitekt og Slurm kennari, hélt kynningu á DevOpsConf 2019. Þetta erindi er hluti af einu af viðfangsefnum ítarlegs námskeiðs um Kubernetes „Slurm Mega“.
fer fram í Moskvu dagana 18. – 20. nóvember.
— Moskvu, 22.-24. nóvember.
alltaf til taks.
Fyrir neðan klippuna er afrit af skýrslunni.
Góðan daginn, félagar og þeir sem hafa samúð með þeim. Í dag mun ég tala um öryggi.
Ég sé að það eru margir öryggisverðir í salnum í dag. Ég bið þig fyrirfram afsökunar ef ég nota hugtök úr öryggisheiminum ekki nákvæmlega eins og tíðkast hjá þér.
Það gerðist svo að fyrir um sex mánuðum síðan rakst ég á einn opinberan Kubernetes þyrping. Opinber þýðir að það er n. fjöldi nafnarúma; í þessum nafnasvæðum eru notendur einangraðir í nafnarými þeirra. Allir þessir notendur tilheyra mismunandi fyrirtækjum. Jæja, það var gert ráð fyrir að nota ætti þennan klasa sem CDN. Það er að segja, þeir gefa þér þyrping, þeir gefa þér notanda þar, þú ferð þangað í nafnrýmið þitt, sendir fram vígstöðvarnar þínar.
Fyrra fyrirtæki mitt reyndi að selja slíka þjónustu. Og ég var beðinn um að pota í klasann til að sjá hvort þessi lausn hentaði eða ekki.
Ég kom í þennan klasa. Ég fékk takmörkuð réttindi, takmarkað nafnrými. Strákarnir þarna skildu hvað öryggi var. Þeir lásu um hlutverkatengda aðgangsstýringu (RBAC) í Kubernetes - og þeir snúðu því þannig að ég gæti ekki ræst belg aðskilið frá dreifingum. Ég man ekki vandamálið sem ég var að reyna að leysa með því að ræsa belg án dreifingar, en mig langaði virkilega að ræsa bara belg. Til að heppnast vel ákvað ég að sjá hvaða réttindi ég hef í klasanum, hvað ég get gert, hvað ég get ekki gert og hvað þeir hafa klúðrað þar. Á sama tíma mun ég segja þér hvað þeir hafa stillt rangt í RBAC.
Það gerðist svo að á tveimur mínútum fékk ég stjórnanda í þyrpinguna þeirra, skoðaði öll nálæg nafnasvæði, sá þar gangandi framleiðslusvið fyrirtækja sem þegar höfðu keypt þjónustuna og sett í notkun. Ég gat varla stöðvað mig frá því að fara framan í einhvern og setja blótsyrði á aðalsíðuna.
Ég mun segja þér með dæmum hvernig ég gerði þetta og hvernig á að verja þig fyrir þessu.
En fyrst ætla ég að kynna mig. Ég heiti Pavel Selivanov. Ég er arkitekt hjá Southbridge. Ég skil Kubernetes, DevOps og alls konar fína hluti. Ég og Southbridge verkfræðingarnir erum að byggja þetta allt og ég er í ráðgjöf.
Auk aðalstarfseminnar höfum við nýlega sett af stað verkefni sem kallast Slurms. Við erum að reyna að koma getu okkar til að vinna með Kubernetes aðeins til fjöldans, til að kenna öðru fólki að vinna líka með K8s.
Hvað mun ég tala um í dag? Efni skýrslunnar er augljóst - um öryggi Kubernetes klasans. En ég vil segja strax að þetta efni er mjög stórt - og því vil ég strax skýra það sem ég mun örugglega ekki tala um. Ég ætla ekki að tala um hakkað hugtök sem hafa þegar verið notuð hundrað sinnum á netinu. Allskonar RBAC og vottorð.
Ég mun tala um það sem særir mig og samstarfsmenn mína varðandi öryggi í Kubernetes klasa. Við sjáum þessi vandamál bæði hjá veitendum sem veita Kubernetes klasa og meðal viðskiptavina sem koma til okkar. Og jafnvel frá viðskiptavinum sem koma til okkar frá öðrum ráðgjafarfyrirtækjum. Það er að segja að umfang harmleiksins er í raun mjög stórt.
Það eru bókstaflega þrjú atriði sem ég mun tala um í dag:
- Notendaréttindi vs pod réttindi. Notendaréttindi og pod réttindi eru ekki það sama.
- Að safna upplýsingum um klasann. Ég mun sýna að þú getur safnað öllum þeim upplýsingum sem þú þarft frá klasa án þess að hafa sérstök réttindi í þessum klasa.
- DoS árás á klasann. Ef við getum ekki safnað upplýsingum getum við sett þyrping í alla staði. Ég mun tala um DoS árásir á klasastýringarþætti.
Annað almennt sem ég mun nefna er það sem ég prófaði þetta allt á, sem ég get örugglega sagt að það virkar allt.
Við leggjum til grundvallar uppsetningu á Kubernetes klasa með Kubespray. Ef einhver veit það ekki þá er þetta í raun sett af hlutverkum fyrir Ansible. Við notum það stöðugt í starfi okkar. Það góða er að þú getur rúllað því hvar sem er - þú getur rúllað því á járnstykki eða í ský einhvers staðar. Ein uppsetningaraðferð virkar í grundvallaratriðum fyrir allt.
Í þessum klasa mun ég hafa Kubernetes v1.14.5. Allur Cube þyrpingin, sem við munum skoða, er skipt í nafnarými, hvert nafnrými tilheyrir sérstöku teymi og meðlimir þessa teymi hafa aðgang að hverju nafnrými. Þeir geta ekki farið í mismunandi nafnrými, aðeins til síns eigin. En það er ákveðinn admin reikningur sem hefur réttindi yfir allan klasann.
Ég lofaði því að það fyrsta sem við munum gera er að fá stjórnandaréttindi á klasanum. Okkur vantar sérútbúið belg sem mun brjóta Kubernetes þyrpinguna. Allt sem við þurfum að gera er að nota það á Kubernetes klasann.
kubectl apply -f pod.yamlÞessi fræbelgur mun koma til eins af meisturum Kubernetes klasans. Og eftir þetta mun þyrpingin með ánægju skila okkur skrá sem heitir admin.conf. Í Cube geymir þessi skrá öll stjórnandavottorð og stillir á sama tíma þyrpinga-API. Svona er auðvelt að fá stjórnandaaðgang að, held ég, 98% af Kubernetes þyrpingum.
Ég endurtek, þetta hólf var búið til af einum verktaki í klasanum þínum sem hefur aðgang að tillögum sínum í eitt lítið nafnrými, það er allt klemmt af RBAC. Hann hafði engin réttindi. En engu að síður var skírteininu skilað.
Og nú um sérútbúið belg. Við keyrum það á hvaða mynd sem er. Tökum debian:jessie sem dæmi.
Við erum með þetta:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Hvað er umburðarlyndi? Meistarar í Kubernetes klasa eru venjulega merktir með einhverju sem kallast taint. Og kjarninn í þessari „sýkingu“ er að hún segir að ekki sé hægt að úthluta fræbelgjum til meistarahnúta. En enginn nennir að gefa til kynna í hvaða belg sem er að það þoli „sýkinguna“. Umburðarlyndi hluti segir bara að ef einhver hnútur er með NoSchedule, þá þolir hnúturinn okkar slíka sýkingu - og það eru engin vandamál.
Ennfremur segjum við að undir okkar sé ekki aðeins umburðarlynt, heldur vill hann einnig miða sérstaklega við meistarann. Vegna þess að meistararnir eiga það ljúffengasta sem við þurfum - öll skírteinin. Þess vegna segjum við nodeSelector - og við höfum staðlað merki á meistara, sem gerir þér kleift að velja úr öllum hnútum í þyrpingunni nákvæmlega þá hnúta sem eru meistarar.
Með þessum tveimur köflum mun hann örugglega koma til meistarans. Og hann mun fá að búa þar.
En bara að koma til meistarans er okkur ekki nóg. Þetta mun ekki gefa okkur neitt. Svo næst höfum við þessa tvo hluti:
hostNetwork: true
hostPID: true Við tilgreinum að belgurinn okkar, sem við ræsum, muni búa í kjarnanafnarýminu, í netnafnarýminu og í PID nafnrýminu. Þegar belgurinn hefur verið ræstur á masterinn mun hann geta séð öll raunveruleg, lifandi viðmót þessa hnút, hlustað á alla umferð og séð PID allra ferla.
Þá er um smáatriði að ræða. Taktu etcd og lestu það sem þú vilt.
Það áhugaverðasta er þessi Kubernetes eiginleiki, sem er sjálfgefið til staðar þar.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Og kjarni þess er að við getum sagt í belgnum sem við ræsum, jafnvel án réttinda fyrir þennan klasa, að við viljum búa til rúmmál af gerðinni hostPath. Þetta þýðir að taka slóðina frá hýsingaraðilanum sem við munum ræsa á - og taka hana sem bindi. Og svo köllum við það nafni: gestgjafi. Við festum allan þennan hostPath inni í belgnum. Í þessu dæmi, í /host möppuna.
Ég endurtek það aftur. Við sögðum belgnum að koma til meistarans, fá hostNetwork og hostPID þar - og festa alla rót meistarans inni í þessum belg.
Þú skilur að í Debian erum við með bash í gangi og þessi bash keyrir undir rót. Það er, við fengum bara rót á meistaranum, án þess að hafa nein réttindi í Kubernetes klasanum.
Síðan er allt verkefnið að fara í undirmöppuna /host /etc/kubernetes/pki, ef mér skjátlast ekki, ná í öll aðalskírteini klasans þar og, í samræmi við það, verða klasastjórnandi.
Ef þú lítur á þetta með þessum hætti eru þetta einhver hættulegustu réttindin í belgjum - óháð því hvaða réttindi notandinn hefur:
Ef ég hef réttindi til að keyra pod í einhverju nafnrými þyrpingarinnar, þá hefur þessi pod þessi réttindi sjálfgefið. Ég get keyrt forréttindabelg og þetta eru yfirleitt öll réttindi, nánast rót á hnútnum.
Uppáhaldið mitt er Root user. Og Kubernetes hefur þennan Run As Non-Root valmöguleika. Þetta er eins konar vernd gegn tölvuþrjóta. Veistu hvað „Moldavian vírusinn“ er? Ef þú ert allt í einu tölvuþrjótur og kemur í Kubernetes þyrpinguna mína, þá spyrjum við, fátækir stjórnendur: „Vinsamlegast tilgreindu í belgnum þínum með hvaða hætti þú ætlar að hakka þyrpinguna mína, keyra sem ekki rót. Annars mun það gerast að þú keyrir ferlið í belgnum þínum undir rót, og það verður mjög auðvelt fyrir þig að hakka mig. Vinsamlegast verndaðu þig fyrir sjálfum þér."
Rúmmál gestgjafaslóða er að mínu mati fljótlegasta leiðin til að ná tilætluðum árangri úr Kubernetes klasa.
En hvað á að gera við þetta allt?
Hugsunin sem ætti að koma til allra venjulegs stjórnanda sem lendir í Kubernetes er: „Já, ég sagði þér, Kubernetes virkar ekki. Það eru göt á honum. Og allur teningurinn er kjaftæði.“ Reyndar er til eitthvað sem heitir skjöl og ef þú skoðar þar er kafli .
Þetta er yaml hlutur - við getum búið hann til í Kubernetes klasanum - sem stjórnar öryggisþáttum sérstaklega í lýsingunni á fræbelgjunum. Það er, í raun, það stjórnar rétti til að nota hvaða hostNetwork, hostPID, ákveðnar hljóðstyrksgerðir sem eru í belgunum við ræsingu. Með hjálp Pod Security Policy er hægt að lýsa þessu öllu.
Það áhugaverðasta við Pod-öryggisstefnuna er að í Kubernetes klasanum er öllum PSP uppsetningartækjum ekki bara ekki lýst á nokkurn hátt, þeir eru einfaldlega óvirkir sjálfgefið. Pod Security Policy er virkjuð með því að nota inngönguviðbótina.
Allt í lagi, við skulum dreifa Pod Security Policy inn í klasann, segjum að við höfum nokkra þjónustubelg í nafnarýminu, sem aðeins stjórnendur hafa aðgang að. Segjum að í öllum öðrum tilvikum hafi fræbelgur takmarkaðan rétt. Vegna þess að líklegast verktaki þurfa ekki að keyra forréttinda fræbelgur í þyrpingunni þinni.
Og allt virðist vera í lagi með okkur. Og ekki er hægt að hakka Kubernetes þyrpinguna okkar á tveimur mínútum.
Það er vandamál. Líklegast, ef þú ert með Kubernetes þyrping, þá er eftirlit sett upp á þyrpingunni þinni. Ég myndi jafnvel ganga svo langt að spá því að ef þyrping þín er með vöktun, þá muni hann heita Prometheus.
Það sem ég ætla að segja þér mun gilda fyrir bæði Prometheus rekstraraðila og Prometheus afhentan í sinni hreinu mynd. Spurningin er sú að ef ég get ekki komið stjórnanda inn í þyrpinguna svo fljótt, þá þýðir þetta að ég þarf að leita meira. Og ég get leitað með hjálp eftirlits þíns.
Líklega lesa allir sömu greinarnar á Habré og vöktunin er staðsett í nafnarými vöktunar. Hjálmarkort kallast nokkurn veginn það sama fyrir alla. Ég giska á að ef þú gerir helm install stable/prometheus, þá endar þú með nokkurn veginn sömu nöfnin. Og líklegast þarf ég ekki einu sinni að giska á DNS nafnið í þyrpingunni þinni. Vegna þess að það er staðlað.
Næst höfum við ákveðið dev ns, þar sem þú getur keyrt ákveðinn pod. Og svo frá þessum belg er mjög auðvelt að gera eitthvað eins og þetta:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics er einn af Prometheus útflytjendum sem safnar mælingum úr Kubernetes API sjálfu. Það er mikið af gögnum þarna, hvað er í gangi í klasanum þínum, hvað það er, hvaða vandamál þú átt við hann.
Sem einfalt dæmi:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Með því að leggja fram einfalda krullabeiðni frá óforréttlátum belg geturðu fengið eftirfarandi upplýsingar. Ef þú veist ekki hvaða útgáfu af Kubernetes þú ert að keyra, mun það auðveldlega segja þér það.
Og það áhugaverðasta er að auk þess að fá aðgang að kube-state-mælingum geturðu alveg eins nálgast Prometheus sjálfan beint. Þú getur safnað mælingum þaðan. Þú getur jafnvel smíðað mælikvarða þaðan. Jafnvel fræðilega séð geturðu byggt upp slíka fyrirspurn úr þyrpingu í Prometheus, sem mun einfaldlega slökkva á henni. Og eftirlit þitt mun hætta að virka frá klasanum með öllu.
Og hér vaknar spurningin hvort einhver ytri vöktun fylgist með vöktun þinni. Ég fékk bara tækifæri til að starfa í Kubernetes klasa án nokkurra afleiðinga fyrir sjálfan mig. Þú munt ekki einu sinni vita að ég er að starfa þar, þar sem það er ekkert eftirlit lengur.
Rétt eins og með PSP, þá finnst mér eins og vandamálið sé að öll þessi fínu tækni - Kubernetes, Prometheus - þau virka bara ekki og eru full af götum. Eiginlega ekki.
Það er svoleiðis - .
Ef þú ert venjulegur stjórnandi, þá veistu líklegast um Network Policy að þetta er bara enn eitt yaml, sem það eru nú þegar margir af þeim í þyrpingunni. Og sumar netstefnur eru örugglega ekki nauðsynlegar. Og jafnvel þótt þú lesir hvað netstefna er, að það sé yaml eldveggur Kubernetes, það gerir þér kleift að takmarka aðgangsrétt á milli nafnrýma, á milli hólf, þá ákvaðstu örugglega að eldveggurinn á yaml sniði í Kubernetes byggist á næstu útdrætti ... Nei nei . Þetta er örugglega ekki nauðsynlegt.
Jafnvel þó þú hafir ekki sagt öryggissérfræðingunum þínum að með því að nota Kubernetes geturðu smíðað mjög auðveldan og einfaldan eldvegg, og mjög kornóttan. Ef þeir vita þetta ekki ennþá og trufla þig ekki: „Jæja, gefðu mér, gefðu mér...“ Þá þarftu í öllum tilvikum netstefnu til að loka fyrir aðgang að sumum þjónustustöðum sem hægt er að draga úr þyrpingunni þinni án nokkurrar heimildar.
Eins og í dæminu sem ég gaf, geturðu dregið upp kube ástandsmælikvarða úr hvaða nafnrými sem er í Kubernetes klasanum án þess að hafa nein réttindi til þess. Netstefnur hafa lokaðan aðgang frá öllum öðrum nafnasvæðum að vöktunarnafnarýminu og það er það: enginn aðgangur, engin vandamál. Í öllum töflunum sem eru til, bæði staðlaða Prometheus og Prometheus sem er í símafyrirtækinu, er einfaldlega valkostur í stýrisgildunum til að virkja netstefnur fyrir þá. Þú þarft bara að kveikja á því og þeir munu virka.
Hér er í raun eitt vandamál. Þar sem þú ert venjulegur skeggjaður stjórnandi ákvaðstu líklega að netstefnur væru ekki nauðsynlegar. Og eftir að hafa lesið alls kyns greinar um auðlindir eins og Habr, ákvaðstu að flannel, sérstaklega með hýsilgáttarstillingu, væri það besta sem þú getur valið.
Hvað á að gera?
Þú getur prófað að endurskipuleggja netlausnina sem þú ert með í Kubernetes klasanum þínum, reyndu að skipta henni út fyrir eitthvað virkara. Fyrir sama Calico, til dæmis. En ég vil segja strax að verkefnið að breyta netlausninni í Kubernetes vinnuklasa er frekar lítið. Ég leysti það tvisvar (í bæði skiptin þó fræðilega) en við sýndum meira að segja hvernig á að gera það á Slurms. Fyrir nemendur okkar sýndum við hvernig á að breyta netlausninni í Kubernetes klasa. Í grundvallaratriðum geturðu reynt að ganga úr skugga um að það sé engin niður í miðbæ á framleiðsluklasanum. En þú munt líklega ekki ná árangri.
Og vandamálið er í raun leyst mjög einfaldlega. Það eru vottorð í klasanum og þú veist að skírteinin þín renna út eftir eitt ár. Jæja, venjulega venjuleg lausn með skírteini í klasa - hvers vegna erum við að hafa áhyggjur, við munum búa til nýjan klasa í nágrenninu, láta þann gamla rotna og endurskipuleggja allt. Að vísu verðum við að sitja í einn dag þegar það verður rotið, en hér er nýr hópur.
Þegar þú hækkar nýjan klasa skaltu um leið setja inn Calico í staðinn fyrir flannel.
Hvað á að gera ef skírteinin þín eru gefin út í hundrað ár og þú ætlar ekki að endurskipuleggja klasann? Það er til eitthvað sem heitir Kube-RBAC-Proxy. Þetta er mjög flott þróun, hún gerir þér kleift að fella sjálfan sig inn sem hliðarvagn í hvaða belg sem er í Kubernetes klasanum. Og það bætir í raun heimild við þennan belg í gegnum RBAC frá Kubernetes sjálfum.
Það er eitt vandamál. Áður var þessi Kube-RBAC-Proxy lausn innbyggð í Prometheus símafyrirtækisins. En svo var hann farinn. Nútíma útgáfur treysta á þá staðreynd að þú sért með netstefnu og lokar henni með því að nota þær. Og þess vegna verðum við að endurskrifa töfluna aðeins. Reyndar ef þú ferð til , það eru dæmi um hvernig á að nota þetta sem hliðarvagna og töflurnar verða að endurskrifa sem minnst.
Það er enn eitt lítið vandamál. Prometheus er ekki sá eini sem gefur hverjum sem er mælikvarða sína. Allir Kubernetes klasahlutar okkar geta einnig skilað eigin mælingum.
En eins og ég sagði þegar, ef þú getur ekki fengið aðgang að klasanum og safnað upplýsingum, þá geturðu að minnsta kosti gert skaða.
Svo ég mun fljótt sýna tvær leiðir hvernig hægt er að eyðileggja Kubernetes þyrping.
Þú munt hlæja þegar ég segi þér þetta, þetta eru tvö alvöru mál.
Aðferð eitt. Þurrkun auðlinda.
Við skulum setja af stað annan sérstakan belg. Það mun hafa kafla eins og þennan.
resources:
requests:
cpu: 4
memory: 4Gi Eins og þú veist, eru beiðnir magn örgjörva og minnis sem er frátekið á hýsilinn fyrir tiltekna belg með beiðnum. Ef við erum með fjögurra kjarna hýsil í Kubernetes þyrping, og fjórir CPU belg koma þangað með beiðnir, þýðir það að ekki fleiri belg með beiðnum munu geta komið til þessa hýsils.
Ef ég keyri slíkan belg, þá mun ég keyra skipunina:
$ kubectl scale special-pod --replicas=...Þá mun enginn annar geta dreift til Kubernetes þyrpingarinnar. Vegna þess að allir hnútar munu klárast af beiðnum. Og þannig mun ég stöðva Kubernetes þyrpinguna þína. Ef ég geri þetta á kvöldin get ég stöðvað dreifingarnar í nokkuð langan tíma.
Ef við skoðum Kubernetes skjölin aftur munum við sjá þetta sem kallast Limit Range. Það setur tilföng fyrir klasahluti. Þú getur skrifað Limit Range hlut í yaml, notað hann á ákveðin nafnrými - og svo í þessu nafnarými geturðu sagt að þú hafir sjálfgefið, hámarks- og lágmarkstilföng fyrir hólf.
Með hjálp slíks getum við takmarkað notendur í sérstökum vörunafnarýmum teyma í getu til að gefa til kynna alls kyns viðbjóð á belgnum sínum. En því miður, jafnvel þótt þú segjir notandanum að þeir geti ekki ræst belg með beiðnum um fleiri en einn CPU, þá er til svo dásamleg mælikvarðaskipun, eða þeir geta gert mælikvarða í gegnum mælaborðið.
Og þaðan kemur aðferð númer tvö. Við kynnum 11 belg. Það eru ellefu milljarðar. Þetta er ekki vegna þess að ég kom með svona tölu, heldur vegna þess að ég sá hana sjálfur.
Raunveruleg saga. Seint um kvöldið ætlaði ég að yfirgefa skrifstofuna. Ég sé hóp þróunaraðila sitja í horninu og gera eitthvað með fartölvurnar sínar. Ég fer að strákunum og spyr: "Hvað kom fyrir þig?"
Nokkru fyrr, um níu leytið um kvöldið, var einn verktaki að búa sig undir að fara heim. Og ég ákvað: "Nú skal ég minnka umsóknina mína í eina." Ég ýtti á einn, en internetið hægðist aðeins. Hann ýtti á einn aftur, hann ýtti á einn og smellti á Enter. Ég potaði í allt sem ég gat. Svo lifnaði internetið við - og allt fór að minnka í þennan fjölda.
Að vísu gerðist þessi saga ekki á Kubernetes; á þeim tíma var það Nomad. Það endaði með því að eftir klukkutíma tilraunir okkar til að stöðva Nomad frá þrálátum tilraunum til að skala, svaraði Nomad að hann myndi ekki hætta að skala og ekki gera neitt annað. "Ég er þreyttur, ég er að fara." Og hann hrökklaðist upp.
Auðvitað reyndi ég að gera það sama á Kubernetes. Kubernetes var ekki ánægður með ellefu milljarða fræbelgja, hann sagði: „Ég get það ekki. Fer yfir innri munnhlífar." En 1 belg gætu.
Til að bregðast við einum milljarði dró teningurinn sig ekki inn í sjálfan sig. Hann byrjaði virkilega að stækka. Því lengra sem ferlið fór, því lengri tíma tók hann að búa til nýja belg. En samt hélt ferlið áfram. Eina vandamálið er að ef ég get ræst belg ótakmarkað í nafnrýminu mínu, þá get ég jafnvel án beiðna og takmarkana ræst svo marga belg með sumum verkefnum að með hjálp þessara verkefna munu hnútarnir byrja að bætast upp í minni, í CPU. Þegar ég ræsi svona marga belg ættu upplýsingarnar frá þeim að fara í geymslu, það er, osfrv. Og þegar of miklar upplýsingar berast þangað byrjar geymslan að koma of hægt til baka - og Kubernetes fer að verða sljór.
Og eitt vandamál í viðbót... Eins og þú veist, eru Kubernetes stjórnunarþættirnir ekki einn miðlægur hlutur, heldur nokkrir þættir. Einkum er stjórnandi stjórnandi, tímaáætlunarmaður og svo framvegis. Allir þessir krakkar munu byrja að vinna óþarfa, heimskulega vinnu á sama tíma, sem með tímanum mun taka meiri og meiri tíma. Stjórnandi mun búa til nýja belg. Tímaáætlun mun reyna að finna nýjan hnút fyrir þá. Þú munt líklega klárast af nýjum hnútum í klasanum þínum fljótlega. Kubernetes þyrpingin mun byrja að vinna hægar og hægar.
En ég ákvað að ganga enn lengra. Eins og þú veist, í Kubernetes er til slíkt sem kallast þjónusta. Jæja, sjálfgefið í klösunum þínum, líklega virkar þjónustan með IP töflum.
Ef þú keyrir einn milljarð belg, til dæmis, og notar síðan handrit til að þvinga Kubernetis til að búa til nýja þjónustu:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Á öllum hnútum klasans verða fleiri og fleiri nýjar iptables reglur búnar til um það bil samtímis. Ennfremur verða til einn milljarður iptables reglna fyrir hverja þjónustu.
Ég athugaði þetta allt á nokkur þúsund, allt að tíu. Og vandamálið er að þegar við þennan þröskuld er það frekar erfitt að gera ssh við hnútinn. Vegna þess að pakkar, sem fara í gegnum svo margar keðjur, byrja að líða ekki mjög vel.
Og þetta er líka allt leyst með hjálp Kubernetes. Það er svona Auðlindakvótahlutur. Stillir fjölda tiltækra tilfanga og hluta fyrir nafnrýmið í þyrpingunni. Við getum búið til yaml hlut í hverju nafnrými Kubernetes klasans. Með því að nota þennan hlut getum við sagt að við séum með ákveðinn fjölda beiðna og takmörkunum úthlutað fyrir þetta nafnrými og þá getum við sagt að í þessu nafnrými sé hægt að búa til 10 þjónustur og 10 belg. Og einn verktaki getur að minnsta kosti kæft sig á kvöldin. Kubernetes mun segja honum: „Þú getur ekki stækkað fræbelgina þína í það magn, vegna þess að auðlindin fer yfir kvótann. Það er það, vandamál leyst. .
Eitt vandamál kemur upp í þessu sambandi. Þú finnur hversu erfitt það er að verða að búa til nafnrými í Kubernetes. Til að búa hana til þurfum við að taka tillit til margra hluta.
Auðlindakvóti + Takmörkunarsvið + RBAC
• Búðu til nafnrými
• Búðu til takmarkanasvið inni
• Búa til auðlindakvóta
• Búðu til þjónustureikning fyrir CI
• Búa til hlutverkabindingu fyrir CI og notendur
• Valfrjálst ræstu nauðsynlega þjónustukapla
Þess vegna vil ég nota tækifærið til að deila þróun minni. Það er til eitthvað sem heitir SDK rekstraraðili. Þetta er leið fyrir Kubernetes klasa til að skrifa rekstraraðila fyrir hann. Þú getur skrifað fullyrðingar með því að nota Ansible.
Fyrst var það skrifað í Ansible og svo sá ég að það var SDK rekstraraðili og umritaði Ansible hlutverkið í rekstraraðila. Þessi setning gerir þér kleift að búa til hlut í Kubernetes klasanum sem kallast skipun. Inni í skipun gerir það þér kleift að lýsa umhverfinu fyrir þessa skipun í yaml. Og innan teymisumhverfisins gerir það okkur kleift að lýsa því að við erum að úthluta svo miklu fjármagni.
Lítill einn .
Og að lokum. Hvað á að gera við þetta allt?
Fyrst. Pod Security Policy er góð. Og þrátt fyrir þá staðreynd að enginn af Kubernetes uppsetningartækjunum notar þau til þessa dags, þarftu samt að nota þau í þyrpingunum þínum.
Netstefna er ekki bara annar óþarfa eiginleiki. Þetta er það sem raunverulega þarf í klasa.
LimitRange/ResourceQuota - það er kominn tími til að nota hann. Við byrjuðum að nota þetta fyrir löngu síðan og lengi vel var ég viss um að allir væru að nota þetta. Í ljós kom að þetta er sjaldgæft.
Til viðbótar við það sem ég nefndi í skýrslunni eru óskráðir eiginleikar sem gera þér kleift að ráðast á þyrpinguna. Gefin út nýlega .
Sumt er svo sorglegt og sárt. Til dæmis, við ákveðnar aðstæður, geta kubbar í Kubernetes þyrping gefið innihald warlocks möppunnar til óviðkomandi notanda.
Það eru leiðbeiningar um hvernig á að endurskapa allt sem ég sagði þér. Það eru til skrár með framleiðsludæmum um hvernig ResourceQuota og Pod Security Policy líta út. Og þú getur snert allt þetta.
Þakka ykkur öllum.
Heimild: www.habr.com