Caurumu nostiprināŔana Kubernetes klasterÄ«. Ziņojums un atÅ”ifrējums no DevOpsConf

Pāvels Seļivanovs, Southbridge risinājumu arhitekts un Slurm skolotājs, uzstājās ar prezentāciju DevOpsConf 2019. Å Ä« runa ir daļa no vienas no Kubernetes padziļinātā kursa tēmām ā€œSlurm Megaā€.

Slurm Basic: Ievads Kubernetes notiek Maskavā 18.-20.novembrī.
Slurm Mega: skatoties zem Kubernetes pārsega ā€” Maskava, 22.-24.novembris.
Slurm Online: abi Kubernetes kursi vienmēr pieejams.

Zem griezuma ir ziņojuma atÅ”ifrējums.

Labdien, kolēģi un tie, kas viņiem jÅ«t lÄ«dzi. Å odien es runāŔu par droŔību.

Es redzu, ka Å”odien zālē ir daudz apsargu. Jau iepriekÅ” atvainojos, ja lietoju terminus no droŔības pasaules ne gluži tā, kā jums ir ierasts.

Tā sagadÄ«jās, ka pirms apmēram pusgada es uzgāju vienu publisku Kubernetes klasteru. Publisks nozÄ«mē, ka ir n-tais nosaukumvietu skaits; Å”ajās nosaukumvietās ir izolēti lietotāji savā nosaukumvietā. Visi Å”ie lietotāji pieder dažādiem uzņēmumiem. Tika pieņemts, ka Å”is klasteris ir jāizmanto kā CDN. Tas nozÄ«mē, ka viņi dod jums kopu, viņi tur dod lietotāju, jÅ«s dodaties tur uz savu vārdu telpu, izvietojat savas frontes.

Mans iepriekŔējais uzņēmums mēģināja pārdot Ŕādu pakalpojumu. Un man palÅ«dza iedurt klasteru, lai redzētu, vai Å”is risinājums ir piemērots vai nē.

Es nonācu Å”ajā klasterÄ«. Man tika dotas ierobežotas tiesÄ«bas, ierobežota vārdu telpa. Tur esoÅ”ie puiÅ”i saprata, kas ir droŔība. Viņi lasÄ«ja par lomām balstÄ«tu piekļuves kontroli (RBAC) pakalpojumā Kubernetes ā€” un viņi to izmainÄ«ja tā, lai es nevarētu palaist podziņus atseviŔķi no izvietoÅ”anas. Es neatceros problēmu, kuru mēģināju atrisināt, palaižot podziņu bez izvietoÅ”anas, taču es patieŔām vēlējos palaist tikai podziņu. Lai veicas, es nolēmu redzēt, kādas tiesÄ«bas man ir klasterÄ«, ko es varu darÄ«t, ko es nevaru darÄ«t un ko viņi tur ir sagrābuÅ”i. Tajā paŔā laikā es jums pastāstÄ«Å”u, ko viņi ir nepareizi konfigurējuÅ”i RBAC.

SagadÄ«jās, ka divu minÅ«Å”u laikā es saņēmu viņu klastera administratoru, apskatÄ«ju visas blakus esoŔās nosaukumvietas, ieraudzÄ«ju tur strādājoŔās ražoÅ”anas frontes uzņēmumiem, kuri jau bija iegādājuÅ”ies pakalpojumu un izvietojuÅ”i to. Es tik tikko varēju atturēties no kāda priekÅ”gala un galvenajā lapā ievietot kādu lamuvārdu.

Ar piemēriem pastāstÄ«Å”u, kā es to izdarÄ«ju un kā no tā sevi pasargāt.

Bet vispirms ļaujiet man iepazīstināt ar sevi. Mani sauc Pāvels Seļivanovs. Es esmu Sautbridžas arhitekts. Es saprotu Kubernetes, DevOps un visādas smalkas lietas. Sautbridžas inženieri un es to visu veidojam, un es konsultēju.

Papildus mÅ«su galvenajām aktivitātēm nesen esam uzsākuÅ”i projektus ar nosaukumu Slurms. Mēs cenÅ”amies savu prasmi strādāt ar Kubernetes nedaudz nest masās, mācÄ«t arÄ« citus cilvēkus strādāt ar K8.

Par ko es Å”odien runāŔu? Ziņojuma tēma ir acÄ«mredzama - par Kubernetes klastera droŔību. Bet es gribu uzreiz pateikt, ka Ŕī tēma ir ļoti liela - un tāpēc es gribu nekavējoties precizēt, par ko es noteikti nerunāŔu. Es nerunāŔu par uzlauztiem terminiem, kas jau simts reizes izmantoti internetā. Visa veida RBAC un sertifikāti.

