Pavel Selivanov, Southbridge-ratkaisujen arkkitehti ja Slurm-opettaja, piti esitelmän DevOpsConf 2019 -tapahtumassa. Tämä puhe on osa yhtä Kubernetesin “Slurm Mega” -syvyyskurssin aiheista.
järjestetään Moskovassa 18.-20. marraskuuta.
- Moskova, 22.-24. marraskuuta.
aina saatavilla.
Leikkauksen alla on kopio raportista.
Hyvää iltapäivää kollegat ja heille myötätuntoiset. Tänään puhun turvallisuudesta.
Näen, että salissa on tänään paljon vartijoita. Pahoittelen jo etukäteen, jos käytän turvallisuusmaailman termejä toisin kuin sinulle on tavallista.
Sattui niin, että noin puoli vuotta sitten törmäsin yhteen julkiseen Kubernetes-klusteriin. Julkinen tarkoittaa, että nimiavaruuksia on n:s määrä; näissä nimiavaruuksissa on nimiavaruudessaan eristettyjä käyttäjiä. Kaikki nämä käyttäjät kuuluvat eri yrityksiin. No, oletettiin, että tätä klusteria tulisi käyttää CDN:nä. Toisin sanoen he antavat sinulle klusterin, he antavat sinulle käyttäjän sinne, siirryt sinne nimiavaruuteen, otat käyttöön rintamasi.
Edellinen yritykseni yritti myydä tällaista palvelua. Ja minua pyydettiin näkemään klusteria nähdäkseni, oliko tämä ratkaisu sopiva vai ei.
Tulin tähän ryhmään. Minulle annettiin rajoitetut oikeudet, rajoitettu nimitila. Siellä olleet kaverit ymmärsivät mitä turvallisuus on. He lukivat roolipohjaisesta pääsynhallinnasta (RBAC) Kubernetesissa - ja he vääntelivät sitä niin, että en voinut käynnistää podeja erillään käyttöönotoista. En muista ongelmaa, jota yritin ratkaista käynnistämällä podin ilman käyttöönottoa, mutta halusin todella käynnistää vain podin. Onnea varten päätin katsoa, mitä oikeuksia minulla on klusterissa, mitä voin tehdä, mitä en voi tehdä ja mitä he ovat sotkeneet siellä. Samalla kerron sinulle, mitä he ovat määrittäneet väärin RBAC:ssa.
Kävi niin, että kahdessa minuutissa sain heidän klusteriinsa järjestelmänvalvojan, katsoin kaikki viereiset nimitilat, näin siellä palvelun jo ostaneiden ja käyttöönottaneiden yritysten tuotantorintamat. Pystyin tuskin pysäyttämään itseäni menemästä jonkun eteen ja laittamaan jotain kirosanaa pääsivulle.
Kerron sinulle esimerkkien avulla, kuinka tein tämän ja kuinka suojautua siltä.
Mutta ensin esittelen itseni. Nimeni on Pavel Selivanov. Olen arkkitehti Southbridgessä. Ymmärrän Kubernetesia, DevOpsia ja kaikenlaisia hienoja asioita. Southbridgen insinöörit ja minä rakennamme kaikkea tätä, ja minä neuvon.
Päätoimintojemme lisäksi olemme viime aikoina käynnistäneet projekteja nimeltä Slurms. Pyrimme tuomaan kykyämme työskennellä Kuberneteksen kanssa hieman massojen ulottuville, opettamaan muitakin työskentelemään K8:n kanssa.
Mistä puhun tänään? Raportin aihe on ilmeinen - Kubernetes-klusterin turvallisuudesta. Mutta haluan sanoa heti, että tämä aihe on erittäin laaja - ja siksi haluan heti selventää, mistä en varmasti puhu. En puhu hakkeroituista termeistä, joita on käytetty jo sata kertaa Internetissä. Kaikenlaiset RBAC ja sertifikaatit.
Puhun siitä, mikä minua ja kollegoitani vaivaa Kubernetes-klusterin tietoturvassa. Näemme nämä ongelmat sekä Kubernetes-klustereita tarjoavien palveluntarjoajien että meille tulevien asiakkaiden keskuudessa. Ja jopa asiakkailta, jotka tulevat meille muista konsulttihallinnointiyrityksistä. Toisin sanoen tragedian mittakaava on itse asiassa erittäin suuri.
Puhun kirjaimellisesti kolmesta asiasta tänään:
- Käyttäjäoikeudet vs. pod-oikeudet. Käyttäjäoikeudet ja pod-oikeudet eivät ole sama asia.
- Tietojen kerääminen klusterista. Näytän, että voit kerätä kaikki tarvitsemasi tiedot klusterista ilman erityisiä oikeuksia tähän klusteriin.
- DoS-hyökkäys klusteriin. Jos emme pysty keräämään tietoja, voimme joka tapauksessa perustaa klusterin. Puhun DoS-hyökkäyksistä klusterin ohjauselementtejä vastaan.
Toinen yleinen asia, jonka mainitsen, on se, millä testasin tätä kaikkea, jonka perusteella voin ehdottomasti sanoa, että kaikki toimii.
Otamme lähtökohtana Kubernetes-klusterin asennuksen Kubesprayllä. Jos joku ei tiedä, tämä on itse asiassa joukko Ansiblen rooleja. Käytämme sitä jatkuvasti työssämme. Hyvä asia on, että voit rullata sen missä tahansa - voit rullata sen raudanpaloille tai jonnekin pilveen. Yksi asennustapa toimii periaatteessa kaikkeen.
Tässä klusterissa minulla on Kubernetes v1.14.5. Koko Cube-klusteri, jota tarkastelemme, on jaettu nimiavaruuksiin, jokainen nimiavaruus kuuluu erilliselle tiimille, ja tämän tiimin jäsenillä on pääsy kuhunkin nimiavaruuteen. He eivät voi mennä eri nimiavaruuksiin, vain omiin nimiavaroihinsa. Mutta on olemassa tietty järjestelmänvalvojatili, jolla on oikeudet koko klusteriin.
Lupasin, että ensimmäinen asia, jonka teemme, on hankkia järjestelmänvalvojan oikeudet klusteriin. Tarvitsemme erityisesti valmistetun kotelon, joka rikkoo Kubernetes-klusterin. Meidän tarvitsee vain soveltaa sitä Kubernetes-klusteriin.
kubectl apply -f pod.yamlTämä pod saapuu yhdelle Kubernetes-klusterin mestarista. Ja tämän jälkeen klusteri palauttaa meille onneksi tiedoston nimeltä admin.conf. Cubessa tämä tiedosto tallentaa kaikki järjestelmänvalvojan varmenteet ja määrittää samalla klusterin API:n. Näin helppoa on saada järjestelmänvalvojan käyttöoikeus mielestäni 98 prosenttiin Kubernetes-klustereista.
Toistan, että tämän kotelon on tehnyt yksi klusterisi kehittäjä, jolla on pääsy ehdotuksiinsa yhteen pieneen nimiavaruuteen. RBAC sulkee sen kaiken. Hänellä ei ollut oikeuksia. Mutta siitä huolimatta todistus palautettiin.
Ja nyt erityisesti valmistetusta palosta. Suoritamme sen missä tahansa kuvassa. Otetaan esimerkkinä debian:jessie.
Meillä on tämä:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Mitä on suvaitsevaisuus? Kubernetes-klusterin mestarit on yleensä merkitty tahralla. Ja tämän "tartunnan" ydin on, että se sanoo, että paloja ei voida osoittaa pääsolmuille. Mutta kukaan ei vaivaudu osoittamaan missään kotelossa, että se sietää "infektiota". Toleraatio-osiossa sanotaan vain, että jos jollakin solmulla on NoSchedule, niin solmumme kestää tällaisen infektion - eikä ongelmia ole.
Lisäksi sanomme, että altamme ei ole vain suvaitsevainen, vaan haluaa myös kohdistaa nimenomaisesti mestarin. Koska mestareilla on herkullisin mitä tarvitsemme - kaikki todistukset. Siksi sanomme nodeSelector - ja meillä on vakionimike isännissä, jonka avulla voit valita kaikista klusterin solmuista täsmälleen ne solmut, jotka ovat isäntäsolmuja.
Näillä kahdella osalla hän tulee varmasti mestarin luo. Ja hän saa asua siellä.
Mutta pelkkä mestarin luokse tuleminen ei riitä meille. Tämä ei anna meille mitään. Joten seuraavaksi meillä on nämä kaksi asiaa:
hostNetwork: true
hostPID: true Määritämme, että käynnistämämme podimme asuu ytimen nimiavaruudessa, verkon nimiavaruudessa ja PID-nimiavaruudessa. Kun pod on käynnistetty isäntäkoneessa, se voi nähdä kaikki tämän solmun todelliset live-rajapinnat, kuunnella kaikkea liikennettä ja nähdä kaikkien prosessien PID-tunnukset.
Sitten on kyse pienistä asioista. Ota etcd ja lue mitä haluat.
Mielenkiintoisin asia on tämä Kubernetes-ominaisuus, joka on siellä oletuksena.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Ja sen ydin on, että voimme sanoa podissa, että käynnistämme, jopa ilman oikeuksia tähän klusteriin, että haluamme luoda hostPath-tyyppisen taltion. Tämä tarkoittaa polun ottamista isännältä, jolla käynnistämme - ja sen ottamista volyymiksi. Ja sitten kutsumme sitä nimellä: isäntä. Asennamme tämän koko isäntäpolun podin sisään. Tässä esimerkissä /host-hakemistoon.
Toistan sen uudelleen. Käskimme podin tulla isäntäkoneen luo, hankkia isäntäverkko ja isäntäPID sieltä - ja asentaa koko isäntäkoneen juuri tähän podiin.
Ymmärrät, että Debianissa bash on käynnissä, ja tämä bash toimii rootin alla. Toisin sanoen saimme juuri pääkoneen rootin ilman oikeuksia Kubernetes-klusteriin.
Sitten koko tehtävä on mennä alihakemistoon /host /etc/kubernetes/pki, jos en erehdy, poimia sieltä kaikki klusterin pääsertifikaatit ja ryhtyä vastaavasti klusterin ylläpitäjäksi.
Jos katsot asiaa tällä tavalla, nämä ovat eräitä vaarallisimmista oikeuksista podissa - riippumatta siitä, mitä oikeuksia käyttäjällä on:
Jos minulla on oikeudet ajaa podia jossain klusterin nimiavaruudessa, tällä podilla on nämä oikeudet oletusarvoisesti. Voin käyttää etuoikeutettuja podeja, ja nämä ovat yleensä kaikki oikeudet, käytännössä pääkäyttäjän oikeudet.
Suosikkini on Root-käyttäjä. Ja Kubernetesilla on tämä Run As Non-Root -vaihtoehto. Tämä on eräänlainen suoja hakkereilta. Tiedätkö mikä "Moldavian virus" on? Jos olet yhtäkkiä hakkeri ja tulet Kubernetes-klusteriini, niin me, huonot järjestelmänvalvojat, kysymme: "Ilmoita koteloihisi, millä aiot hakkeroida klusterini, ajaa ei-rootina. Muuten tapahtuu, että suoritat prosessin podissasi rootin alla, ja sinun on erittäin helppo hakkeroida minut. Ole hyvä ja suojele itseäsi itseltäsi."
Isäntäpolun volyymi on mielestäni nopein tapa saada haluttu tulos Kubernetes-klusterista.
Mutta mitä tehdä tämän kaiken kanssa?
Jokaisen Kubernetesin kohtaavan normaalin järjestelmänvalvojan pitäisi tulla mieleen: "Joo, sanoin sinulle, että Kubernetes ei toimi. Siinä on reikiä. Ja koko Kuutio on paskaa." Itse asiassa on olemassa sellainen asia kuin dokumentaatio, ja jos katsot siellä, siellä on osio .
Tämä on yaml-objekti - voimme luoda sen Kubernetes-klusterissa - joka ohjaa tietoturvanäkökohtia erityisesti podien kuvauksessa. Toisin sanoen se itse asiassa hallitsee oikeuksia käyttää mitä tahansa isäntäverkkoa, isäntäPID:tä ja tiettyjä taltiotyyppejä, jotka ovat koteloissa käynnistyksen yhteydessä. Pod Security Policyn avulla tämä kaikki voidaan kuvata.
Mielenkiintoisin asia Pod-tietoturvakäytännössä on, että Kubernetes-klusterissa kaikkia PSP-asentajia ei vain ole kuvattu millään tavalla, vaan ne on yksinkertaisesti oletuksena poistettu käytöstä. Pod Security Policy on otettu käyttöön sisäänpääsylaajennuksella.
Okei, otetaan käyttöön Pod-suojauskäytäntö klusteriin, sanotaan, että meillä on nimiavaruudessa joitain palvelutyyppejä, joihin vain järjestelmänvalvojilla on pääsy. Oletetaan, että kaikissa muissa tapauksissa podilla on rajoitetut oikeudet. Koska todennäköisimmin kehittäjien ei tarvitse käyttää etuoikeutettuja podeja klusterissasi.
Ja kaikki näyttää olevan meillä hyvin. Ja Kubernetes-klusteriamme ei voida hakkeroida kahdessa minuutissa.
On ongelma. Todennäköisesti, jos sinulla on Kubernetes-klusteri, valvonta on asennettu klusteriisi. Menisin jopa niin pitkälle, että ennustaisin, että jos klusterillasi on seurantaa, sitä kutsutaan Prometheukseksi.
Se, mitä aion kertoa, koskee sekä Prometheus-operaattoria että Prometheusta toimitettuna puhtaassa muodossaan. Kysymys kuuluu, että jos en saa järjestelmänvalvojaa klusteriin niin nopeasti, tämä tarkoittaa, että minun on etsittävä lisää. Ja voin etsiä seurantasi avulla.
Luultavasti kaikki lukevat samoja artikkeleita Habresta, ja seuranta sijaitsee seurannan nimiavaruudessa. Ruorikaaviota kutsutaan suunnilleen samaksi kaikille. Oletan, että jos teet ruoriasennuksen stable/prometheus, saat suunnilleen samat nimet. Ja todennäköisesti minun ei tarvitse edes arvata DNS-nimeä klusterissasi. Koska se on vakio.
Seuraavaksi meillä on tietty dev ns, jossa voit ajaa tietyn pod. Ja sitten tästä podista on erittäin helppo tehdä jotain tällaista:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics on yksi Prometheus-viejistä, joka kerää mittareita itse Kubernetes API:sta. Siellä on paljon dataa, mitä klusterissasi on käynnissä, mitä se on, mitä ongelmia sinulla on sen kanssa.
Yksinkertaisena esimerkkinä:
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
Tekemällä yksinkertaisen kiharapyynnön etuoikeutetusta kotelosta saat seuraavat tiedot. Jos et tiedä mitä Kubernetes-versiota käytät, se kertoo sinulle helposti.
Ja mielenkiintoisin asia on, että sen lisäksi, että pääset kube-state-metricsille, voit yhtä helposti käyttää itse Prometheusta suoraan. Sieltä voi kerätä mittareita. Voit jopa rakentaa mittareita sieltä. Jopa teoriassa voit rakentaa tällaisen kyselyn Prometheuksen klusterista, joka yksinkertaisesti sammuttaa sen. Ja valvontasi lakkaa toimimasta kokonaan klusterista.
Ja tässä herää kysymys, valvooko jokin ulkoinen valvonta seurantaasi. Sain juuri mahdollisuuden toimia Kubernetes-klusterissa ilman mitään seurauksia itselleni. Et edes tiedä, että toimin siellä, koska valvontaa ei enää ole.
Aivan kuten PSP:n kanssa, ongelma tuntuu olevan se, että kaikki nämä hienot tekniikat - Kubernetes, Prometheus - eivät vain toimi ja ovat täynnä reikiä. Ei oikeastaan.
On sellainen asia - .
Jos olet tavallinen järjestelmänvalvoja, tiedät todennäköisesti Network Policysta, että tämä on vain yksi yaml, jota klusterissa on jo paljon. Ja joitain verkkokäytäntöjä ei todellakaan tarvita. Ja vaikka lukisit mikä verkkokäytäntö on, että se on Kubernetesin yaml-palomuuri, sen avulla voit rajoittaa käyttöoikeuksia nimiavaruuksien välillä, podien välillä, niin päätit varmasti, että Kubernetesin yaml-muodossa oleva palomuuri perustuu seuraaviin abstraktioihin. ... Ei, ei. Tämä ei todellakaan ole välttämätöntä.
Vaikka et kertonut tietoturva-asiantuntijoillesi, että voit rakentaa Kubernetesin avulla erittäin helpon ja yksinkertaisen palomuurin, joka on erittäin rakeinen. Jos he eivät vielä tiedä tätä eivätkä häiritse sinua: "No, anna minulle, anna minulle..." Joka tapauksessa tarvitset verkkokäytännön estämään pääsyn joihinkin klusteristasi poistettaviin palvelupaikkoihin ilman mitään lupaa.
Kuten antamassani esimerkissä, voit hakea kube-tilamittareita mistä tahansa Kubernetes-klusterin nimiavaruudesta ilman oikeuksia tehdä niin. Verkkokäytännöt ovat sulkeneet pääsyn kaikista muista nimiavaruuksista tarkkailun nimiavaruuteen ja siinä kaikki: ei pääsyä, ei ongelmia. Kaikissa olemassa olevissa kaavioissa, sekä tavallisessa Prometheuksessa että operaattorissa olevassa Prometheuksessa, ruoriarvoissa on yksinkertaisesti vaihtoehto ottaa käyttöön verkkokäytännöt niille. Sinun tarvitsee vain kytkeä se päälle ja ne toimivat.
Tässä on todella yksi ongelma. Koska olet normaali parrakas järjestelmänvalvoja, päätit todennäköisesti, että verkkokäytäntöjä ei tarvita. Ja luettuasi kaikenlaisia resursseja, kuten Habria, koskevia artikkeleita, päätit, että flanelli, erityisesti isäntäyhdyskäytävätilassa, on paras vaihtoehto, jonka voit valita.
Mitä tehdä?
Voit yrittää ottaa käyttöön Kubernetes-klusterissasi olevan verkkoratkaisun uudelleen, yrittää korvata sen jollain toimivammalla. Esimerkiksi samalle Calicolle. Mutta haluan sanoa heti, että verkkoratkaisun muuttaminen Kubernetes-työklusterissa on melko ei-triviaali. Ratkaisin sen kahdesti (molemmat kerrat kuitenkin teoreettisesti), mutta osoitimme jopa kuinka se tehdään Slurmsissa. Opiskelijoillemme näytimme, kuinka verkkoratkaisua voidaan muuttaa Kubernetes-klusterissa. Periaatteessa voit yrittää varmistaa, että tuotantoklusterissa ei ole seisokkeja. Mutta et todennäköisesti onnistu.
Ja ongelma on itse asiassa ratkaistu hyvin yksinkertaisesti. Klusterissa on varmenteita, ja tiedät, että sertifikaattisi vanhenevat vuoden kuluttua. No, ja yleensä normaali ratkaisu, jossa on sertifikaatit klusterissa - miksi olemme huolissamme, nostamme uuden klusterin lähelle, annamme vanhan mennä mätä ja kohdistamme kaiken uudelleen. Totta, kun se menee mätä, meidän on istuttava päivä, mutta tässä on uusi klusteri.
Kun nostat uuden klusterin, aseta samalla Calico flanellin sijaan.
Mitä tehdä, jos sertifikaattisi on myönnetty sadaksi vuodeksi, etkä aio sijoittaa klusteria uudelleen? On olemassa sellainen asia kuin Kube-RBAC-välityspalvelin. Tämä on erittäin hieno kehitys, sen avulla voit upottaa itsensä sivuvaunusäiliöksi mihin tahansa Kubernetes-klusterin koteloon. Ja se itse asiassa lisää valtuutuksen tähän podiin itse Kubernetesin RBAC:n kautta.
On yksi ongelma. Aikaisemmin tämä Kube-RBAC-Proxy-ratkaisu oli sisäänrakennettu operaattorin Prometheukseen. Mutta sitten hän oli poissa. Nykyiset versiot luottavat nyt siihen, että sinulla on verkkokäytäntö ja suljet sen käyttämällä niitä. Ja siksi meidän on kirjoitettava kaaviota hieman uudelleen. Itse asiassa, jos menet , on esimerkkejä tämän käyttämisestä sivuvaunuina, ja kaavioita on kirjoitettava uudelleen minimaalisesti.
On vielä yksi pieni ongelma. Prometheus ei ole ainoa, joka jakaa mittareitaan kenelle tahansa. Kaikki Kubernetes-klusterikomponentimme voivat myös palauttaa omat mittarinsa.
Mutta kuten jo sanoin, jos et pääse käsiksi klusteriin ja kerää tietoja, voit ainakin tehdä jonkin verran haittaa.
Joten näytän nopeasti kaksi tapaa, kuinka Kubernetes-klusteri voidaan pilata.
Naurat, kun kerron sinulle tämän, nämä ovat kaksi tosielämän tapausta.
Menetelmä yksi. Resurssien ehtyminen.
Aloitetaan toinen erityinen pod. Siitä tulee tällainen osio.
resources:
requests:
cpu: 4
memory: 4Gi Kuten tiedät, pyynnöt ovat suorittimen ja muistin määrää, joka on varattu isännässä tietyille pyyntöjä sisältäville podille. Jos meillä on neljän ytimen isäntä Kubernetes-klusterissa ja sinne saapuu neljä CPU-podia pyyntöjen kanssa, se tarkoittaa, että tälle isännälle ei voi tulla enempää pyyntöjä sisältäviä podeja.
Jos käytän tällaista podia, suoritan komennon:
$ kubectl scale special-pod --replicas=...Silloin kukaan muu ei voi ottaa käyttöön Kubernetes-klusteria. Koska kaikki solmut loppuvat pyynnöistä. Ja siten pysäytän Kubernetes-klusterisi. Jos teen tämän illalla, voin pysäyttää käyttöönoton melko pitkäksi aikaa.
Jos katsomme uudelleen Kubernetes-dokumentaatiota, näemme tämän asian nimeltä Limit Range. Se asettaa resurssit klusteriobjekteille. Voit kirjoittaa Limit Range -objektin yamliin, soveltaa sitä tiettyihin nimiavaruuksiin - ja sitten tässä nimiavaruudessa voit sanoa, että sinulla on oletus-, enimmäis- ja vähimmäisresurssit podille.
Tällaisen asian avulla voimme rajoittaa tiettyjen tiimien tuotenimiavaruuksien käyttäjiä ilmoittamaan podeissaan kaikenlaisia ilkeitä asioita. Mutta valitettavasti, vaikka kertoisit käyttäjälle, että hän ei voi käynnistää podeja, joissa on pyyntöjä useammalle kuin yhdelle suorittimelle, on olemassa upea skaalauskomento, tai he voivat tehdä skaalauksen kojelaudan kautta.
Ja tästä menetelmä numero kaksi tulee. Tuomme markkinoille 11 111 111 111 111 koteloa. Se on yksitoista miljardia. Tämä ei johdu siitä, että keksin sellaisen numeron, vaan koska näin sen itse.
Tositarina. Myöhään illalla olin lähdössä toimistolta. Näen ryhmän kehittäjiä istuvan nurkassa tehden kiihkeästi jotain kannettavien tietokoneillaan. Menen poikien luo ja kysyn: "Mitä sinulle tapahtui?"
Hieman aikaisemmin, noin yhdeksän aikaan illalla, yksi kehittäjistä oli valmistautumassa kotiin. Ja päätin: "Myönnän nyt hakemukseni yhteen." Painoin yhtä, mutta Internet hidastui hieman. Hän painoi yhtä uudelleen, hän painoi yhtä ja napsauttaa Enter. Nauroin kaikkea mahdollista. Sitten Internet heräsi henkiin - ja kaikki alkoi skaalata tähän numeroon.
Totta, tämä tarina ei tapahtunut Kubernetesilla; tuolloin se oli Nomad. Se päättyi siihen, että tunnin yritettyämme estää Nomadin jatkuvista skaalausyrityksistä Nomad vastasi, ettei hän lopettaisi skaalaaminen eikä tekisi mitään muuta. "Olen väsynyt, lähden." Ja hän käpertyi.
Luonnollisesti yritin tehdä samaa Kubernetesissa. Kubernetes ei ollut tyytyväinen yhteentoista miljardiin koteloon, hän sanoi: "En voi. Ylittää sisäiset suunsuojat." Mutta 1 000 000 000 paloa voisi.
Vastauksena miljardiin kuutio ei vetäytynyt itseensä. Hän todella alkoi skaalata. Mitä pidemmälle prosessi eteni, sitä enemmän häneltä kesti aikaa luoda uusia paloja. Mutta prosessi jatkui silti. Ainoa ongelma on se, että jos voin käynnistää podeja rajattomasti nimiavaruudessani, niin voin jopa ilman pyyntöjä ja rajoituksia käynnistää joillakin tehtävillä niin monta podia, että näiden tehtävien avulla solmut alkavat summautua muistiin, prosessoriin. Kun käynnistän niin monta podia, niiden tietojen pitäisi mennä varastoon, eli jne. Ja kun sinne saapuu liikaa tietoa, tallennustila alkaa palata liian hitaasti - ja Kubernetes alkaa tylsistyä.
Ja vielä yksi ongelma... Kuten tiedät, Kubernetes-ohjauselementit eivät ole yksi keskeinen asia, vaan useita komponentteja. Erityisesti on olemassa ohjainpäällikkö, ajastin ja niin edelleen. Kaikki nämä kaverit alkavat tehdä turhaa, typerää työtä samanaikaisesti, mikä ajan myötä alkaa viedä enemmän ja enemmän aikaa. Ohjaimen johtaja luo uudet podit. Scheduler yrittää löytää heille uuden solmun. Todennäköisesti klusterisi uudet solmut loppuvat pian. Kubernetes-klusteri alkaa toimia hitaammin ja hitaammin.
Mutta päätin mennä vielä pidemmälle. Kuten tiedät, Kubernetesissa on sellainen asia, jota kutsutaan palveluksi. No, oletuksena klustereissasi palvelu toimii todennäköisesti IP-taulukoiden avulla.
Jos käytät esimerkiksi miljardia podia ja käytät sitten komentosarjaa pakottaaksesi Kubernetisin luomaan uusia palveluita:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Kaikissa klusterin solmuissa luodaan yhä enemmän uusia iptables-sääntöjä suunnilleen samanaikaisesti. Lisäksi jokaiselle palvelulle luodaan miljardi iptables-sääntöä.
Tarkistin tämän koko asian useista tuhansista, jopa kymmeneen. Ja ongelma on, että jo tällä kynnyksellä on melko ongelmallista tehdä ssh solmulle. Koska paketit, jotka käyvät läpi niin monia ketjuja, alkavat tuntua huonoilta.
Ja tämäkin on kaikki ratkaistu Kubernetesin avulla. On olemassa tällainen resurssikiintiöobjekti. Asettaa käytettävissä olevien resurssien ja objektien määrän klusterin nimiavaruuteen. Voimme luoda yaml-objektin jokaiseen Kubernetes-klusterin nimiavaruuteen. Tämän objektin avulla voimme sanoa, että tälle nimiavaruudelle on varattu tietty määrä pyyntöjä ja rajoituksia, ja sitten voidaan sanoa, että tähän nimiavaruuteen on mahdollista luoda 10 palvelua ja 10 podia. Ja yksi kehittäjä voi ainakin tukehtua iltaisin. Kubernetes kertoo hänelle: "Et voi skaalata palojasi tähän määrään, koska resurssi ylittää kiintiön." Siinä se, ongelma ratkaistu. .
Tässä suhteessa tulee esiin yksi ongelmallinen kohta. Tunnet kuinka vaikeaksi on tulossa nimitilan luominen Kubernetesissa. Sen luomiseksi meidän on otettava huomioon monet asiat.
Resurssikiintiö + raja + RBAC
• Luo nimiavaruus
• Luo sisälle raja-alue
• Luo resurssikiintiön sisällä
• Luo palvelutili CI:lle
• Luo roolisidonta CI:lle ja käyttäjille
• Valinnaisesti käynnistä tarvittavat huoltoyksiköt
Siksi haluan käyttää tilaisuutta hyväkseni jakaakseni kehitystäni. On olemassa sellainen asia, jota kutsutaan SDK-operaattoriksi. Tämä on tapa, jolla Kubernetes-klusteri voi kirjoittaa operaattoreita sille. Voit kirjoittaa lausuntoja käyttämällä Ansiblea.
Aluksi se kirjoitettiin Ansiblella, ja sitten huomasin, että siellä oli SDK-operaattori, ja kirjoitin Ansible-roolin uudelleen operaattoriksi. Tämän käskyn avulla voit luoda Kubernetes-klusteriin objektin, jota kutsutaan komennoksi. Komennon sisällä sen avulla voit kuvata tämän komennon ympäristön yamlissa. Ja tiimiympäristössä sen avulla voimme kuvata, että allokoimme niin paljon resursseja.
siro .
Ja lopuksi. Mitä tehdä tämän kaiken kanssa?
Ensimmäinen. Pod Security Policy on hyvä. Ja huolimatta siitä, että yksikään Kubernetes-asentaja ei käytä niitä tähän päivään mennessä, sinun on silti käytettävä niitä klustereissasi.
Verkkokäytäntö ei ole vain yksi tarpeeton ominaisuus. Tätä klusterissa todella tarvitaan.
LimitRange/ResourceQuota – on aika käyttää sitä. Aloitimme tämän käytön kauan sitten, ja olin pitkään varma, että kaikki käyttävät sitä. Kävi ilmi, että tämä on harvinaista.
Sen lisäksi, mitä mainitsin raportissa, on olemassa dokumentoimattomia ominaisuuksia, joiden avulla voit hyökätä klusteriin. Julkaistu äskettäin .
Jotkut asiat ovat niin surullisia ja loukkaavia. Esimerkiksi Kubernetes-klusterin kuutiot voivat tietyissä olosuhteissa antaa warlocks-hakemiston sisällön luvattomalle käyttäjälle.
Siellä on ohjeet kuinka toistaa kaikki, mitä sanoin. Siellä on tiedostoja, joissa on tuotantoesimerkkejä siitä, miltä ResourceQuota ja Pod Security Policy näyttävät. Ja voit koskettaa kaikkea tätä.
Kiitos kaikille.
Lähde: will.com