„Southbridge“ sprendimų architektas ir „Slurm“ mokytojas Pavelas Selivanovas skaitė pranešimą „DevOpsConf 2019“. Šis pokalbis yra viena iš giluminio kurso apie Kubernetes „Slurm Mega“ temų.
vyks Maskvoje lapkričio 18-20 d.
– Maskva, lapkričio 22–24 d.
visada prieinama.
Po pjūviu yra ataskaitos nuorašas.
Laba diena, kolegos ir jiems užjaučiantys. Šiandien kalbėsiu apie saugumą.
Matau, kad šiandien salėje daug apsaugininkų. Iš anksto atsiprašau, jei vartoju saugumo pasaulio terminus ne taip, kaip jums įprasta.
Taip atsitiko, kad maždaug prieš šešis mėnesius susidūriau su vienu viešu Kubernetes klasteriu. Vieša reiškia, kad yra n-asis vardų erdvių skaičius; šiose vardų erdvėse naudotojai yra atskirti savo vardų erdvėje. Visi šie vartotojai priklauso skirtingoms įmonėms. Na, buvo manoma, kad šis klasteris turėtų būti naudojamas kaip CDN. Tai yra, jie suteikia jums klasterį, jie suteikia jums ten vartotoją, jūs ten pateksite į savo vardų erdvę, įdiekite savo frontus.
Mano ankstesnė įmonė bandė parduoti tokią paslaugą. Ir manęs paprašė padurti klasterį, kad pamatyčiau, ar šis sprendimas tinkamas, ar ne.
Aš atėjau į šį klasterį. Man buvo suteiktos ribotos teisės, ribota vardų erdvė. Ten buvę vaikinai suprato, kas yra saugumas. Jie perskaitė apie vaidmenimis pagrįstą prieigos kontrolę (RBAC) „Kubernetes“ ir iškraipė ją taip, kad negalėčiau paleisti blokų atskirai nuo diegimo. Neatsimenu problemos, kurią bandžiau išspręsti paleisdamas bloką be diegimo, bet labai norėjau paleisti tik podėlį. Kad pasisektų, nusprendžiau pažiūrėti, kokias teises turiu klasteryje, ką galiu daryti, ko negaliu ir ką jie ten sugadino. Tuo pat metu aš jums pasakysiu, ką jie neteisingai sukonfigūravo RBAC.
Taip jau susiklostė, kad per dvi minutes gavau jų klasterio administratorių, apžiūrėjau visas gretimas vardų sritis, ten pamačiau veikiančias gamybines įmonių, kurios jau įsigijo paslaugą ir įdiegė, gamybos frontus. Vargais negalais susilaikiau nuo kažkieno priekyje ir pagrindiniame puslapyje įdėjus keiksmažodžių.
Papasakosiu pavyzdžiais, kaip aš tai padariau ir kaip nuo to apsisaugoti.
Bet pirmiausia leiskite prisistatyti. Mano vardas Pavelas Selivanovas. Esu Southbridge architektas. Suprantu Kubernetes, DevOps ir visokius įmantrius dalykus. „Southbridge“ inžinieriai ir aš visa tai statome, o aš konsultuoju.
Be pagrindinės veiklos, neseniai pradėjome projektus „Slurms“. Stengiamės savo gebėjimą dirbti su Kubernetes šiek tiek pernešti į mases, išmokyti kitus žmones taip pat dirbti su K8.
Apie ką šiandien kalbėsiu? Pranešimo tema akivaizdi – apie Kubernetes klasterio saugumą. Bet iš karto noriu pasakyti, kad ši tema yra labai didelė - todėl noriu iš karto patikslinti, apie ką aš tikrai nekalbėsiu. Nekalbėsiu apie nulaužtus terminus, kurie jau šimtą kartų buvo naudojami internete. Visų rūšių RBAC ir sertifikatai.
Pakalbėsiu apie tai, kas mane ir mano kolegas skaudina dėl saugumo Kubernetes klasteryje. Šias problemas matome tiek tarp tiekėjų, teikiančių „Kubernetes“ grupes, ir tarp pas mus besikreipiančių klientų. Ir net iš klientų, kurie pas mus ateina iš kitų konsultacinių administravimo įmonių. Tai yra, tragedijos mastai iš tikrųjų yra labai dideli.
Yra trys punktai, apie kuriuos šiandien kalbėsiu:
- Vartotojo teisės prieš pod teises. Vartotojo teisės ir pod teisės nėra tas pats dalykas.
- Informacijos apie klasterį rinkimas. Parodysiu, kad visą reikiamą informaciją galite rinkti iš klasterio neturėdami specialių teisių šioje grupėje.
- DoS ataka prieš klasterį. Jei negalėsime rinkti informacijos, bet kuriuo atveju galėsime įdėti klasterį. Kalbėsiu apie DoS atakas prieš klasterio valdymo elementus.
Kitas bendras dalykas, kurį paminėsiu, yra tai, ant ko aš visa tai išbandžiau, dėl ko tikrai galiu pasakyti, kad viskas veikia.
Kaip pagrindą laikome Kubernetes klasterio įdiegimu naudojant Kubespray. Jei kas nežino, tai iš tikrųjų yra Ansible vaidmenų rinkinys. Ją nuolat naudojame savo darbe. Geras dalykas yra tai, kad galite jį ridenti bet kur – galite suvynioti ant geležies gabalų arba kur nors į debesį. Vienas diegimo būdas iš esmės tinka viskam.
Šiame klasteryje turėsiu Kubernetes v1.14.5. Visas „Cube“ klasteris, kurį apsvarstysime, yra padalintas į vardų sritis, kiekviena vardų sritis priklauso atskirai komandai, o šios komandos nariai turi prieigą prie kiekvienos vardų erdvės. Jie negali eiti į skirtingas vardų erdves, tik į savo. Tačiau yra tam tikra administratoriaus paskyra, kuri turi teises į visą klasterį.
Pažadėjau, kad pirmas dalykas, kurį padarysime, tai gauti klasterio administratoriaus teises. Mums reikia specialiai paruoštos ankšties, kuri sulaužys Kubernetes klasterį. Viskas, ką turime padaryti, tai pritaikyti jį „Kubernetes“ klasteriui.
kubectl apply -f pod.yamlŠi ankštis pasieks vieną iš Kubernetes klasterio meistrų. Ir po to klasteris mielai grąžins mums failą, pavadintą admin.conf. Cube šiame faile saugomi visi administratoriaus sertifikatai ir tuo pačiu metu konfigūruojama klasterio API. Manau, kad taip lengva gauti administratoriaus prieigą prie 98% „Kubernetes“ grupių.
Pasikartosiu, šį rinkinį sukūrė vienas jūsų klasterio kūrėjas, turintis prieigą prie savo pasiūlymų įterpti į vieną nedidelę vardų erdvę. Visa tai sutvirtina RBAC. Jis neturėjo jokių teisių. Tačiau pažymėjimas buvo grąžintas.
O dabar apie specialiai paruoštą ankštį. Mes paleidžiame jį bet kuriame paveikslėlyje. Paimkime debian:jessie kaip pavyzdį.
Turime tokį dalyką:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Kas yra tolerancija? „Kubernetes“ klasterio meistrai paprastai pažymimi kažkuo, vadinamu „užtepimu“. Ir šios „infekcijos“ esmė yra ta, kad ankštys negali būti priskirtos pagrindiniams mazgams. Tačiau niekas nesivargina jokioje ankštyje nurodyti, kad ji yra tolerantiška „infekcijai“. Skyriuje „Toleravimas“ tiesiog rašoma, kad jei koks nors mazgas turi „NoSchedule“, tai mūsų mazgas yra tolerantiškas tokiai infekcijai – ir problemų nėra.
Be to, mes sakome, kad mūsų padas yra ne tik tolerantiškas, bet ir nori konkrečiai nusitaikyti į meistrą. Nes meistrai turi skaniausią mums reikalingą dalyką – visus sertifikatus. Todėl mes sakome nodeSelector – ir turime standartinę pagrindų etiketę, kuri leidžia iš visų klasterio mazgų pasirinkti būtent tuos mazgus, kurie yra pagrindiniai.
Su šiomis dviem sekcijomis jis tikrai ateis pas meistrą. Ir jam bus leista ten gyventi.
Bet mums vien ateiti pas meistrą neužtenka. Tai mums nieko neduos. Taigi toliau turime šiuos du dalykus:
hostNetwork: true
hostPID: true Nurodome, kad mūsų pod, kurį paleidžiame, bus branduolio vardų erdvėje, tinklo vardų erdvėje ir PID vardų srityje. Kai podas bus paleistas pagrindiniame kompiuteryje, jis galės matyti visas realias, tiesiogines šio mazgo sąsajas, klausytis viso srauto ir matyti visų procesų PID.
Tada tai smulkmenos. Paimk etcd ir skaityk ką nori.
Įdomiausia yra ši Kubernetes funkcija, kuri ten yra pagal nutylėjimą.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Ir jo esmė yra ta, kad galime pasakyti, kad mes paleidžiame, net neturėdami teisių į šį klasterį, kad norime sukurti hostPath tipo tomą. Tai reiškia, kad reikia pasirinkti kelią nuo pagrindinio kompiuterio, kuriame paleisime, ir priimti jį kaip garsą. Ir tada mes vadiname jį pavadinimu: šeimininkas. Visą šį pagrindinio kompiuterio kelią sumontuojame dėžutės viduje. Šiame pavyzdyje į /host katalogą.
Pakartosiu dar kartą. Mes liepėme priedai ateiti pas pagrindinį įrenginį, ten gauti pagrindinio kompiuterio tinklą ir pagrindinio kompiuterio PID ir įdėti visą pagrindinio pagrindinio įrenginio šaknį šiame podelyje.
Jūs suprantate, kad Debian'e veikia bash, o šis bash veikia root. Tai yra, mes ką tik gavome pagrindinį pagrindinį kompiuterį, neturėdami jokių teisių į Kubernetes klasterį.
Tada visa užduotis yra nueiti į pakatalogį /host /etc/kubernetes/pki, jei neklystu, ten pasiimti visus pagrindinius klasterio sertifikatus ir atitinkamai tapti klasterio administratoriumi.
Jei pažvelgsite taip, tai yra vienos pavojingiausių teisių į anketas – nepaisant to, kokias teises turi vartotojas:
Jei turiu teises paleisti bloką tam tikroje klasterio vardų erdvėje, tada ši grupė turi šias teises pagal numatytuosius nustatymus. Galiu paleisti privilegijuotus blokus, ir tai paprastai yra visos teisės, praktiškai šaknys mazge.
Mano mėgstamiausias yra Root vartotojas. Ir „Kubernetes“ turi šią parinktį „Run As Non-Root“. Tai apsaugos nuo įsilaužėlių tipas. Ar žinote, kas yra "Moldovos virusas"? Jei staiga tapote įsilaužėliu ir atėjote į mano „Kubernetes“ klasterį, mes, vargšai administratoriai, klausiame: „Prašome savo ankštuose nurodyti, su kuriais nulaužsite mano klasterį, paleiskite kaip ne root. Priešingu atveju atsitiks, kad procesą paleisite savo podyje po šaknimis, ir jums bus labai lengva mane nulaužti. Prašau apsisaugoti nuo savęs“.
Pagrindinio kompiuterio kelio apimtis, mano nuomone, yra greičiausias būdas gauti norimą rezultatą iš Kubernetes klasterio.
Bet ką su visu tuo daryti?
Bet kuris įprastas administratorius, susidūręs su Kubernetes, turėtų kilti mintis: „Taip, aš tau sakiau, kad Kubernetes neveikia. Jame yra skylių. Ir visas Kubas yra nesąmonė. Tiesą sakant, yra toks dalykas kaip dokumentacija, o jei pasižiūri, tai yra skyrius .
Tai yra „yaml“ objektas – jį galime sukurti „Kubernetes“ klasteryje, kuris kontroliuoja saugos aspektus konkrečiai antrijų aprašyme. Tai yra, iš tikrųjų jis valdo teises naudoti bet kokį pagrindinio kompiuterio tinklą, pagrindinio kompiuterio PID, tam tikrus tomo tipus, kurie yra paleidimo metu. Visa tai galima apibūdinti naudojant Pod Security Policy.
Įdomiausias „Pod“ saugos politikos dalykas yra tai, kad „Kubernetes“ klasteryje visi PSP diegimo programos nėra tiesiog niekaip neaprašyti, jie tiesiog yra išjungti pagal numatytuosius nustatymus. Pod saugos politika įjungta naudojant priėmimo papildinį.
Gerai, į klasterį įveskime Pod saugos politiką, tarkime, kad vardų erdvėje turime keletą paslaugų blokų, prie kurių prieigą turi tik administratoriai. Tarkime, visais kitais atvejais ankštys turi ribotas teises. Kadangi greičiausiai kūrėjams jūsų klasteryje nereikia paleisti privilegijuotųjų rinkinių.
Ir atrodo, kad pas mus viskas gerai. Ir mūsų „Kubernetes“ klasteris negali būti nulaužtas per dvi minutes.
Yra problema. Greičiausiai, jei turite Kubernetes klasterį, jūsų klasteryje įdiegtas stebėjimas. Netgi norėčiau nuspėti, kad jei jūsų klasteris turės stebėjimą, jis vadinsis Prometėjas.
Tai, ką aš jums pasakysiu, galios ir „Prometheus“ operatoriui, ir „Prometheus“, pristatomam gryna forma. Kyla klausimas, kad jei aš negaliu taip greitai gauti administratoriaus į klasterį, tai reiškia, kad turiu ieškoti daugiau. Ir aš galiu ieškoti jūsų stebėjimo pagalba.
Tikriausiai visi skaito tuos pačius straipsnius apie Habré, o stebėjimas yra stebėjimo vardų erdvėje. Vairo diagrama vadinama maždaug vienoda visiems. Spėju, kad jei įdiegsite stable/prometheus, gausite maždaug tuos pačius pavadinimus. Ir greičiausiai man net nereikės atspėti DNS pavadinimo jūsų klasteryje. Nes tai yra standartinė.
Toliau turime tam tikrą dev ns, kurioje galite paleisti tam tikrą podą. Ir tada iš šio podelio labai lengva padaryti kažką panašaus:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics yra vienas iš Prometheus eksportuotojų, kuris renka metrikas iš pačios Kubernetes API. Ten yra daug duomenų, kas veikia jūsų klasteryje, kas tai yra, kokių problemų turite su juo.
Kaip paprastas pavyzdys:
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
Pateikę paprastą garbanojimo užklausą iš neprivilegijuoto įrenginio, galite gauti šią informaciją. Jei nežinote, kokią Kubernetes versiją naudojate, ji lengvai jums pasakys.
O įdomiausia tai, kad be prieigos prie kube-state-metrics, taip pat galite lengvai pasiekti patį Prometheus tiesiogiai. Iš ten galite rinkti metrikas. Iš ten netgi galite kurti metrikas. Net teoriškai tokią užklausą galite sukurti iš Prometheus klasterio, kuris jį tiesiog išjungs. Ir jūsų stebėjimas nustos veikti iš klasterio.
Ir čia kyla klausimas, ar koks nors išorinis stebėjimas stebi jūsų stebėjimą. Ką tik gavau galimybę veikti Kubernetes klasteryje be jokių pasekmių sau. Net nesužinosite, kad aš ten dirbu, nes nebėra stebėjimo.
Kaip ir su PSP, atrodo, kad problema yra ta, kad visos šios išgalvotos technologijos – Kubernetes, Prometheus – tiesiog neveikia ir yra pilnos skylių. Ne visai.
Yra toks dalykas - .
Jei esate paprastas administratorius, greičiausiai žinote apie tinklo politiką, kad tai tik dar vienas yaml, kurio klasteryje jau yra daug. O kai kurių tinklo strategijų tikrai nereikia. Ir net jei perskaitėte, kas yra tinklo politika, kad tai yra Kubernetes yaml ugniasienė, leidžianti apriboti prieigos teises tarp vardų erdvių, tarp blokų, tada tikrai nusprendėte, kad Kubernetes yaml formato ugniasienė yra pagrįsta kitomis abstrakcijomis. ... Ne, ne. Tai tikrai nėra būtina.
Net jei nesakėte savo saugos specialistams, kad naudodami „Kubernetes“ galite sukurti labai paprastą ir paprastą užkardą, o tuo pačiu ir labai detalią. Jei jie to dar nežino ir jums netrukdo: „Na, duok, duok...“ Bet kokiu atveju jums reikia tinklo strategijos, kad užblokuotumėte prieigą prie kai kurių paslaugų vietų, kurias galima paimti iš jūsų klasterio. be jokio leidimo.
Kaip ir mano pateiktame pavyzdyje, galite gauti kube būsenos metriką iš bet kurios Kubernetes klasterio vardų srities neturėdami tam teisių. Tinklo politika uždarė prieigą iš visų kitų vardų sričių į stebėjimo vardų erdvę ir viskas: nėra prieigos, nėra problemų. Visose esamose diagramose, tiek standartiniame „Prometheus“, tiek „Prometheus“, esančiame operatoriuje, vairo reikšmėse yra tiesiog parinktis tiesiog įjungti joms tinklo politiką. Jums tereikia jį įjungti ir jie veiks.
Čia tikrai yra viena problema. Būdami įprastas barzdotas administratorius, greičiausiai nusprendėte, kad tinklo politika nereikalinga. Ir perskaitę įvairius straipsnius apie išteklius, tokius kaip Habras, nusprendėte, kad flanelė, ypač naudojant pagrindinio kompiuterio vartų režimą, yra geriausias dalykas, kurį galite pasirinkti.
Ką daryti?
Galite pabandyti iš naujo įdiegti tinklo sprendimą, kurį turite savo Kubernetes klasteryje, pabandykite jį pakeisti kažkuo funkcionalesniu. Pavyzdžiui, tam pačiam Calico. Tačiau iš karto noriu pasakyti, kad užduotis pakeisti tinklo sprendimą Kubernetes veikiančiame klasteryje yra gana nereikšminga. Aš tai išsprendžiau du kartus (bet abu kartus teoriškai), bet mes net parodėme, kaip tai padaryti Slurms. Savo studentams parodėme, kaip pakeisti tinklo sprendimą Kubernetes klasteryje. Iš esmės galite pabandyti įsitikinti, kad gamybos klasteryje nėra prastovų. Bet greičiausiai jums nepavyks.
O problema iš tikrųjų išspręsta labai paprastai. Klasteryje yra sertifikatai, ir jūs žinote, kad jūsų sertifikatai nustos galioti po metų. Na, o dažniausiai normalus sprendimas su sertifikatais klasteryje - kam nerimauti, šalia iškelsime naują klasterį, leisime senam supuvusi ir perdislokuoti viską. Tiesa, kai supuvus, teks sėdėti dieną, bet čia naujas klasteris.
Kai keliate naują klasterį, tuo pačiu metu vietoj flanelės įdėkite Calico.
Ką daryti, jei sertifikatai išduodami šimtui metų ir neketinate perskirstyti klasterio? Yra toks dalykas kaip Kube-RBAC-proxy. Tai labai šaunus patobulinimas, leidžiantis įterpti save kaip šoninės priekabos konteinerį į bet kurį „Kubernetes“ klasterio bloką. Ir tai iš tikrųjų prideda leidimą šiam rinkiniui per paties Kubernetes RBAC.
Yra viena problema. Anksčiau šis Kube-RBAC-Proxy sprendimas buvo integruotas į operatoriaus Prometheus. Bet tada jo nebeliko. Dabar šiuolaikinės versijos remiasi tuo, kad turite tinklo politiką ir uždarote ją naudodami jas. Ir todėl turėsime šiek tiek perrašyti diagramą. Tiesą sakant, jei einate į , yra pavyzdžių, kaip tai panaudoti kaip šonines priekabas, o diagramas teks perrašyti minimaliai.
Yra dar viena nedidelė problema. „Prometėjas“ nėra vienintelis, kuris pateikia savo rodiklius bet kam. Visi mūsų „Kubernetes“ klasterio komponentai taip pat gali grąžinti savo metrikas.
Tačiau, kaip jau sakiau, jei negalite pasiekti klasterio ir rinkti informacijos, galite padaryti bent šiek tiek žalos.
Taigi greitai parodysiu du būdus, kaip galima sugadinti Kubernetes klasterį.
Jus juoksitės, kai jums tai pasakysiu, tai du realūs atvejai.
Pirmasis metodas. Išteklių išeikvojimas.
Paleiskime dar vieną specialų podą. Jame bus tokia sekcija.
resources:
requests:
cpu: 4
memory: 4Gi Kaip žinote, užklausos yra procesoriaus ir atminties kiekis, rezervuotas pagrindiniame kompiuteryje tam tikriems blokams su užklausomis. Jei „Kubernetes“ klasteryje turime keturių branduolių pagrindinį kompiuterį ir keturi procesoriaus blokai atkeliauja į jį su užklausomis, tai reiškia, kad daugiau blokų su užklausomis negalės patekti į šį pagrindinį kompiuterį.
Jei paleisiu tokį bloką, paleisiu komandą:
$ kubectl scale special-pod --replicas=...Tada niekas kitas negalės dislokuoti Kubernetes klasteryje. Nes visi mazgai pritrūks užklausų. Taigi aš sustabdysiu jūsų „Kubernetes“ klasterį. Jei tai padarysiu vakare, galiu gana ilgam sustabdyti dislokavimą.
Jei dar kartą pažvelgsime į „Kubernetes“ dokumentaciją, pamatysime šį dalyką, vadinamą „Limit Range“. Jis nustato klasterio objektų išteklius. Galite parašyti Limit Range objektą yaml, pritaikyti jį tam tikroms vardų erdvėms – tada šioje vardų erdvėje galite pasakyti, kad turite numatytuosius, maksimalius ir minimalius išteklius ankštims.
Naudodami tokį dalyką, galime apriboti vartotojų galimybę konkrečiose komandų produktų vardų erdvėse nurodyti įvairius bjaurius dalykus savo anketose. Deja, net jei pasakysite vartotojui, kad jis negali paleisti rinkinių su užklausomis dėl daugiau nei vieno procesoriaus, yra tokia nuostabi mastelio komanda arba jie gali atlikti mastelį per prietaisų skydelį.
Ir štai iš kur atsiranda antrasis metodas. Paleidžiame 11 111 111 111 111 ankščių. Tai vienuolika milijardų. Taip yra ne todėl, kad sugalvojau tokį skaičių, o todėl, kad pats jį mačiau.
Tikra istorija. Vėlai vakare ruošiausi išeiti iš biuro. Matau grupę kūrėjų, sėdinčių kampe ir pašėlusiai kažką daro su savo nešiojamaisiais kompiuteriais. Prieinu prie vaikinų ir klausiu: „Kas tau atsitiko?
Kiek anksčiau, apie devintą vakaro, vienas kūrėjų ruošėsi namo. Ir nusprendžiau: „Dabar sumažinsiu savo paraišką iki vienos“. Paspaudžiau vieną, bet internetas šiek tiek sulėtėjo. Jis dar kartą paspaudė vieną, jis paspaudė vieną ir paspaudė Enter. Spustelėjau į viską, ką galėjau. Tada internetas atgijo – ir viskas ėmė mažėti iki šio skaičiaus.
Tiesa, ši istorija neįvyko Kubernetes, tuo metu tai buvo Nomad. Tai baigėsi tuo, kad po valandos mūsų bandymų sustabdyti Nomadą nuo atkaklių bandymų keisti mastelį, Nomadas atsakė, kad nesiliaus mastelio ir nieko daugiau nedarys. – Pavargau, išeinu. Ir jis susirangė.
Natūralu, kad tą patį bandžiau padaryti su Kubernetes. Kubernetesas nebuvo patenkintas vienuolika milijardų ankščių, jis sakė: „Aš negaliu. Pranoksta vidines burnos apsaugas. Bet 1 000 000 000 ankščių galėtų.
Atsakydamas į vieną milijardą, Kubas nepasitraukė į save. Jis tikrai pradėjo mažėti. Kuo toliau procesas vyko, tuo daugiau laiko jam prireikė naujų ankščių kūrimui. Tačiau procesas vis tiek tęsėsi. Vienintelė problema yra ta, kad jei galiu neribotai paleisti blokus savo vardų erdvėje, tai net be užklausų ir apribojimų galiu paleisti tiek daug podų su kai kuriomis užduotimis, kad šių užduočių pagalba mazgai pradės kauptis atmintyje, CPU. Kai paleidžiu tiek daug ankščių, informacija iš jų turėtų patekti į saugyklą, ty ir pan. Ir kai ten patenka per daug informacijos, saugykla pradeda grįžti per lėtai - ir Kubernetes pradeda nuobodu.
Ir dar viena problema... Kaip žinia, Kubernetes valdymo elementai yra ne vienas centrinis dalykas, o keli komponentai. Visų pirma, yra valdiklio vadybininkas, planuotojas ir pan. Visi šie vaikinai tuo pačiu metu pradės dirbti nereikalingą, kvailą darbą, kuris laikui bėgant ims užtrukti vis daugiau laiko. Valdiklio valdytojas sukurs naujus blokus. Planuoklis bandys rasti jiems naują mazgą. Greičiausiai greitai pritrūks naujų mazgų savo klasteryje. „Kubernetes“ klasteris pradės veikti vis lėčiau.
Bet nusprendžiau eiti dar toliau. Kaip žinote, Kubernetes yra toks dalykas, vadinamas paslauga. Na, pagal numatytuosius nustatymus jūsų klasteriuose greičiausiai paslauga veikia naudojant IP lenteles.
Pavyzdžiui, jei paleidžiate vieną milijardą rinkinių ir tada naudojate scenarijų, kad priverstumėte Kubernetis kurti naujas paslaugas:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Visuose klasterio mazguose maždaug vienu metu bus generuojama vis daugiau naujų iptables taisyklių. Be to, kiekvienai paslaugai bus sukurta milijardas iptables taisyklių.
Patikrinau visą tai kelis tūkstančius, iki dešimties. Ir bėda ta, kad jau esant šiam slenksčiui gana problemiška padaryti ssh mazgui. Nes paketai, perėję tiek daug grandinių, pradeda jaustis nelabai gerai.
Ir visa tai taip pat išspręsta Kubernetes pagalba. Yra toks Išteklių kvotos objektas. Nustato galimų išteklių ir objektų skaičių vardų srityje klasteryje. Kiekvienoje Kubernetes klasterio vardų erdvėje galime sukurti yaml objektą. Naudodami šį objektą galime pasakyti, kad šiai vardų erdvei paskirstome tam tikrą skaičių užklausų ir limitų, tada galime pasakyti, kad šioje vardų erdvėje galima sukurti 10 paslaugų ir 10 podų. O vienas kūrėjas bent jau gali užspringti vakarais. Kubernetesas jam pasakys: „Negalite padidinti savo ankšties iki tokios sumos, nes ištekliai viršija kvotą“. Štai ir viskas, problema išspręsta. .
Šiuo atžvilgiu iškyla vienas probleminis momentas. Jaučiate, kaip sunku sukurti vardų erdvę „Kubernetes“. Norėdami jį sukurti, turime atsižvelgti į daugybę dalykų.
Išteklių kvota + ribinis diapazonas + RBAC
• Sukurkite vardų erdvę
• Sukurkite ribą viduje
• Sukurti išteklių kvotos viduje
• Sukurkite CI paslaugų paskyrą
• Sukurti vaidmenų susiejimą CI ir vartotojams
• Pasirinktinai paleiskite reikiamus aptarnavimo blokus
Todėl norėčiau pasinaudoti proga ir pasidalinti savo pasiekimais. Yra toks dalykas, vadinamas SDK operatoriumi. Tai būdas Kubernetes klasteriui parašyti operatorius. Galite rašyti teiginius naudodami Ansible.
Iš pradžių buvo parašyta Ansible, o tada pamačiau, kad yra SDK operatorius ir perrašiau Ansible vaidmenį į operatorių. Šis teiginys leidžia sukurti objektą Kubernetes klasteryje, vadinamą komanda. Komandoje ji leidžia apibūdinti šios komandos aplinką yaml. O komandinėje aplinkoje tai leidžia apibūdinti, kad skiriame tiek daug išteklių.
Mažai .
Ir pabaigai. Ką su visu tuo daryti?
Pirmas. Pod saugos politika yra gera. Ir nepaisant to, kad nė vienas iš „Kubernetes“ montuotojų jų nenaudoja iki šiol, vis tiek turite juos naudoti savo grupėse.
Tinklo politika nėra tik dar viena nereikalinga funkcija. Tai yra tai, ko iš tikrųjų reikia klasteryje.
LimitRange/ResourceQuota – laikas ja pasinaudoti. Pradėjome naudoti jau seniai ir ilgą laiką buvau tikras, kad visi jį naudoja. Paaiškėjo, kad tai reta.
Be to, ką minėjau ataskaitoje, yra ir nedokumentuotų funkcijų, kurios leidžia atakuoti klasterį. Neseniai išleista .
Kai kurie dalykai yra tokie liūdni ir žeidžiantys. Pavyzdžiui, esant tam tikroms sąlygoms, Kubernetes klasteryje esantys kubeliai gali perduoti warlocks katalogo turinį neteisėtam vartotojui.
Yra instrukcijos, kaip atkurti viską, ką jums sakiau. Yra failų su gamybos pavyzdžiais, kaip atrodo ResourceQuota ir Pod saugos politika. Ir visa tai galite paliesti.
Ačiū jums visiems.
Šaltinis: www.habr.com