Es runāŔu par to, kas mani un manus kolēģus sāpina par droŔību Kubernetes klasterÄ«. Mēs redzam Ŕīs problēmas gan starp pakalpojumu sniedzējiem, kas nodroÅ”ina Kubernetes klasterus, gan starp klientiem, kas vērÅ”as pie mums. Un pat no klientiem, kuri pie mums ierodas no citām konsultāciju admin kompānijām. Tas ir, traģēdijas mērogs patiesÄ«bā ir ļoti liels.

Burtiski ir trīs punkti, par kuriem es Ŕodien runāŔu:

  1. Lietotāja tiesības pret pod tiesībām. Lietotāja tiesības un pod tiesības nav viens un tas pats.
  2. Informācijas vākŔana par klasteru. Es parādīŔu, ka jūs varat savākt visu nepiecieŔamo informāciju no klastera bez īpaŔām tiesībām Ŕajā klasterī.
  3. DoS uzbrukums klasterim. Ja mēs nevaram apkopot informāciju, mēs jebkurā gadÄ«jumā varēsim ievietot klasteri. Es runāŔu par DoS uzbrukumiem klasteru vadÄ«bas elementiem.

Vēl viena vispārÄ«ga lieta, ko pieminÄ“Å”u, ir tas, uz ko es Å”o visu testēju, uz kā es noteikti varu teikt, ka tas viss darbojas.

Par pamatu ņemam Kubernetes klastera uzstādÄ«Å”anu, izmantojot Kubespray. Ja kāds nezina, tas patiesÄ«bā ir Ansible lomu kopums. Mēs to pastāvÄ«gi izmantojam savā darbā. Labā lieta ir tā, ka to var ripināt jebkur - var uzrullēt uz dzelzs gabaliņiem vai kaut kur mākonÄ«. Viena instalÄ“Å”anas metode principā darbojas visam.

Å ajā klasterÄ« man bÅ«s Kubernetes v1.14.5. Viss Cube klasteris, kuru mēs apsvērsim, ir sadalÄ«ts nosaukumvietās, katra nosaukumvieta pieder atseviŔķai komandai, un Ŕīs komandas locekļiem ir piekļuve katrai nosaukumvietai. Viņi nevar doties uz dažādām nosaukumu telpām, tikai uz savu. Bet ir noteikts administratora konts, kuram ir tiesÄ«bas uz visu klasteru.

Caurumu nostiprināŔana Kubernetes klasterÄ«. Ziņojums un atÅ”ifrējums no DevOpsConf

Es apsolÄ«ju, ka pirmā lieta, ko mēs darÄ«sim, ir iegÅ«t klastera administratora tiesÄ«bas. Mums ir nepiecieÅ”ams speciāli sagatavots pods, kas pārtrauks Kubernetes kopu. Viss, kas mums jādara, ir jāpiemēro Kubernetes klasterim.

kubectl apply -f pod.yaml

Å is pods nonāks pie viena no Kubernetes klastera meistariem. Un pēc tam klasteris ar prieku atgriezÄ«s mums failu ar nosaukumu admin.conf. Programmā Cube Å”is fails saglabā visus administratora sertifikātus un vienlaikus konfigurē klastera API. Tādā veidā ir viegli iegÅ«t administratora piekļuvi, manuprāt, 98% Kubernetes klasteru.

Es atkārtoju, ka Å”o aplikumu izveidoja viens jÅ«su klastera izstrādātājs, kuram ir piekļuve, lai izvietotu savus priekÅ”likumus vienā mazā nosaukumvietā. To visu ierobežo RBAC. Viņam nebija tiesÄ«bu. Bet tomēr sertifikāts tika atgriezts.

Un tagad par Ä«paÅ”i sagatavotu pāksti. Mēs to izpildām uz jebkura attēla. Kā piemēru ņemsim debian:jessie.

Mums ir Ŕī lieta:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

Kas ir tolerance? Kubernetes klastera meistari parasti tiek apzÄ«mēti ar kaut ko, ko sauc par piesārņojumu. Un Ŕīs ā€œinfekcijasā€ bÅ«tÄ«ba ir tāda, ka pākstis nevar pieŔķirt galvenajiem mezgliem. Bet neviens neuztraucas nevienā pākstÄ« norādÄ«t, ka tas ir tolerants pret "infekciju". Sadaļā Pielaide tikai teikts, ka, ja kādam mezglam ir NoSchedule, tad mÅ«su mezgls ir izturÄ«gs pret Ŕādu infekciju - un nekādu problēmu.

