Pavel Selivanovek, Southbridge soluzioen arkitektoak eta Slurm irakasleak, aurkezpena egin zuen DevOpsConf 2019-n. Hitzaldi hau Kubernetes "Slurm Mega"-ri buruzko ikastaro sakoneko gaietako baten parte da.
Moskun ospatuko da azaroaren 18tik 20ra.
— Mosku, azaroaren 22tik 24ra.
beti eskuragarri.
Ebakiaren azpian txostenaren transkripzioa dago.
Arratsaldeon, lankideok eta haiekin bat egiten dutenok. Gaur segurtasunari buruz hitz egingo dut.
Ikusten dut gaur aretoan segurtasun zaindari asko daudela. Barkamena eskatzen dizut aldez aurretik segurtasun-munduko terminoak zuretzako ohikoak ez diren bezala erabiltzen baditut.
Gertatu zen duela sei hilabete inguru Kubernetes kluster publiko batekin topo egin nuela. Publikoak esan nahi du izen-eremu kopuru engarren bat dagoela; izen-espazio horietan erabiltzaileak daude beren izen-espazioan isolatuta. Erabiltzaile hauek guztiak enpresa ezberdinetakoak dira. Bada, kluster hau CDN gisa erabili behar zela suposatu zen. Hau da, cluster bat ematen dizute, hor erabiltzaile bat ematen dizute, hara joaten zara zure izen-espaziora, zure fronteak zabaldu.
Nire aurreko enpresa horrelako zerbitzu bat saltzen saiatu zen. Eta klusterra botatzeko eskatu zidaten irtenbide hau egokia zen edo ez ikusteko.
Multzo honetara etorri naiz. Eskubide mugatuak eman zizkidaten, izen-espazio mugatua. Han zeuden mutilek ulertu zuten zer zen segurtasuna. Rolean oinarritutako sarbide-kontrola (RBAC) irakurri zuten Kubernetes-en, eta bihurritu egin zuten, inplementazioetatik bereizita abiarazi ahal izateko. Ez dut gogoan konpontzen saiatzen ari nintzen arazoa inplementatu gabe pod bat abiaraziz, baina benetan pod bat besterik ez abiarazi nahi nuen. Zorte onerako, klusterrean zer eskubide ditudan, zer egin dezakedan, zer ezin dudan eta zer izorratu duten hor ikustea erabaki nuen. Aldi berean, RBACen gaizki konfiguratu dutena esango dizut.
Gertatu zen bi minuturen buruan haien klusterreko administratzaile bat jaso nuen, aldameneko izen-espazio guztiak begiratu nituela, han ikusi nuela zerbitzua dagoeneko erosi eta zabalduta zuten enpresen ekoizpen-fronteak martxan. Ozta-ozta gelditu nintzen inoren aurrealdera joatea eta orri nagusian txarto batzuk jartzea.
Adibideekin esango dizut nola egin nuen hau eta nola babestu honetatik.
Baina lehenik eta behin, utz iezadazu nire burua aurkezten. Nire izena Pavel Selivanov da. Southbridgen arkitektoa naiz. Kubernetes, DevOps eta era guztietako gauza dotoreak ulertzen ditut. Southbridge ingeniariak eta biok hau guztia eraikitzen ari gara, eta ni aholkularitza egiten ari naiz.
Gure jarduera nagusiez gain, Slurms izeneko proiektuak martxan jarri berri ditugu. Saiatzen ari gara Kubernetesekin lan egiteko dugun gaitasuna jendearengana apur bat ekartzen, beste jendeari K8ekin ere lan egiten irakasten.
Zertaz hitz egingo dut gaur? Txostenaren gaia begien bistakoa da: Kubernetes klusterraren segurtasunari buruzkoa. Baina berehala esan nahi dut gai hau oso zabala dela - eta, beraz, berehala argitu nahi dut zertaz hitz egingo ez dudan zalantzarik gabe. Ez dut hitz egingo Interneten dagoeneko ehun aldiz erabili izan diren termino txukunez. Era guztietako RBAC eta ziurtagiriak.
Kubernetes kluster batean segurtasunari buruz niri eta nire lankideei min ematen dienari buruz hitz egingo dut. Arazo hauek ikusten ditugu bai Kubernetes klusterrak eskaintzen dituzten hornitzaileen artean, bai guregana etortzen diren bezeroen artean. Eta baita beste aholkularitza-administrazio-enpresa batzuetatik etortzen zaizkigun bezeroetatik ere. Hau da, tragediaren tamaina benetan oso handia da.
Gaur hitz egingo dudan hiru puntu daude literalki:
- Erabiltzaile eskubideak vs pod eskubideak. Erabiltzaile eskubideak eta pod eskubideak ez dira gauza bera.
- Klusterraren inguruko informazioa biltzea. Erakutsiko dut kluster batetik behar duzun informazio guztia bil dezakezula kluster honetan eskubide berezirik izan gabe.
- DoS klusterren aurkako erasoa. Ezin badugu informazioa bildu, edozein kasutan kluster bat jarri ahal izango dugu. Klusterren kontroleko elementuen DoS erasoei buruz hitz egingo dut.
Aipatuko dudan beste gauza orokor bat hau guztia probatu dudana da, eta horrek guztiak funtzionatzen duela esan dezaket zalantzarik gabe.
Kubespray erabiliz Kubernetes kluster baten instalazioa hartzen dugu oinarri. Inork ez badu ezagutzen, hau benetan Ansibleren rol multzo bat da. Gure lanean etengabe erabiltzen dugu. Gauza ona da edonondik jaurti dezakezula - burdin zatietan edo hodei batean sartu dezakezula. Instalazio-metodo batek printzipioz denetarako balio du.
Kluster honetan Kubernetes v1.14.5 izango dut. Kontuan hartuko dugun Cube kluster osoa izen-espazioetan banatuta dago, izen-espazio bakoitza talde ezberdin batekoa da eta talde honetako kideek izen-espazio bakoitzerako sarbidea dute. Ezin dira izen-espazio ezberdinetara joan, eurenera bakarrik. Baina bada administratzaile kontu jakin bat kluster osorako eskubideak dituena.
Egingo dugun lehenengo gauza klusterraren administratzaile eskubideak lortzea izango dela agindu nion. Kubernetes klusterra apurtuko duen espresuki prestatutako pod bat behar dugu. Egin behar duguna da Kubernetes klusterrean aplikatzea.
kubectl apply -f pod.yamlPod hau Kubernetes klusterreko maisuetako bati helduko zaio. Eta honen ondoren klusterrak pozik itzuliko digu admin.conf izeneko fitxategia. Cube-n, fitxategi honek administratzaile-ziurtagiri guztiak gordetzen ditu eta, aldi berean, kluster APIa konfiguratzen du. Hau da, nire ustez, Kubernetes klusterren % 98 administratzailearen sarbidea lortzea zein erraza den.
Berriro diot, pod hau zure klusterreko garatzaile batek egin zuen, bere proposamenak izen-espazio txiki batean zabaltzeko sarbidea daukana, RBAC-ek finkatuta dago. Ez zuen eskubiderik. Baina, hala ere, ziurtagiria itzuli zen.
Eta orain bereziki prestatutako leka bati buruz. Edozein iruditan exekutatzen dugu. Har dezagun adibide gisa debian:jessie.
Gauza hau dugu:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Zer da tolerantzia? Kubernetes kluster bateko maisuak kutsadura izeneko zerbaitekin markatu ohi dira. Eta "infekzio" honen funtsa zera da, lekak ezin direla nodo nagusiei esleitu. Baina inor ez da kezkatzen inongo leketan "infekzioarekiko" tolerantea dela adierazteko. Tolerantzia atalak dio nodoren batek NoSchedule badu, gure nodoak horrelako infekzioekiko tolerantzia duela eta ez dagoela arazorik.
Gainera, gure azpia tolerantea ez ezik, maisuari berariaz zuzendu nahi zaiola esaten dugu. Maisuek behar dugun gauza goxoena baitute: ziurtagiri guztiak. Hori dela eta, nodeSelector esaten dugu eta maisuetan etiketa estandarra dugu, eta horrek aukera ematen dizu klusterreko nodo guztien artean maisuak diren nodoak hautatzeko.
Bi atal hauekin maisuari helduko zaio zalantzarik gabe. Eta bertan bizitzeko baimena emango diote.
Baina maisuarengana etortzea ez zaigu nahikoa. Honek ez digu ezer emango. Beraz, hurrengo bi gauza hauek ditugu:
hostNetwork: true
hostPID: true Abian jartzen dugun gure poda kernel izen-espazioan, sareko izen-espazioan eta PID izen-espazioan biziko dela zehazten dugu. Pod-a maisuan abiarazi ondoren, nodo honen benetako interfaze guztiak ikusteko, trafiko guztia entzun eta prozesu guztien PID-a ikusi ahal izango du.
Orduan gauza txikien kontua da. Hartu etcd eta irakurri nahi duzuna.
Interesgarriena Kubernetes ezaugarri hau da, lehenespenez bertan dagoena.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Eta bere funtsa da pod-ean esan dezakegula abiarazten dugula, nahiz eta kluster honen eskubiderik gabe, hostPath motako bolumen bat sortu nahi dugula. Horrek esan nahi du abiaraziko dugun ostalaritik bidea hartzea eta bolumen gisa hartzea. Eta gero izena deitzen diogu: host. HostPath osoa lekaren barruan muntatzen dugu. Adibide honetan, /host direktoriora.
Berriro errepikatuko dut. Pod-ari esan genion masterrera etortzeko, hostNetwork eta hostPID bertan lortzeko eta master-aren erro osoa pod honen barruan muntatzeko.
Ulertzen duzu Debian-en bash exekutatzen dugula, eta bash hau root azpian exekutatzen dela. Hau da, maisuan erroa jaso berri dugu, Kubernetes klusterrean inolako eskubiderik izan gabe.
Ondoren, zeregin osoa /host /etc/kubernetes/pki azpidirektoriora joatea da, oker ez banago, bertan jaso klusterreko ziurtagiri nagusi guztiak eta, horren arabera, bihurtu klusterraren administratzaile.
Honela ikusten baduzu, hauek dira pods-en eskubide arriskutsuenetako batzuk, erabiltzaileak zein eskubide dituen kontuan hartu gabe:
Pod bat klusterraren izen-espazio batean exekutatzeko eskubideak baditut, orduan pod honek eskubide hauek ditu lehenespenez. Pod pribilegiatuak exekutatu ditzaket, eta hauek, oro har, eskubide guztiak dira, ia nodoan erro.
Nire gustukoena Root erabiltzailea da. Eta Kubernetes-ek Run As Non-Root aukera hau du. Hacker baten aurkako babes mota bat da. Ba al dakizu zer den “Moldaviako birusa”? Bat-batean hacker bat bazara eta nire Kubernetes klusterera etortzen bazara, orduan guk, administratzaile pobreek, hauxe galdetzen dizugu: “Mesedez, adierazi zure podetan zeinekin hackeatu duzun nire klusterra, exekutatu ez-root gisa. Bestela, gertatuko da prozesua root azpian zure podan exekutatzen duzula, eta oso erraza izango zaizu pirateatzea. Mesedez, babes ezazu zuregandik".
Ostalariaren bide-bolumena da, nire ustez, Kubernetes kluster batetik nahi den emaitza lortzeko modurik azkarrena.
Baina zer egin honekin guztiarekin?
Kubernetesekin topo egiten duen edozein administratzaile arruntengana etorri beharko litzatekeen pentsamendua hauxe da: "Bai, esan dizut, Kubernetes-ek ez du funtzionatzen. Bertan zuloak daude. Eta Kubo osoa astakeria da». Izan ere, bada dokumentazioa, eta horra begiratuz gero, bada atal bat .
Hau yaml objektu bat da - Kubernetes klusterrean sor dezakegu - segurtasun-alderdiak kontrolatzen ditu bereziki leken deskribapenean. Hau da, hain zuzen ere, abiaraztean podsetan dauden edozein hostNetwork, hostPID, bolumen mota jakin batzuk erabiltzeko eskubideak kontrolatzen ditu. Pod Segurtasun Politikaren laguntzaz, hau guztia deskriba daiteke.
Pod Segurtasun Politikari buruzko gauzarik interesgarriena da Kubernetes klusterrean, PSP instalatzaile guztiak ez direla inola ere deskribatzen, lehenespenez desgaituta daudela. Pod Segurtasun-politika onarpen plugina erabiliz gaituta dago.
Ados, inplementatu ditzagun Pod Security Policy klusterean, demagun zerbitzu-pod batzuk ditugula izen-espazioan, eta horietara administratzaileek soilik dute sarbidea. Demagun, gainontzeko kasuetan lekak eskubide mugatuak dituztela. Garatzaile gehienek ez dutelako zure klusterrean pribilegiatu pribilegiatuak exekutatu behar.
Eta dena ondo doala dirudi. Eta gure Kubernetes klusterra ezin da bi minututan pirateatu.
Arazo bat dago. Seguruenik, Kubernetes kluster bat baduzu, monitorizazioa zure klusterrean instalatuta dago. Are gehiago, iragartzeraino iritsiko nintzateke zure klusterrak monitorizazioa badu, Prometheus deituko dela.
Kontatuko dudana Prometheus operadorearentzat zein Prometheus bere forma hutsean entregatutakoentzat balioko du. Galdera da ezin badut administratzaile bat klusterrean sartu hain azkar, horrek esan nahi du gehiago bilatu behar dudala. Eta zure monitorizazioaren laguntzaz bilatu dezaket.
Seguruenik, denek irakurtzen dituzte Habré-n artikulu berdinak, eta monitorizazioa monitoring namespacean dago. Helm taula deitzen da gutxi gorabehera denentzat. Uste dut helm install stable/prometheus egiten baduzu, gutxi gorabehera izen berdinak izango dituzula. Eta ziurrenik ez dut zure klusterreko DNS izena asmatu beharko. Estandarra delako.
Hurrengo garapen jakin bat dugu, zeinetan pod jakin bat exekutatu dezakezu. Eta gero, pod honetatik oso erraza da horrelako zerbait egitea:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics Kubernetes APItik bertatik neurketak biltzen dituen Prometheus esportatzaileetako bat da. Bertan datu asko daude, zer exekutatzen ari den zure klusterrean, zer den, zein arazo dituzun.
Adibide sinple gisa:
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
Pribilegiorik gabeko pod batetik kizkur eskaera soil bat eginez, informazio hau lor dezakezu. Ez badakizu Kubernetes-en zein bertsio exekutatzen ari zaren, erraz esango dizu.
Eta interesgarriena da kube-state-metrics atzitzeaz gain, Prometheus bera zuzenean sar zaitezkeela. Hortik neurketak bil ditzakezu. Bertatik neurketak ere eraiki ditzakezu. Teorikoki ere, Prometheus-eko kluster batetik eraiki dezakezu kontsulta hori, eta horrek besterik gabe itzali egingo du. Eta zure monitorizazioak klusteretik funtzionatzeari utziko dio guztiz.
Eta hemen galdera sortzen da ea kanpoko monitorizazioren batek zure monitorizazioa kontrolatzen duen. Kubernetes kluster batean jarduteko aukera izan dut niretzat inolako ondoriorik gabe. Ez duzu jakingo bertan lanean ari naizenik, ez baitago monitorizaziorik.
PSPrekin bezala, arazoa dela iruditzen zait teknologia dotore horiek guztiak - Kubernetes, Prometheus - ez dutela funtzionatzen eta zuloz beteta daudela. Benetan ez.
Badago halakorik - .
Administratzaile normala bazara, ziurrenik sare-politikari buruz jakingo duzu hori beste yaml bat besterik ez dela, eta horietatik asko daude jada klusterrean. Eta Sareko Politika batzuk ez dira beharrezkoak. Eta sare-politika zer den irakurtzen baduzu ere, Kubernetes-en yaml suebakia dela, izen-espazioen arteko sarbide-eskubideak mugatzeko aukera ematen dizu, poden artean, orduan erabaki zenuen yaml formatuan Kubernetes-en suebakia hurrengo abstrakzioetan oinarritzen dela. ... Ez, ez . Hau, zalantzarik gabe, ez da beharrezkoa.
Zure segurtasun espezialistei esan ez badiezu zure Kubernetes erabiliz suebaki oso erraz eta sinple bat eraiki dezakezula, eta, gainera, oso xehea. Hau oraindik ez badakite eta molestatzen ez bazaitu: "Beno, emaidazu, emaidazu..." Orduan, edozein kasutan, zure klustertik atera daitezkeen zerbitzu-leku batzuetarako sarbidea blokeatzeko Sareko Politika behar duzu. inolako baimenik gabe.
Eman dudan adibidean bezala, Kubernetes klusterreko edozein izen-espaziotik kube egoeraren neurketak atera ditzakezu horretarako eskubiderik izan gabe. Sare-politikek beste izen-espazio guztietatik sarbidea itxi dute jarraipenaren izen-espaziorako eta kitto: sarbiderik ez, arazorik gabe. Dauden grafiko guztietan, bai Prometheus estandarrean, bai operadorean dagoen Prometheus-en, lema-balioetan aukera bat besterik ez dago sare-politikak gaitzeko. Piztu besterik ez duzu behar eta funtzionatuko dute.
Benetan arazo bat dago hemen. Bizardun administratzaile normala izanik, ziurrenik sare-politikak ez direla behar erabaki zenuen. Eta Habr bezalako baliabideei buruzko mota guztietako artikuluak irakurri ondoren, erabaki zenuen flanela, batez ere ostalari-atebide moduarekin, aukera dezakezun gauzarik onena dela.
Zer egin?
Saia zaitezke zure Kubernetes klusterrean duzun sare-soluzioa berriro zabaltzen, saiatu ordez funtzionalagoa den zerbaitekin. Calico berarentzat, adibidez. Baina berehala esan nahi dut Kubernetes lan-kluster batean sareko irtenbidea aldatzeko zeregina ez dela hutsala. Bi aldiz konpondu nuen (bi aldiz, ordea, teorikoki), baina Slurmsen nola egin ere erakutsi genuen. Gure ikasleei, sareko irtenbidea nola aldatu erakutsi genien Kubernetes kluster batean. Printzipioz, ekoizpen klusterrean geldialdirik ez dagoela ziurtatzen saia zaitezke. Baina ziurrenik ez duzu arrakastarik izango.
Eta arazoa benetan oso sinpleki konpontzen da. Klusterrean ziurtagiriak daude, eta badakizu zure ziurtagiriak urtebete barru iraungiko direla. Beno, eta normalean klusterrean ziurtagiriak dituen irtenbide normal bat - zergatik kezkatzen garen, kluster berri bat sortuko dugu inguruan, zaharra usteltzen utziko dugu eta dena berriro zabalduko dugu. Egia da, usteltzen denean, egun batez eserita egon beharko dugu, baina hona hemen kluster berri bat.
Kluster berri bat planteatzen duzunean, aldi berean, sartu Calico-a flanela ordez.
Zer egin zure ziurtagiriak ehun urterako jaulkitzen badira eta ez baduzu klusterra berriro zabalduko? Kube-RBAC-Proxy bezalako gauza bat dago. Oso garapen polita da, Kubernetes klusterreko edozein podetan sidecar edukiontzi gisa txertatzeko aukera ematen du. Eta, egia esan, baimena gehitzen dio pod honi Kubernetesen beraren RBAC bidez.
Arazo bat dago. Aurretik, Kube-RBAC-Proxy irtenbide hau operadorearen Prometheus-en sartu zen. Baina gero joan zen. Orain bertsio modernoek sareko politika bat duzula eta haiek erabiliz ixten duzula oinarritzen dira. Eta horregatik taula pixka bat berridatzi beharko dugu. Izan ere, joaten bazara , badaude hau sidecar gisa erabiltzeko adibideak, eta diagramak gutxieneko berridatzi beharko dira.
Arazo txiki bat gehiago dago. Prometheus ez da edonori bere neurketak banatzen dizkion bakarra. Gure Kubernetes klusterreko osagai guztiak ere beren neurketak itzultzeko gai dira.
Baina lehen esan dudan bezala, ezin baduzu klusterra sartu eta informazioa bildu, orduan kalteren bat egin dezakezu gutxienez.
Beraz, Kubernetes kluster bat nola hondatu daitekeen bi modu azkar erakutsiko ditut.
Barre egingo duzu hau esaten dizudanean, bizitza errealeko bi kasu dira hauek.
Lehenengo metodoa. Baliabideak agortzea.
Abian dezagun beste pod berezi bat. Honelako atal bat izango du.
resources:
requests:
cpu: 4
memory: 4Gi Dakizuenez, eskaerak ostalarian erreserbatzen den CPU eta memoria kopurua da eskaerak dituzten pod zehatzetarako. Kubernetes kluster batean lau nukleoko ostalari bat badugu eta lau CPU-pod eskaerekin iristen badira, esan nahi du ezingo dela ostalari honetara iritsi eskaerak dituzten pods gehiago.
Horrelako pod bat exekutatzen badut, komandoa exekutatuko dut:
$ kubectl scale special-pod --replicas=...Orduan, beste inork ezingo du inplementatu Kubernetes klusterean. Nodo guztiak eskaerarik gabe geratuko direlako. Eta horrela zure Kubernetes clusterra geldituko dut. Arratsaldean hau egiten badut, denbora luzez geldi ditzaket inplementazioak.
Kubernetes-en dokumentazioa berriro begiratzen badugu, muga-barrutia izeneko gauza hau ikusiko dugu. Kluster-objektuen baliabideak ezartzen ditu. Limit Range objektu bat idatz dezakezu yaml-en, aplikatu izen-espazio batzuei - eta, ondoren, izen-espazio honetan esan dezakezu leketarako baliabide lehenetsiak, maximoak eta minimoak dituzula.
Horren laguntzaz, taldeen produktuen izen-espazio espezifikoetan erabiltzaileak muga ditzakegu beren ontzietan mota guztietako gauza gaiztoak adierazteko. Baina, zoritxarrez, erabiltzaileari PUZ bat baino gehiagorako eskaerak dituzten pod-ak abiarazi ezin dituela esaten badiozu ere, eskala-komando zoragarria dago, edo eskala egin dezakete aginte-panelaren bidez.
Eta hortik dator bigarren metodoa. 11 lekak abiarazten ditugu. Hori da hamaika mila milioi. Hau ez da halako zenbaki bat atera dudalako, nik neuk ikusi dudalako baizik.
Benetako istorioa. Iluntzean, bulegotik irtetear nintzen. Garatzaile talde bat ikusten dut izkinan eserita, bere ordenagailu eramangarriekin zerbait egiten amorratuta. Mutikoengana joaten naiz eta galdetzen diot: "Zer gertatu zaizu?"
Pixka bat lehenago, gaueko bederatziak aldera, garatzaileetako bat etxera joateko prestatzen ari zen. Eta erabaki nuen: "Orain nire eskaera bakarrera murriztuko dut". Bat sakatu nuen, baina Internet pixka bat moteldu zen. Berriro sakatu zuen bat, sakatu zuen eta Sartu sakatu zuen. Ahal nuen guztia zulatu nuen. Orduan Internet bizia hartu zuen, eta dena kopuru horretara murrizten hasi zen.
Egia da, istorio hau ez zen Kubernetesen gertatu; garai hartan Nomad zen. Izan ere, Nomad eskalatzeko saiakera iraunkorretatik geldiarazteko gure saiakerak ordubete igaro ondoren, Nomad-ek erantzun zuen ez zuela eskalatzeari utziko eta ez zuela beste ezer egingo. "Nekatuta nago, alde egingo dut". Eta kiribildu egin zen.
Jakina, Kubernetes-en berdina egiten saiatu naiz. Kubernetes ez zegoen pozik hamaika milioi lekekin, esan zuen: "Ezin dut. Barne aho-babesak gainditzen ditu". Baina 1 lekak izan daitezke.
Mila milioiri erantzunez, Kuboa ez zen bere baitara erretiratu. Benetan eskalatzen hasi zen. Prozesua zenbat eta urrunago joan, orduan eta denbora gehiago behar izan zuen leka berriak sortzeko. Baina oraindik prozesua aurrera joan zen. Arazo bakarra da nire izen-espazioan pods-ak mugarik gabe abiarazten baditut, eskaera eta mugarik gabe ere hainbat atazarekin abiarazi ditzakedala, zeregin hauen laguntzarekin nodoak memorian gehitzen hasiko direla, CPUan. Hainbeste pod abiarazten ditudanean, haien informazioa biltegiratzera joan beharko litzateke, hau da, etab. Eta informazio gehiegi iristen denean, biltegiratzea astiroegi itzultzen hasten da, eta Kubernetes aspertzen hasten da.
Eta beste arazo bat... Dakizuenez, Kubernetes kontrol-elementuak ez dira gauza zentrala, hainbat osagai baizik. Bereziki, kontroladore kudeatzailea, programatzailea eta abar daude. Mutil hauek guztiak alferrikako lan ergelak egiten hasiko dira aldi berean, denborarekin gero eta denbora gehiago hartzen hasiko dena. Kontrolagailuaren kudeatzaileak ontzi berriak sortuko ditu. Scheduler haientzako nodo berri bat bilatzen saiatuko da. Ziurrenik laster zure klusterrean nodo berririk gabe geratuko zara. Kubernetes klusterra gero eta motelago hasiko da lanean.
Baina urrunago joatea erabaki nuen. Dakizuenez, Kubernetesen badago zerbitzu deitzen den gauza bat. Beno, lehenespenez zure klusterretan, ziurrenik, zerbitzuak IP taulak erabiliz funtzionatzen du.
Mila milioi pod exekutatzen badituzu, adibidez, eta gero script bat erabiltzen baduzu Kubernetis zerbitzu berriak sortzera behartzeko:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Klusterraren nodo guztietan, gero eta iptables arau berri gehiago sortuko dira gutxi gorabehera aldi berean. Gainera, mila milioi iptables arau sortuko dira zerbitzu bakoitzeko.
Hainbat milatan egiaztatu nuen gauza hau guztia, hamar arte. Eta arazoa da dagoeneko atalase honetan nahiko problematikoa dela nodoan ssh egitea. Paketeak, hainbeste kate igarota, ez oso ondo sentitzen hasten direlako.
Eta hau ere Kubernetes-en laguntzarekin konpontzen da. Baliabideen kuota objektu bat dago. Klusterreko izen-espaziorako erabilgarri dauden baliabide eta objektu kopurua ezartzen du. Yaml objektu bat sor dezakegu Kubernetes klusterraren izen-espazio bakoitzean. Objektu hau erabiliz, izen-espazio honetarako eskaera eta muga kopuru jakin bat esleituta dugula esan dezakegu, eta gero esan dezakegu izen-espazio honetan 10 zerbitzu eta 10 pod sor daitezkeela. Eta garatzaile bakar batek gutxienez bere burua ito dezake arratsaldeetan. Kubernetesek esango dio: "Ezin dituzu zure lekak kopuru horretara eskalatu, baliabideak kuota gainditzen duelako". Hori da, arazoa konponduta. .
Zentzu honetan arazo bat sortzen da. Kubernetesen izen-espazio bat sortzea zein zaila bihurtzen ari den sentitzen duzu. Sortzeko, gauza asko hartu behar ditugu kontuan.
Baliabideen kuota + Muga-barrutia + RBAC
• Sortu izen-espazio bat
• Sortu barruan muga-barrutia
• Sortu barruko baliabideen kuota
• Sortu zerbitzu-kontu bat CIrako
• Sortu rol-lotura CI eta erabiltzaileentzat
• Aukeran, abiarazi beharrezko zerbitzu-podak
Horregatik, aukera hau aprobetxatu nahiko nuke nire garapenak partekatzeko. Bada SDK operadorea deitzen den gauza bat. Hau Kubernetes kluster batek operadoreak idazteko modu bat da. Ansible erabiliz adierazpenak idatz ditzakezu.
Hasieran Ansible-n idatzi zen, eta gero SDK operadore bat zegoela ikusi nuen eta Ansible rola operadore batean berridatzi nuen. Adierazpen honek komando izeneko Kubernetes klusterrean objektu bat sortzeko aukera ematen du. Komando baten barruan, komando honen ingurunea yaml-en deskribatzeko aukera ematen du. Eta talde giroaren barruan, baliabide asko esleitzen ari garela deskribatzeko aukera ematen digu.
petite .
Eta bukatzeko. Zer egin honekin guztiarekin?
Lehenengoa. Pod Segurtasun-politika ona da. Eta gaur egun Kubernetes instalatzaileetako inork ez dituen arren erabili, oraindik ere erabili behar dituzu zure klusterretan.
Sare-politika ez da beharrezkoa ez den beste funtzio bat. Hau da kluster batean benetan behar dena.
LimitRange/ResourceQuota - erabiltzeko garaia da. Aspaldi hasi ginen hau erabiltzen, eta denbora luzez ziur egon nintzen denek erabiltzen zutela. Hori arraroa dela ikusi zen.
Txostenean aipatu dudanez gain, dokumenturik gabeko funtzioak daude kluster erasotzeko aukera ematen dutenak. Duela gutxi kaleratua .
Gauza batzuk oso tristeak eta mingarriak dira. Esate baterako, baldintza jakin batzuetan, Kubernetes klusterreko kubeletek warlocks direktorioaren edukia baimendu gabeko erabiltzaile bati eman diezaiokete.
Esan dizudan guztia nola erreproduzitzeko argibideak daude. ResourceQuota eta Pod Segurtasun Politikaren itxura duten ekoizpen-adibideekin fitxategiak daude. Eta hori guztia ukitu dezakezu.
Eskerrik asko guztioi.
Iturria: www.habr.com