Pavel Selivanov, arkitekt i zgjidhjeve të Southbridge dhe mësues Slurm, dha një prezantim në DevOpsConf 2019. Ky diskutim është pjesë e një prej temave të kursit të thelluar mbi Kubernetes “Slurm Mega”.
zhvillohet në Moskë më 18-20 nëntor.
- Moskë, 22-24 nëntor.
gjithmonë në dispozicion.
Poshtë prerjes është një transkript i raportit.
Mirëdita, kolegë dhe ata që i simpatizojnë. Sot do të flas për sigurinë.
Shoh që sot në sallë ka shumë roje sigurie. Ju kërkoj falje paraprakisht nëse përdor terma nga bota e sigurisë jo tamam siç është zakon për ju.
Kështu ndodhi që rreth gjashtë muaj më parë hasa në një grup publik Kubernetes. Publik do të thotë që ka një numër të nëntë hapësirash emrash; në këto hapësira emrash ka përdorues të izoluar në hapësirën e tyre të emrave. Të gjithë këta përdorues i përkasin kompanive të ndryshme. Epo, supozohej se ky grup duhet të përdoret si CDN. Kjo do të thotë, ata ju japin një grup, ata ju japin një përdorues atje, ju shkoni atje në hapësirën tuaj të emrave, vendosni frontet tuaja.
Kompania ime e mëparshme u përpoq të shesë një shërbim të tillë. Dhe m'u kërkua të thes grupin për të parë nëse kjo zgjidhje ishte e përshtatshme apo jo.
Unë erdha në këtë grup. Më janë dhënë të drejta të kufizuara, hapësira e kufizuar e emrave. Djemtë atje e kuptuan se çfarë ishte siguria. Ata lexuan se çfarë është kontrolli i aksesit i bazuar në role (RBAC) në Kubernetes - dhe e shtrembëruan atë në mënyrë që unë të mos mund të nisja podet veçmas nga vendosjet. Nuk e mbaj mend problemin që po përpiqesha të zgjidhja duke nisur një pod pa vendosje, por me të vërtetë doja të nisja vetëm një pod. Për fat të mirë, vendosa të shoh se çfarë të drejtash kam në grup, çfarë mund të bëj, çfarë nuk mund të bëj dhe çfarë kanë prishur atje. Në të njëjtën kohë, unë do t'ju tregoj se çfarë kanë konfiguruar gabimisht në RBAC.
Ndodhi që brenda dy minutash mora një administrator në grupin e tyre, shikova të gjitha hapësirat e emrave fqinjë, pashë atje frontet e prodhimit të kompanive që kishin blerë tashmë shërbimin dhe kishin vendosur. Mezi e ndaloja veten që të shkoja në ballë të dikujt dhe të vendosja disa sharje në faqen kryesore.
Unë do t'ju tregoj me shembuj se si e bëra këtë dhe si të mbroheni nga kjo.
Por së pari, më lejoni të prezantohem. Emri im është Pavel Selivanov. Unë jam një arkitekt në Southbridge. Unë i kuptoj Kubernetes, DevOps dhe të gjitha llojet e gjërave të zbukuruara. Inxhinierët e Southbridge dhe unë po ndërtojmë të gjitha këto dhe jam duke u konsultuar.
Krahas aktiviteteve tona kryesore, së fundmi kemi lançuar projekte të quajtura Slurms. Ne po përpiqemi të sjellim aftësinë tonë për të punuar me Kubernetes pak te masat, për të mësuar njerëzit e tjerë të punojnë edhe me K8.
Për çfarë do të flas sot? Tema e raportit është e qartë - për sigurinë e grupit Kubernetes. Por dua të them menjëherë se kjo temë është shumë e madhe - dhe për këtë arsye dua të sqaroj menjëherë atë për të cilën nuk do të flas patjetër. Unë nuk do të flas për terma të hacked që janë përdorur tashmë njëqind herë në internet. Të gjitha llojet e RBAC dhe certifikatat.
Unë do të flas për atë që më dhemb mua dhe kolegët e mi për sigurinë në një grup Kubernetes. Ne i shohim këto probleme si midis ofruesve që ofrojnë grupe Kubernetes dhe midis klientëve që vijnë tek ne. Dhe madje edhe nga klientët që vijnë tek ne nga kompani të tjera të administrimit të konsulencës. Kjo do të thotë, shkalla e tragjedisë është në të vërtetë shumë e madhe.
Janë fjalë për fjalë tre pika për të cilat do të flas sot:
- Të drejtat e përdoruesit kundrejt të drejtave të pod. Të drejtat e përdoruesit dhe të drejtat e pod nuk janë e njëjta gjë.
- Mbledhja e informacionit rreth grupit. Unë do të tregoj se ju mund të mbledhni të gjithë informacionin që ju nevojitet nga një grup pa pasur të drejta të veçanta në këtë grup.
- Sulmi DoS në grup. Nëse nuk mund të mbledhim informacion, do të jemi në gjendje të vendosim një grup në çdo rast. Unë do të flas për sulmet DoS në elementët e kontrollit të grupimeve.
Një tjetër gjë e përgjithshme që do të përmend është ajo mbi të cilën e kam testuar të gjithë këtë, mbi të cilën mund të them patjetër se gjithçka funksionon.
Ne marrim si bazë instalimin e një grupi Kubernetes duke përdorur Kubespray. Nëse dikush nuk e di, ky është në fakt një grup rolesh për Ansible. Ne e përdorim vazhdimisht në punën tonë. E mira është se mund ta rrotulloni kudo - mund ta rrotulloni në copa hekuri ose në një re diku. Një metodë instalimi funksionon në parim për gjithçka.
Në këtë grup do të kem Kubernetes v1.14.5. I gjithë grupi i Kubeve, të cilin do ta shqyrtojmë, është i ndarë në hapësira emrash, secila hapësirë e emrave i përket një ekipi të veçantë dhe anëtarët e këtij ekipi kanë akses në secilën hapësirë emrash. Ata nuk mund të shkojnë në hapësira të ndryshme emrash, vetëm në hapësirat e tyre. Por ka një llogari të caktuar administratori që ka të drejta për të gjithë grupin.
Unë premtova se gjëja e parë që do të bëjmë është të marrim të drejtat e administratorit për grupin. Ne kemi nevojë për një pod të përgatitur posaçërisht që do të thyejë grupin Kubernetes. Gjithçka që duhet të bëjmë është ta zbatojmë atë në grupin Kubernetes.
kubectl apply -f pod.yamlKy pod do të arrijë te një nga zotërit e grupit Kubernetes. Dhe pas kësaj grupi do të na kthejë me kënaqësi një skedar të quajtur admin.conf. Në Cube, ky skedar ruan të gjitha certifikatat e administratorit dhe në të njëjtën kohë konfiguron API-në e grupit. Kjo është sa e lehtë është të fitosh akses administratori, mendoj, në 98% të grupimeve të Kubernetes.
E përsëris, kjo pod është krijuar nga një zhvillues në grupin tuaj, i cili ka akses për të vendosur propozimet e tij në një hapësirë të vogël emri, e gjitha është e lidhur nga RBAC. Nuk kishte të drejta. Por megjithatë certifikata iu kthye.
Dhe tani në lidhje me një pod të përgatitur posaçërisht. Ne e ekzekutojmë atë në çdo imazh. Le të marrim debian:jessie si shembull.
Ne kemi këtë gjë:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Çfarë është toleranca? Masters në një grup Kubernetes zakonisht shënohen me diçka që quhet njollë. Dhe thelbi i këtij "infeksioni" është se ai thotë se pods nuk mund të caktohen për nyjet master. Por askush nuk shqetësohet të tregojë në çdo pod se është tolerant ndaj "infeksionit". Seksioni Toleration thjesht thotë se nëse një nyje ka NoSchedule, atëherë nyja jonë është tolerante ndaj një infeksioni të tillë - dhe nuk ka probleme.
Më tej, themi se nën-ja jonë jo vetëm që është tolerante, por gjithashtu dëshiron të synojë në mënyrë specifike zotërinë. Sepse mjeshtrit kanë gjënë më të shijshme që na nevojitet - të gjitha certifikatat. Prandaj, ne themi nodeSelector - dhe kemi një etiketë standarde në master, e cila ju lejon të zgjidhni nga të gjitha nyjet në grup pikërisht ato nyje që janë master.
Me këto dy seksione ai patjetër do të vijë te mjeshtri. Dhe ai do të lejohet të jetojë atje.
Por vetëm ardhja te mjeshtri nuk na mjafton. Kjo nuk do të na japë asgjë. Pra, në vijim kemi këto dy gjëra:
hostNetwork: true
hostPID: true Ne specifikojmë që pod-i ynë, të cilin e lëshojmë, do të jetojë në hapësirën e emrave të kernelit, në hapësirën e emrave të rrjetit dhe në hapësirën e emrave PID. Pasi pod-i të lansohet në master, ai do të jetë në gjendje të shohë të gjitha ndërfaqet reale, të drejtpërdrejta të kësaj nyje, të dëgjojë të gjithë trafikun dhe të shohë PID-in e të gjitha proceseve.
Pastaj bëhet fjalë për gjëra të vogla. Merrni etcd dhe lexoni atë që dëshironi.
Gjëja më interesante është kjo veçori e Kubernetes, e cila është e pranishme atje si parazgjedhje.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Dhe thelbi i tij është se ne mund të themi në pod që ne lëshojmë, edhe pa të drejta për këtë grup, se duam të krijojmë një vëllim të tipit hostPath. Kjo do të thotë të marrim rrugën nga hosti në të cilin do të nisim - dhe ta marrim atë si vëllim. Dhe pastaj e quajmë emrin: host. Ne e montojmë të gjithë këtë hostPath brenda pod. Në këtë shembull, në drejtorinë /host.
Do ta përsëris përsëri. Ne i thamë podit të vinte te masteri, të merrte hostNetwork dhe hostPID atje - dhe të montoje të gjithë rrënjën e masterit brenda këtij pod.
Ju e kuptoni që në Debian kemi bash running, dhe ky bash shkon nën rrënjë. Kjo do të thotë, ne sapo morëm rrënjë në master, pa pasur asnjë të drejtë në grupin Kubernetes.
Atëherë e gjithë detyra është të shkoni në nëndrejtorinë /host /etc/kubernetes/pki, nëse nuk gabohem, merrni të gjitha certifikatat master të grupit atje dhe, në përputhje me rrethanat, bëhuni administratori i grupit.
Nëse e shikoni në këtë mënyrë, këto janë disa nga të drejtat më të rrezikshme në pods - pavarësisht se çfarë të drejtash ka përdoruesi:
Nëse kam të drejtat për të ekzekutuar një pod në disa hapësira emrash të grupit, atëherë ky pod i ka këto të drejta si parazgjedhje. Unë mund të ekzekutoj pods të privilegjuar, dhe këto janë përgjithësisht të gjitha të drejtat, praktikisht root në nyje.
I preferuari im është përdoruesi Root. Dhe Kubernetes ka këtë opsion Run As Non-Root. Ky është një lloj mbrojtjeje nga një haker. A e dini se çfarë është "virusi moldav"? Nëse befas jeni një haker dhe vini në grupin tim Kubernetes, atëherë ne, administratorë të varfër, pyesim: "Ju lutemi, tregoni në podet tuaja me të cilat do të hakoni grupin tim, ekzekutoni si jo-root. Përndryshe, do të ndodhë që ta kryeni procesin në podin tuaj nën rrënjë dhe do ta keni shumë të lehtë të më hakoni. Ju lutemi mbroni veten nga vetja”.
Vëllimi i rrugës së hostit është, për mendimin tim, mënyra më e shpejtë për të marrë rezultatin e dëshiruar nga një grup Kubernetes.
Por çfarë të bëhet me gjithë këtë?
Mendimi që duhet t'i vijë çdo administratori normal që has Kubernetes është: "Po, ju thashë, Kubernetes nuk funksionon. Ka vrima në të. Dhe i gjithë Kubi është marrëzi.” Në fakt, ekziston një gjë e tillë si dokumentacioni, dhe nëse shikoni atje, ka një seksion .
Ky është një objekt yaml - ne mund ta krijojmë atë në grupin Kubernetes - i cili kontrollon aspektet e sigurisë në mënyrë specifike në përshkrimin e pods. Kjo do të thotë, në fakt, ai kontrollon të drejtat për të përdorur çdo rrjet host, hostPID, lloje të caktuara vëllimi që janë në pods në fillim. Me ndihmën e Pod Security Policy, e gjithë kjo mund të përshkruhet.
Gjëja më interesante në lidhje me Politikën e Sigurisë Pod është se në grupin Kubernetes, të gjithë instaluesit e PSP jo thjesht nuk përshkruhen në asnjë mënyrë, ata thjesht janë çaktivizuar si parazgjedhje. Politika e sigurisë së pod është aktivizuar duke përdorur shtesën e pranimit.
Në rregull, le të vendosim Politikën e Sigurisë së Pod-it në grup, le të themi se kemi disa pods shërbimi në hapësirën e emrave, në të cilat vetëm administratorët kanë qasje. Le të themi, në të gjitha rastet e tjera, pods kanë të drejta të kufizuara. Sepse ka shumë të ngjarë që zhvilluesit nuk kanë nevojë të ekzekutojnë pods të privilegjuar në grupin tuaj.
Dhe gjithçka duket se është mirë me ne. Dhe grupi ynë Kubernetes nuk mund të hakerohet në dy minuta.
Ka një problem. Me shumë mundësi, nëse keni një grup Kubernetes, atëherë monitorimi është instaluar në grupin tuaj. Madje do të shkoja aq larg sa të parashikoja që nëse grupi juaj ka monitorim, ai do të quhet Prometheus.
Ajo që do t'ju tregoj do të jetë e vlefshme si për operatorin Prometheus ashtu edhe për Prometheun të dorëzuar në formën e tij të pastër. Pyetja është se nëse nuk mund të marr një administrator në grup kaq shpejt, atëherë kjo do të thotë që duhet të shikoj më shumë. Dhe unë mund të kërkoj me ndihmën e monitorimit tuaj.
Ndoshta të gjithë lexojnë të njëjtat artikuj në Habré, dhe monitorimi ndodhet në hapësirën e emrave të monitorimit. Grafiku i timonit quhet afërsisht i njëjtë për të gjithë. Unë jam me hamendje se nëse instaloni helmin stabil/prometheus, do të përfundoni me afërsisht të njëjtët emra. Dhe me shumë mundësi nuk do të më duhet as të hamend emrin e DNS në grupin tuaj. Sepse është standard.
Më pas kemi një ns të caktuar dev, në të cilën mund të ekzekutoni një pod të caktuar. Dhe pastaj nga ky pod është shumë e lehtë të bësh diçka të tillë:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics është një nga eksportuesit e Prometheus që mbledh metrikë nga vetë API Kubernetes. Ka shumë të dhëna atje, çfarë po funksionon në grupin tuaj, çfarë është, çfarë problemesh keni me të.
Si një shembull i thjeshtë:
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
Duke bërë një kërkesë të thjeshtë për kaçurrela nga një pod i paprivilegjuar, mund të merrni informacionin e mëposhtëm. Nëse nuk e dini se çfarë versioni të Kubernetes po përdorni, do t'ju tregojë lehtësisht.
Dhe gjëja më interesante është se përveç aksesit në kube-state-metrics, po aq lehtë mund të aksesoni drejtpërdrejt vetë Prometheun. Ju mund të mbledhni metrikë nga atje. Ju madje mund të ndërtoni metrikë nga atje. Edhe teorikisht, ju mund të ndërtoni një pyetje të tillë nga një grup në Prometheus, i cili thjesht do ta fikur atë. Dhe monitorimi juaj do të ndalojë së punuari nga grupi krejtësisht.
Dhe këtu lind pyetja nëse ndonjë monitorim i jashtëm monitoron monitorimin tuaj. Sapo mora mundësinë të operoj në një grup Kubernetes pa asnjë pasojë për veten time. Ju as nuk do ta dini që unë jam duke operuar atje, pasi nuk ka më asnjë monitorim.
Ashtu si me PSP-në, duket sikur problemi është se të gjitha këto teknologji të zbukuruara - Kubernetes, Prometheus - ato thjesht nuk funksionojnë dhe janë plot vrima. Jo ne te vertete.
Ka një gjë të tillë - .
Nëse jeni një administrator normal, atëherë ka shumë të ngjarë që ju e dini për Politikën e Rrjetit që kjo është vetëm një yaml tjetër, prej të cilave tashmë ka shumë prej tyre në grup. Dhe disa politika të rrjetit definitivisht nuk janë të nevojshme. Dhe edhe nëse lexoni se çfarë është Politika e Rrjetit, se është një mur zjarri yaml i Kubernetes, ju lejon të kufizoni të drejtat e hyrjes midis hapësirave të emrave, midis pods, atëherë me siguri keni vendosur që muri i zjarrit në format yaml në Kubernetes bazohet në abstraksionet e radhës ... Jo, jo. Kjo definitivisht nuk është e nevojshme.
Edhe nëse nuk i keni thënë specialistëve tuaj të sigurisë se duke përdorur Kubernetes-in tuaj, mund të ndërtoni një mur zjarri shumë të lehtë dhe të thjeshtë, dhe një shumë të grimcuar. Nëse ata nuk e dinë ende këtë dhe nuk ju shqetësojnë: "Epo, më jep, më jep..." Atëherë në çdo rast, ju duhet Politika e Rrjetit për të bllokuar hyrjen në disa vende shërbimi që mund të tërhiqen nga grupi juaj pa asnjë autorizim.
Ashtu si në shembullin që dhashë, ju mund të tërhiqni matjet e gjendjes kube nga çdo hapësirë emri në grupimin Kubernetes pa pasur asnjë të drejtë për ta bërë këtë. Politikat e rrjetit kanë akses të mbyllur nga të gjitha hapësirat e tjera të emrave në hapësirën e emrave të monitorimit dhe kaq: pa akses, pa probleme. Në të gjitha grafikët që ekzistojnë, si Prometheus standard ashtu edhe Prometheus që është në operator, ka thjesht një opsion në vlerat e timonit për të aktivizuar thjesht politikat e rrjetit për ta. Thjesht duhet ta ndizni dhe ata do të funksionojnë.
Këtu ka vërtet një problem. Duke qenë një administrator normal me mjekër, me shumë mundësi keni vendosur që politikat e rrjetit nuk janë të nevojshme. Dhe pasi keni lexuar të gjitha llojet e artikujve mbi burimet si Habr, keni vendosur që fanella, veçanërisht me modalitetin host-gateway, është gjëja më e mirë që mund të zgjidhni.
Çfarë duhet të bëni?
Mund të provoni të rishpërndani zgjidhjen e rrjetit që keni në grupin tuaj Kubernetes, përpiquni ta zëvendësoni atë me diçka më funksionale. Për të njëjtin Calico, për shembull. Por dua të them menjëherë se detyra e ndryshimit të zgjidhjes së rrjetit në një grup pune Kubernetes është mjaft jo e parëndësishme. E zgjidha dy herë (të dyja herët, megjithatë, teorikisht), por madje treguam se si ta bëjmë atë në Slurms. Për studentët tanë, ne treguam se si të ndryshoni zgjidhjen e rrjetit në një grupim Kubernetes. Në parim, mund të përpiqeni të siguroheni që të mos ketë kohë joproduktive në grupin e prodhimit. Por ndoshta nuk do të keni sukses.
Dhe problemi në fakt zgjidhet shumë thjeshtë. Ka certifikata në grup, dhe ju e dini që certifikatat tuaja do të skadojnë brenda një viti. Epo, dhe zakonisht një zgjidhje normale me certifikata në grup - pse po shqetësohemi, do të ngremë një grup të ri aty pranë, do ta lëmë të vjetrin të kalbet dhe do të rishpërndajmë gjithçka. Vërtetë, kur të kalbet, do të duhet të ulemi për një ditë, por këtu është një grup i ri.
Kur ngrini një grup të ri, në të njëjtën kohë futni Calico në vend të fanellës.
Çfarë duhet të bëni nëse certifikatat tuaja lëshohen për njëqind vjet dhe nuk do të rishpërndani grupin? Ekziston një gjë e tillë si Kube-RBAC-Proxy. Ky është një zhvillim shumë i lezetshëm, ai ju lejon të futni veten si një enë anësore në çdo pod në grupin Kubernetes. Dhe në fakt shton autorizim në këtë pod përmes vetë RBAC të Kubernetes.
Ka një problem. Më parë, kjo zgjidhje Kube-RBAC-Proxy ishte ndërtuar në Prometheus të operatorit. Por më pas ai ishte zhdukur. Tani versionet moderne mbështeten në faktin se ju keni një politikë rrjeti dhe e mbyllni atë duke përdorur ato. Dhe për këtë arsye ne do të duhet të rishkruajmë pak grafikun. Në fakt, nëse shkoni në , ka shembuj se si të përdoret kjo si karrige anësore, dhe grafikët do të duhet të rishkruhen minimalisht.
Ka edhe një problem të vogël. Prometeu nuk është i vetmi që ia shpërndan metrikat e tij kujtdo. Të gjithë përbërësit tanë të grupimit Kubernetes janë gjithashtu në gjendje të kthejnë metrikat e tyre.
Por siç thashë tashmë, nëse nuk mund të hyni në grup dhe të mbledhni informacion, atëherë të paktën mund të bëni një dëm.
Kështu që unë do të tregoj shpejt dy mënyra se si mund të shkatërrohet një grup Kubernetes.
Do të qeshni kur t'ju them këtë, këto janë dy raste reale.
Metoda e parë. Shkarkimi i burimeve.
Le të hapim një tjetër pod special. Do të ketë një seksion të tillë.
resources:
requests:
cpu: 4
memory: 4Gi Siç e dini, kërkesat është sasia e CPU-së dhe memories që është e rezervuar në host për pods specifike me kërkesa. Nëse kemi një host me katër bërthama në një grup Kubernetes, dhe katër pods CPU mbërrijnë atje me kërkesa, do të thotë që asnjë tjetër pod me kërkesa nuk do të mund të vijë te ky host.
Nëse drejtoj një pod të tillë, atëherë do të ekzekutoj komandën:
$ kubectl scale special-pod --replicas=...Atëherë askush tjetër nuk do të jetë në gjendje të vendoset në grupin Kubernetes. Sepse të gjitha nyjet do të mbarojnë kërkesat. Dhe kështu unë do të ndaloj grupin tuaj Kubernetes. Nëse e bëj këtë në mbrëmje, mund të ndaloj vendosjet për një kohë mjaft të gjatë.
Nëse shikojmë përsëri dokumentacionin e Kubernetes, do të shohim këtë gjë të quajtur Limit Range. Ai përcakton burimet për objektet e grupimit. Ju mund të shkruani një objekt Limit Range në yaml, ta aplikoni atë në hapësira të caktuara emrash - dhe më pas në këtë hapësirë të emrave mund të thoni se keni burime të paracaktuar, maksimale dhe minimale për pods.
Me ndihmën e një gjëje të tillë, ne mund të kufizojmë përdoruesit në hapësirat e emrave të produkteve specifike të ekipeve në aftësinë për të treguar të gjitha llojet e gjërave të këqija në grupet e tyre. Por për fat të keq, edhe nëse i thoni përdoruesit se nuk mund të lëshojnë pods me kërkesa për më shumë se një CPU, ekziston një komandë kaq e mrekullueshme e shkallës, ose ata mund të bëjnë shkallë përmes pultit.
Dhe këtu vjen metoda numër dy. Ne lëshojmë 11 pods. Kjo është njëmbëdhjetë miliardë. Kjo nuk ndodh sepse kam ardhur me një numër të tillë, por sepse e kam parë vetë.
Histori e vërtetë. Vonë në mbrëmje isha gati të largohesha nga zyra. Unë shoh një grup zhvilluesish të ulur në qoshe, të furishëm duke bërë diçka me laptopët e tyre. Shkoj te djemtë dhe pyes: "Çfarë ndodhi me ju?"
Pak më herët, rreth orës nëntë të mbrëmjes, një nga zhvilluesit po bëhej gati të shkonte në shtëpi. Dhe vendosa: "Tani do ta zmadhoj aplikimin tim në një." Shtypa një, por interneti u ngadalësua pak. Ai shtypi përsëri një, ai shtypi një dhe kliko Enter. Unë godita gjithçka që munda. Pastaj interneti erdhi në jetë - dhe gjithçka filloi të zvogëlohej në këtë numër.
Vërtetë, kjo histori nuk u zhvillua në Kubernetes; në atë kohë ishte Nomad. Përfundoi me faktin se pas një ore përpjekjesh tona për të ndaluar Nomadin nga përpjekjet e vazhdueshme për të shkallëzuar, Nomad u përgjigj se ai nuk do të ndalonte shkallëzimin dhe nuk do të bënte asgjë tjetër. “Jam i lodhur, po largohem”. Dhe ai u përkul.
Natyrisht, u përpoqa të bëja të njëjtën gjë në Kubernetes. Kubernetes nuk ishte i kënaqur me njëmbëdhjetë miliardë pods, ai tha: "Nuk mundem. I tejkalon mbrojtjen e brendshme të gojës." Por 1 bishtaja mund.
Në përgjigje të një miliardi, Kubi nuk u tërhoq në vetvete. Ai me të vërtetë filloi të shkallëzohej. Sa më tej shkonte procesi, aq më shumë kohë i duhej atij për të krijuar pods të rinj. Por ende procesi vazhdoi. Problemi i vetëm është se nëse mund të lëshoj pods pa kufi në hapësirën time të emrave, atëherë edhe pa kërkesa dhe kufizime mund të lëshoj aq shumë pods me disa detyra sa që me ndihmën e këtyre detyrave nyjet do të fillojnë të shtohen në memorie, në CPU. Kur lëshoj kaq shumë pods, informacioni prej tyre duhet të shkojë në ruajtje, domethënë, etj. Dhe kur shumë informacion mbërrijnë atje, ruajtja fillon të kthehet shumë ngadalë - dhe Kubernetes fillon të bëhet i mërzitshëm.
Dhe një problem tjetër... Siç e dini, elementët e kontrollit Kubernetes nuk janë një gjë qendrore, por disa komponentë. Në veçanti, ekziston një menaxher kontrollues, planifikues, etj. Të gjithë këta djem do të fillojnë të bëjnë punë të panevojshme, marrëzi në të njëjtën kohë, të cilat me kalimin e kohës do të fillojnë të marrin gjithnjë e më shumë kohë. Menaxheri i kontrolluesit do të krijojë pods të rinj. Scheduler do të përpiqet të gjejë një nyje të re për ta. Me shumë mundësi, së shpejti do t'ju mbarojnë nyjet e reja në grupin tuaj. Grupi Kubernetes do të fillojë të funksionojë gjithnjë e më ngadalë.
Por vendosa të shkoj edhe më tej. Siç e dini, në Kubernetes ekziston një gjë e tillë që quhet shërbim. Epo, si parazgjedhje në grupimet tuaja, ka shumë të ngjarë, shërbimi funksionon duke përdorur tabela IP.
Nëse përdorni një miliard pods, për shembull, dhe më pas përdorni një skript për të detyruar Kubernetis të krijojë shërbime të reja:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Në të gjitha nyjet e grupit, gjithnjë e më shumë rregulla të reja iptables do të gjenerohen përafërsisht njëkohësisht. Për më tepër, një miliard rregulla iptables do të gjenerohen për çdo shërbim.
E kontrollova të gjithë këtë gjë në disa mijëra, deri në dhjetë. Dhe problemi është se tashmë në këtë prag është mjaft problematike të bësh ssh në nyje. Sepse paketat, duke kaluar nëpër kaq shumë zinxhirë, fillojnë të ndihen jo shumë mirë.
Dhe kjo, gjithashtu, zgjidhet e gjitha me ndihmën e Kubernetes. Ekziston një objekt i kuotës së Burimeve. Vendos numrin e burimeve dhe objekteve të disponueshme për hapësirën e emrave në grup. Ne mund të krijojmë një objekt yaml në çdo hapësirë emri të grupit Kubernetes. Duke përdorur këtë objekt, mund të themi se kemi një numër të caktuar kërkesash dhe limitesh të alokuara për këtë hapësirë emrash, dhe më pas mund të themi se në këtë hapësirë emrash është e mundur të krijohen 10 shërbime dhe 10 pods. Dhe një zhvillues i vetëm mund të paktën të mbyt veten në mbrëmje. Kubernetes do t'i thotë atij: "Ju nuk mund t'i përmasoni grupet tuaja në atë shumë, sepse burimi e tejkalon kuotën." Kjo është ajo, problemi u zgjidh. .
Një pikë problematike lind në këtë drejtim. Ju ndjeni se sa e vështirë po bëhet krijimi i një hapësire emri në Kubernetes. Për ta krijuar atë, duhet të marrim parasysh shumë gjëra.
Kuota e burimeve + Gama kufitare + RBAC
• Krijoni një hapësirë emri
• Krijoni një kufi brenda
• Krijoni kuotën e burimeve brenda
• Krijoni një llogari shërbimi për CI
• Krijoni lidhjen e roleve për CI dhe përdoruesit
• Hapni opsionalisht podet e nevojshme të shërbimit
Prandaj, do të doja të përfitoj nga ky rast për të ndarë zhvillimet e mia. Ekziston një gjë e tillë që quhet operatori SDK. Kjo është një mënyrë për një grup Kubernetes për të shkruar operatorë për të. Ju mund të shkruani deklarata duke përdorur Ansible.
Në fillim ishte shkruar në Ansible, dhe më pas pashë që kishte një operator SDK dhe rishkrova rolin Ansible në një operator. Kjo deklaratë ju lejon të krijoni një objekt në grupin Kubernetes të quajtur një komandë. Brenda një komande, ju lejon të përshkruani mjedisin për këtë komandë në yaml. Dhe brenda mjedisit të ekipit, na lejon të përshkruajmë se po shpërndajmë kaq shumë burime.
i imët .
Dhe në përfundim. Çfarë duhet bërë me gjithë këtë?
Së pari. Politika e sigurisë së pod është e mirë. Dhe përkundër faktit se asnjë nga instaluesit e Kubernetes nuk i përdor ato deri më sot, ju ende duhet t'i përdorni ato në grupimet tuaja.
Politika e Rrjetit nuk është vetëm një veçori tjetër e panevojshme. Kjo është ajo që vërtet nevojitet në një grup.
LimitRange/ResourceQuota - është koha për ta përdorur atë. Ne kemi filluar ta përdorim këtë shumë kohë më parë, dhe për një kohë të gjatë isha i sigurt se të gjithë po e përdornin. Doli se kjo është e rrallë.
Përveç asaj që përmenda gjatë raportit, ka veçori të padokumentuara që ju lejojnë të sulmoni grupin. Lëshuar së fundmi .
Disa gjëra janë kaq të trishtueshme dhe lënduese. Për shembull, në kushte të caktuara, cubelets në një grup Kubernetes mund t'i japin përmbajtjen e drejtorisë warlocks një përdoruesi të paautorizuar.
Ka udhëzime se si të riprodhoni gjithçka që ju thashë. Ka skedarë me shembuj prodhimi se si duken ResourceQuota dhe Pod Security Policy. Dhe ju mund të prekni të gjitha këto.
Faleminderit të gjithëve.
Burimi: www.habr.com