Tālāk mēs sakām, ka mÅ«su apakÅ”daļa ir ne tikai iecietÄ«ga, bet arÄ« vēlas Ä«paÅ”i mērķēt uz meistaru. Jo meistariem ir visgarŔīgākais, kas mums vajadzÄ«gs - visi sertifikāti. Tāpēc mēs sakām nodeSelector ā€” un mums ir standarta uzlÄ«me uz galvenajām ierÄ«cēm, kas ļauj no visiem klastera mezgliem atlasÄ«t tieÅ”i tos mezglus, kas ir galvenie.

Ar Ŕīm divām sekcijām viņŔ noteikti tiks pie meistara. Un viņam atļaus tur dzÄ«vot.

Bet ar atnākŔanu pie meistara mums nepietiek. Tas mums neko nedos. Tālāk mums ir Ŕīs divas lietas:

hostNetwork: true 
hostPID: true 

Mēs norādām, ka mÅ«su pods, kuru mēs palaižam, atradÄ«sies kodola nosaukumvietā, tÄ«kla nosaukumvietā un PID nosaukumvietā. Kad pods tiks palaists galvenajā ierÄ«cē, tas varēs redzēt visas Ŕī mezgla reālās, dzÄ«vās saskarnes, klausÄ«ties visu trafiku un redzēt visu procesu PID.

Tad runa ir par sīkumiem. Paņem etcd un lasi ko gribi.

Interesantākā lieta ir Ŕī Kubernetes funkcija, kas tur ir pieejama pēc noklusējuma.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

Un tā bÅ«tÄ«ba ir tāda, ka mēs varam teikt, ka mēs palaižam pat bez tiesÄ«bām uz Å”o klasteru, ka mēs vēlamies izveidot hostPath tipa sējumu. Tas nozÄ«mē izvēlēties ceļu no saimniekdatora, kurā tiks palaists, un pieņemt to kā apjomu. Un tad mēs to saucam par nosaukumu: saimnieks. Mēs uzstādām visu Å”o saimniekdatora ceļu podā. Å ajā piemērā uz /host direktoriju.

Es to atkārtoÅ”u vēlreiz. Mēs likām podam nākt pie galvenā, iegÅ«t resursdatora tÄ«klu un resursdatora PID tur ā€” un Å”ajā podā ievietojiet visu galvenās ierÄ«ces sakni.

JÅ«s saprotat, ka Debian mums darbojas bash, un Å”is bash darbojas zem saknes. Tas ir, mēs tikko saņēmām root uz galvenā, bez jebkādām tiesÄ«bām Kubernetes klasterÄ«.

Tad viss uzdevums ir doties uz apakÅ”direktoriju /host /etc/kubernetes/pki, ja nemaldos, paņemt tur visus klastera galvenos sertifikātus un attiecÄ«gi kļūt par klastera administratoru.

Ja paskatās Ŕādi, Ŕīs ir dažas no visbÄ«stamākajām tiesÄ«bām aplikumos ā€” neatkarÄ«gi no lietotāja tiesÄ«bām:
Caurumu nostiprināŔana Kubernetes klasterÄ«. Ziņojums un atÅ”ifrējums no DevOpsConf

Ja man ir tiesÄ«bas palaist podziņu kādā klastera nosaukumvietā, tad Å”im podam ir Ŕīs tiesÄ«bas pēc noklusējuma. Es varu palaist priviliģētus apvidus, un tas parasti ir visas tiesÄ«bas, praktiski saknes mezglā.

Mans mīļākais ir Root lietotājs. Un Kubernetes ir Ŕī opcija Run As Non-Root. Tas ir aizsardzÄ«bas veids pret hakeriem. Vai jÅ«s zināt, kas ir "Moldāvijas vÄ«russ"? Ja jÅ«s pēkŔņi esat hakeris un nonākat pie mana Kubernetes klastera, tad mēs, nabaga administratori, lÅ«dzam: ā€œLÅ«dzu, norādiet savos podiņos, ar kuriem jÅ«s uzlauzÄ«sit manu klasteru, palaist kā ne-root. Pretējā gadÄ«jumā jÅ«s palaidÄ«sit procesu savā podā zem saknes, un jums bÅ«s ļoti viegli mani uzlauzt. LÅ«dzu, pasargā sevi no sevis."

Resursdatora ceļa apjoms, manuprāt, ir ātrākais veids, kā iegūt vēlamo rezultātu no Kubernetes klastera.

Bet ko ar to visu iesākt?

Ikvienam normālam administratoram, kurÅ” sastopas ar Kubernetes, jādomā: ā€œJā, es jums teicu, Kubernetes nedarbojas. Tajā ir caurumi. Un viss Kubs ir muļķības. PatiesÄ«bā ir tāda lieta kā dokumentācija, un, ja paskatās, tad ir sadaļa Pod droŔības politika.

Å is ir yaml objekts ā€” mēs to varam izveidot Kubernetes klasterÄ« ā€”, kas kontrolē droŔības aspektus Ä«paÅ”i aprakstā. Tas nozÄ«mē, ka faktiski tā kontrolē tiesÄ«bas izmantot jebkuru resursdatora tÄ«klu, resursdatora PID, noteiktus skaļuma veidus, kas startÄ“Å”anas laikā atrodas podiņos. Ar Pod droŔības politikas palÄ«dzÄ«bu to visu var aprakstÄ«t.

Pod droŔības politikas interesantākā lieta ir tāda, ka Kubernetes klasterÄ« visi PSP instalētāji nav vienkārÅ”i aprakstÄ«ti nekādā veidā, tie vienkārÅ”i ir atspējoti pēc noklusējuma. Pod droŔības politika ir iespējota, izmantojot uzņemÅ”anas spraudni.

Labi, izvietosim klasterÄ« Pod droŔības politiku, pieņemsim, ka mums ir daži pakalpojumu podi nosaukumvietā, kuriem var piekļūt tikai administratori. Teiksim, visos citos gadÄ«jumos pākstÄ«m ir ierobežotas tiesÄ«bas. Tā kā, visticamāk, izstrādātājiem nav nepiecieÅ”ams jÅ«su klasterÄ« palaist priviliģētus aplikācijas.

Un Ŕķiet, ka ar mums viss ir kārtÄ«bā. Un mÅ«su Kubernetes klasteru nevar uzlauzt divās minÅ«tēs.

Ir problēma. Visticamāk, ja jums ir Kubernetes klasteris, jūsu klasterī ir instalēta uzraudzība. Es pat varētu paredzēt, ka, ja jūsu klasterim ir monitorings, to sauks par Prometeju.

Tas, ko es jums pastāstÄ«Å”u, bÅ«s spēkā gan Prometheus operatoram, gan Prometheus, kas tiek piegādāts tÄ«rā veidā. Jautājums ir tāds, ka, ja es nevaru tik ātri dabÅ«t klasterÄ« administratoru, tas nozÄ«mē, ka man ir jāmeklē vairāk. Un es varu meklēt ar jÅ«su uzraudzÄ«bas palÄ«dzÄ«bu.

DroÅ”i vien visi lasa vienus un tos paÅ”us rakstus par HabrĆ©, un monitorings atrodas monitoringa nosaukumvietā. StÅ«res diagrammu visiem sauc aptuveni vienādi. Es domāju, ka, ja jÅ«s instalējat stable/prometheus, jÅ«s saņemsit aptuveni tādus paÅ”us nosaukumus. Un, visticamāk, man pat nevajadzēs uzminēt DNS nosaukumu jÅ«su klasterÄ«. Jo tas ir standarts.

Caurumu nostiprināŔana Kubernetes klasterÄ«. Ziņojums un atÅ”ifrējums no DevOpsConf

Tālāk mums ir noteikts dev ns, kurā varat palaist noteiktu pod. Un tad no Ŕī podiņa ir ļoti viegli izdarÄ«t kaut ko lÄ«dzÄ«gu:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics ir viens no Prometheus eksportētājiem, kas apkopo metriku no paÅ”as Kubernetes API. Tur ir daudz datu, kas darbojas jÅ«su klasterÄ«, kas tas ir, kādas problēmas jums ir ar to.

Kā vienkārÅ”s piemērs:

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

Veicot vienkārŔu čokuroŔanās pieprasījumu no nepiederoŔas ierīces, varat iegūt Ŕādu informāciju. Ja nezināt, kuru Kubernetes versiju izmantojat, tas jums viegli pateiks.

Un pats interesantākais ir tas, ka papildus kube-state-metrics piekļuvei jÅ«s varat tikpat viegli piekļūt arÄ« paÅ”am Prometheus. No turienes varat apkopot metriku. JÅ«s pat varat izveidot metriku no turienes. Pat teorētiski jÅ«s varat izveidot Ŕādu vaicājumu no Prometheus klastera, kas to vienkārÅ”i izslēgs. Un jÅ«su uzraudzÄ«ba pārtrauks darboties no kopas.

Un Å”eit rodas jautājums, vai kāds ārējs monitorings uzrauga jÅ«su uzraudzÄ«bu. Es tikko saņēmu iespēju darboties Kubernetes klasterÄ« bez jebkādām sekām sev. JÅ«s pat nezināsiet, ka es tur darbojos, jo vairs nav nekādas uzraudzÄ«bas.

Tāpat kā ar PSP, Ŕķiet, ka problēma ir tajā, ka visas Ŕīs smalkās tehnoloÄ£ijas - Kubernetes, Prometheus - tās vienkārÅ”i nedarbojas un ir pilnas ar caurumiem. Ne Ä«sti.

Ir tāda lieta - Tīkla politika.

Ja esat parasts administrators, tad, visticamāk, jÅ«s zināt par tÄ«kla politiku, ka tas ir tikai vēl viens yaml, kuru klasterÄ« jau ir daudz. Un dažas tÄ«kla politikas noteikti nav vajadzÄ«gas. Un pat ja jÅ«s izlasāt, kas ir tÄ«kla politika, ka tas ir Kubernetes yaml ugunsmÅ«ris, tas ļauj ierobežot piekļuves tiesÄ«bas starp nosaukumvietām, starp podiem, tad jÅ«s noteikti nolēmāt, ka Kubernetes ugunsmÅ«ris yaml formātā ir balstÄ«ts uz nākamajām abstrakcijām. ... Nē, nē. Tas noteikti nav nepiecieÅ”ams.

Pat ja neesat teicis saviem droŔības speciālistiem, ka, izmantojot savu Kubernetes, varat izveidot ļoti vienkārÅ”u un vienkārÅ”u ugunsmÅ«ri, turklāt ļoti detalizētu. Ja viņi to vēl nezina un jÅ«s netraucē: ā€œNu, dod man, dod man...ā€ Tad jebkurā gadÄ«jumā jums ir nepiecieÅ”ama tÄ«kla politika, lai bloķētu piekļuvi dažām pakalpojumu vietām, kuras var izņemt no jÅ«su klastera. bez jebkādas atļaujas.

Tāpat kā manis sniegtajā piemērā, varat iegÅ«t kube stāvokļa metriku no jebkuras Kubernetes klastera nosaukumvietas bez jebkādām tiesÄ«bām to darÄ«t. TÄ«kla politikām ir slēgta piekļuve no visām pārējām nosaukumvietām pārraudzÄ«bas nosaukumvietai, un tas arÄ« viss: nav piekļuves, nav problēmu. Visās esoÅ”ajās diagrammās, gan standarta Prometheus, gan Prometheus, kas atrodas operatorā, stÅ«res vērtÄ«bās ir vienkārÅ”i iespēja tiem vienkārÅ”i iespējot tÄ«kla politikas. Jums tas vienkārÅ”i jāieslēdz, un tie darbosies.

Å eit patieŔām ir viena problēma. BÅ«dams parasts bārdains administrators, jÅ«s, visticamāk, nolēmāt, ka tÄ«kla politikas nav vajadzÄ«gas. Un pēc visu veidu rakstu lasÄ«Å”anas par resursiem, piemēram, Habr, jÅ«s nolēmāt, ka flanelis, Ä«paÅ”i ar saimniekdatora vārtejas režīmu, ir labākā lieta, ko varat izvēlēties.

Ko darīt?

Varat mēģināt pārizvietot Kubernetes klasterÄ« esoÅ”o tÄ«kla risinājumu, mēģināt aizstāt to ar kaut ko funkcionālāku. Par to paÅ”u Calico, piemēram. Bet es gribu uzreiz teikt, ka uzdevums mainÄ«t tÄ«kla risinājumu Kubernetes darba klasterÄ« ir diezgan nenozÄ«mÄ«gs. Divreiz atrisināju (abas reizes gan teorētiski), bet Slurmā ā€‹ā€‹pat parādÄ«jām, kā to izdarÄ«t. MÅ«su studentiem mēs parādÄ«jām, kā mainÄ«t tÄ«kla risinājumu Kubernetes klasterÄ«. Principā varat mēģināt pārliecināties, ka ražoÅ”anas klasterÄ« nav dÄ«kstāves. Bet, visticamāk, jums tas neizdosies.

Un problēma patiesÄ«bā tiek atrisināta ļoti vienkārÅ”i. KlasterÄ« ir sertifikāti, un jÅ«s zināt, ka jÅ«su sertifikāti beigsies pēc gada. Nu, un parasti parasts risinājums ar sertifikātiem klasterÄ« - kāpēc mēs uztraucamies, celsim blakus jaunu klasteri, ļausim vecajam sapuvāt un visu pārkārtosim. Tiesa, kad tas sapuvis, mums bÅ«s jāpasēž viena diena, bet Å”eit ir jauns klasteris.

Paceļot jaunu kopu, tajā paŔā laikā flaneļa vietā ievietojiet Calico.

Ko darīt, ja jūsu sertifikāti tiek izsniegti uz simts gadiem un jūs neplānojat pārdalīt klasteru? Ir tāda lieta kā Kube-RBAC-Proxy. Šī ir ļoti forŔa izstrāde, kas ļauj iegult sevi kā blakusvāģa konteineru jebkurā Kubernetes klastera podā. Un tas faktiski pievieno atļauju Ŕim podam, izmantojot paŔa Kubernetes RBAC.

Ir viena problēma. IepriekÅ” Å”is Kube-RBAC-Proxy risinājums tika iebÅ«vēts operatora Prometheus. Bet tad viņŔ bija prom. Tagad modernās versijas paļaujas uz to, ka jums ir tÄ«kla politika, un aizveriet to, izmantojot tās. Un tāpēc mums diagramma bÅ«s nedaudz jāpārraksta. PatiesÄ«bā, ja jÅ«s dodaties uz Å”o repozitoriju, ir piemēri, kā to izmantot kā blakusvāģus, un diagrammas bÅ«s minimāli jāpārraksta.

Ir vēl viena neliela problēma. Prometejs nav vienīgais, kas izsniedz savus rādītājus ikvienam. Visi mūsu Kubernetes klastera komponenti var arī atgriezt savus rādītājus.

Bet, kā jau teicu, ja nevarat piekļūt klasterim un apkopot informāciju, varat vismaz nodarīt kaitējumu.

Tāpēc es ātri parādÄ«Å”u divus veidus, kā var sabojāt Kubernetes kopu.

Jūs smiesieties, kad es jums to pateikŔu, Ŕie ir divi reāli dzīves gadījumi.

Pirmā metode. Resursu izsīkŔana.

PalaidÄ«sim vēl vienu Ä«paÅ”u podiņu. Tam bÅ«s Ŕāda sadaļa.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

Kā jÅ«s zināt, pieprasÄ«jumi ir CPU un atmiņas apjoms, kas resursdatorā ir rezervēts konkrētiem podiem ar pieprasÄ«jumiem. Ja mums ir četru kodolu resursdators Kubernetes klasterÄ« un četri CPU podi tur ierodas ar pieprasÄ«jumiem, tas nozÄ«mē, ka Å”im resursdatoram vairs nevarēs nonākt neviens pods ar pieprasÄ«jumiem.

Ja es palaižu Ŕādu podziņu, es izpildÄ«Å”u komandu:

$ kubectl scale special-pod --replicas=...

Tad neviens cits nevarēs izvietot Kubernetes klasterÄ«. Jo visiem mezgliem beigsies pieprasÄ«jumi. Un tādējādi es apturÄ“Å”u jÅ«su Kubernetes kopu. Ja es to daru vakarā, es varu apturēt izvietoÅ”anu diezgan ilgu laiku.

Ja mēs vēlreiz paskatÄ«simies uz Kubernetes dokumentāciju, mēs redzēsim Å”o lietu, ko sauc par Limit Range. Tas nosaka resursus klasteru objektiem. JÅ«s varat uzrakstÄ«t Limit Range objektu yaml, lietot to noteiktām nosaukumvietām - un tad Å”ajā nosaukumvietā varat teikt, ka jums ir noklusējuma, maksimālie un minimālie resursi podiem.

Ar Ŕādas lietas palÄ«dzÄ«bu mēs varam ierobežot lietotājus konkrētās komandu produktu nosaukumvietās, lai savos aplikumos norādÄ«tu visa veida nepatÄ«kamas lietas. Bet diemžēl, pat ja jÅ«s sakāt lietotājam, ka viņŔ nevar palaist aplikumus ar pieprasÄ«jumiem vairāk nekā vienam CPU, ir tik brÄ«niŔķīga mēroga komanda, vai arÄ« viņi var veikt mērogoÅ”anu, izmantojot informācijas paneli.

Un Å”eit nāk metode numur divi. Mēs izlaižam 11 111 111 111 111 pākstis. Tie ir vienpadsmit miljardi. Tas nav tāpēc, ka es izdomāju Ŕādu numuru, bet gan tāpēc, ka es pats to redzēju.

ÄŖsts stāsts. Vēlu vakarā grasÄ«jos iziet no biroja. Es redzu kaktā sēžam izstrādātāju grupu un izmisÄ«gi kaut ko dara ar saviem klēpjdatoriem. Es piegāju pie puiÅ”iem un jautāju: "Kas ar jums noticis?"

Nedaudz agrāk, ap deviņiem vakarā, viens no izstrādātājiem gatavojās doties mājās. Un es nolēmu: "Tagad es samazināŔu savu pieteikumu lÄ«dz vienam." Nospiedu vienu, bet internets nedaudz palēninājās. ViņŔ vēlreiz nospieda vienu, viņŔ nospieda vienu un noklikŔķināja uz Enter. Es bakstÄ«ju uz visu, ko varēju. Tad atdzÄ«vojās internets ā€“ un viss sāka samazināties lÄ«dz Å”im skaitlim.

Tiesa, Å”is stāsts nenotika Kubernetes, tajā laikā tas bija Nomad. Tas beidzās ar faktu, ka pēc stundas mÅ«su mēģinājumiem apturēt Nomad no neatlaidÄ«giem mērogoÅ”anas mēģinājumiem Nomads atbildēja, ka viņŔ nepārtrauks mērogoÅ”anu un nedarÄ«s neko citu. "Esmu noguris, es dodos prom." Un viņŔ saritinājās.

Protams, es mēģināju to darÄ«t arÄ« Kubernetes. Kubernetess nebija apmierināts ar vienpadsmit miljardiem pākstÄ«m, viņŔ teica: ā€œEs nevaru. Pārsniedz iekŔējos mutes aizsargus." Bet 1 000 000 000 pākstis varētu.

Atbildot uz vienu miljardu, Kubs neatkāpās sevÄ«. ViņŔ patieŔām sāka mērogot. Jo tālāk process gāja, jo vairāk laika viņam prasÄ«ja jaunu pākstÄ«m. Bet tomēr process turpinājās. VienÄ«gā problēma ir tā, ka, ja es varu neierobežoti palaist podus savā nosaukumvietā, tad pat bez pieprasÄ«jumiem un ierobežojumiem es varu palaist tik daudz podiņu ar dažiem uzdevumiem, ka ar Å”o uzdevumu palÄ«dzÄ«bu mezgli sāks pievienoties atmiņā, CPU. Kad es palaižu tik daudz podziņu, informācijai no tiem vajadzētu nonākt krātuvē, tas ir, utt. Un, kad tur nonāk pārāk daudz informācijas, krātuve sāk atgriezties pārāk lēni - un Kubernetes sāk kļūt blāvi.

Un vēl viena problēma... Kā zināms, Kubernetes vadÄ«bas elementi nav viena centrālā lieta, bet vairākas sastāvdaļas. Jo Ä«paÅ”i ir kontroliera pārvaldnieks, plānotājs un tā tālāk. Visi Å”ie puiÅ”i vienlaikus sāks darÄ«t nevajadzÄ«gu, stulbu darbu, kas laika gaitā sāks aizņemt arvien vairāk laika. Kontroliera pārvaldnieks izveidos jaunus aplikumus. Plānotājs mēģinās viņiem atrast jaunu mezglu. Visticamāk, drÄ«z jÅ«su klasterÄ« beigsies jauni mezgli. Kubernetes klasteris sāks strādāt arvien lēnāk.

Bet es nolēmu iet vēl tālāk. Kā zināms, Kubernetes ir tāda lieta, ko sauc par servisu. Nu, pēc noklusējuma jūsu klasteros, visticamāk, pakalpojums darbojas, izmantojot IP tabulas.

Ja palaižat, piemēram, vienu miljardu aplikumu un pēc tam izmantojat skriptu, lai piespiestu Kubernetis izveidot jaunus pakalpojumus:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

Visos klastera mezglos aptuveni vienlaicīgi tiks ģenerēti arvien vairāk jaunu iptables noteikumu. Turklāt katram pakalpojumam tiks ģenerēts viens miljards iptables noteikumu.

Es visu Å”o lietu pārbaudÄ«ju uz vairākiem tÅ«kstoÅ”iem, lÄ«dz pat desmit. Un problēma ir tā, ka jau pie Ŕī sliekŔņa ir diezgan problemātiski veikt ssh mezglam. Jo paciņas, ejot cauri tik daudzām ķēdēm, sāk justies ne pārāk labi.

Un arÄ« tas viss tiek atrisināts ar Kubernetes palÄ«dzÄ«bu. Ir tāds Resursu kvotas objekts. Iestata klastera nosaukumvietai pieejamo resursu un objektu skaitu. Mēs varam izveidot yaml objektu katrā Kubernetes klastera nosaukumvietā. Izmantojot Å”o objektu, mēs varam teikt, ka Å”ai nosaukumvietai mums ir pieŔķirts noteikts pieprasÄ«jumu un ierobežojumu skaits, un tad mēs varam teikt, ka Å”ajā nosaukumu telpā ir iespējams izveidot 10 pakalpojumus un 10 podi. Un atseviŔķs izstrādātājs var vismaz sevi vakaros nosmakt. Kubernetes viņam pateiks: "JÅ«s nevarat mērogot savus pākstis lÄ«dz Ŕādai summai, jo resurss pārsniedz kvotu." Tas arÄ« viss, problēma atrisināta. Dokumentācija Å”eit.

Šajā sakarā rodas viens problemātisks punkts. Jūs jūtat, cik grūti kļūst izveidot nosaukumvietu Kubernetes. Lai to izveidotu, mums ir jāņem vērā daudzas lietas.

Resursu kvota + ierobežojuma diapazons + RBAC
ā€¢ Izveidojiet nosaukumvietu
ā€¢ Izveidojiet ierobežojuma diapazonu iekÅ”pusē
ā€¢ Izveidot resursu kvotas ietvaros
ā€¢ Izveidojiet pakalpojuma kontu CI
ā€¢ Izveidot lomu piesaisti CI un lietotājiem
ā€¢ Pēc izvēles palaidiet nepiecieÅ”amos servisa blokus

Tāpēc vēlos izmantot iespēju, lai padalītos ar saviem notikumiem. Ir tāda lieta, ko sauc par SDK operatoru. Tas ir veids, kā Kubernetes klasteris var rakstīt operatorus. Jūs varat rakstīt paziņojumus, izmantojot Ansible.

Sākumā tas tika rakstÄ«ts Ansible, un tad es redzēju, ka ir SDK operators, un Ansible lomu pārrakstÄ«ju par operatoru. Å is paziņojums ļauj izveidot objektu Kubernetes klasterÄ«, ko sauc par komandu. Komandā tas ļauj aprakstÄ«t Ŕīs komandas vidi yaml valodā. Un komandas vidē tas ļauj mums aprakstÄ«t, ka mēs pieŔķiram tik daudz resursu.

Mazliet atvieglojot visu Ŕo sarežģīto procesu.

Un noslēgumā. Ko darÄ«t ar Å”o visu?
Pirmkārt. Pod droŔības politika ir laba. Un, neskatoties uz to, ka neviens no Kubernetes instalētājiem tos neizmanto lÄ«dz Å”ai dienai, jums tie joprojām ir jāizmanto savās kopās.

TÄ«kla politika nav tikai vēl viena nevajadzÄ«ga funkcija. Tas ir tas, kas patieŔām ir vajadzÄ«gs klasterÄ«.

LimitRange/ResourceQuota ā€” ir pienācis laiks to izmantot. Mēs sākām to lietot jau sen, un ilgu laiku es biju pārliecināts, ka visi to lieto. IzrādÄ«jās, ka tas notiek reti.

Papildus tam, ko minēju ziņojuma laikā, ir arÄ« nedokumentētas funkcijas, kas ļauj uzbrukt klasterim. Nesen izlaists plaÅ”a Kubernetes ievainojamÄ«bu analÄ«ze.

Dažas lietas ir tik skumjas un sāpīgas. Piemēram, noteiktos apstākļos Kubernetes klastera kubeleti var nodot warlocks direktorijas saturu neautorizētam lietotājam.

Å eit Ir norādÄ«jumi, kā reproducēt visu, ko es jums teicu. Ir faili ar ražoÅ”anas piemēriem par to, kā izskatās ResourceQuota un Pod droŔības politika. Un tam visam var pieskarties.

Paldies visiem.

Avots: www.habr.com

Pievieno komentāru