Si Pavel Selivanov, Southbridge solutions architect ug Slurm teacher, mihatag og presentasyon sa DevOpsConf 2019. Kini nga pakigpulong kabahin sa usa sa mga hilisgutan sa lawom nga kurso sa Kubernetes "Slurm Mega".
mahitabo sa Moscow sa Nobyembre 18-20.
— Moscow, Nobyembre 22-24.
kanunay anaa.
Ubos sa cut mao ang usa ka transcript sa report.
Maayong hapon, mga kauban ug sa mga naluoy kanila. Karon maghisgot ko bahin sa kaluwasan.
Nakita nako nga adunay daghang mga guwardiya sa hawanan karon. Nangayo ko og pasaylo kanimo kung mogamit ako mga termino gikan sa kalibutan sa seguridad nga dili eksakto sama sa naandan alang kanimo.
Nahitabo kini nga mga unom ka bulan ang milabay nakit-an nako ang usa ka publiko nga cluster sa Kubernetes. Ang publiko nagpasabot nga adunay ikaunom nga gidaghanon sa mga namespace; niining mga namespace adunay mga tiggamit nga nahimulag sa ilang namespace. Ang tanan niini nga mga tiggamit iya sa lain-laing mga kompanya. Aw, gituohan nga kini nga cluster kinahanglan gamiton isip CDN. Sa ato pa, gihatagan ka nila og cluster, gihatagan ka nila og user didto, adto ka didto sa imong namespace, i-deploy ang imong mga front.
Ang akong kanhing kompaniya misulay sa pagbaligya sa maong serbisyo. Ug ako gihangyo sa pagduslak sa cluster aron makita kung kini nga solusyon angay ba o dili.
Niabot ko ani nga cluster. Gihatagan ako og limitado nga mga katungod, limitado nga namespace. Ang mga lalaki didto nakasabot kung unsa ang kaluwasan. Ilang gibasa ang bahin sa Role-based access control (RBAC) sa Kubernetes - ug ila kining gituis aron dili nako malansad ang mga pod nga bulag sa mga deployment. Wala ko kahinumdom sa problema nga akong gisulayan pagsulbad pinaagi sa paglansad sa usa ka pod nga walay deployment, apan gusto gyud nako nga maglansad usa lang pod. Alang sa suwerte, nakahukom ko nga tan-awon kung unsang mga katungod ang naa nako sa cluster, kung unsa ang akong mahimo, kung unsa ang dili nako mahimo, ug kung unsa ang ilang gibuak didto. Sa samang higayon, isulti ko kanimo kung unsa ang ilang gi-configure nga dili husto sa RBAC.
Nahitabo nga sa duha ka minuto nakadawat ako usa ka admin sa ilang cluster, gitan-aw ang tanan nga kasikbit nga mga namespace, nakita didto ang nagdagan nga mga front production sa mga kompanya nga nakapalit na sa serbisyo ug gipakatap. Halos dili nako mapugngan ang akong kaugalingon sa pag-adto sa atubangan sa usa ka tawo ug pagbutang og pipila ka mga pulong sa pagpamalikas sa main page.
Sultihan ko ikaw sa mga pananglitan kung giunsa nako kini gibuhat ug kung giunsa pagpanalipod ang imong kaugalingon gikan niini.
Pero una, magpaila ko sa akong kaugalingon. Ako si Pavel Selivanov. Usa ko ka arkitekto sa Southbridge. Nakasabot ko sa Kubernetes, DevOps ug tanang matang sa nindot nga mga butang. Ang mga inhenyero sa Southbridge ug ako nagtukod niining tanan, ug ako nagkonsulta.
Dugang pa sa among mga nag-unang kalihokan, bag-o lang kami naglunsad og mga proyekto nga gitawag og Slurms. Kami naningkamot sa pagdala sa among abilidad sa pagtrabaho uban sa Kubernetes sa gamay ngadto sa masa, sa pagtudlo sa ubang mga tawo sa pagtrabaho uban sa K8s.
Unsa ang akong hisgutan karon? Ang hilisgutan sa taho klaro - bahin sa seguridad sa Kubernetes cluster. Apan gusto nako nga isulti dayon nga kini nga hilisgutan dako kaayo - ug busa gusto nako nga ipatin-aw dayon kung unsa ang dili nako hisgutan. Dili ko maghisgot bahin sa mga termino nga gi-hackney nga gigamit na sa usa ka gatos ka beses sa Internet. Tanan nga klase sa RBAC ug mga sertipiko.
Maghisgot ako bahin sa kung unsa ang kasakit kanako ug sa akong mga kauban bahin sa seguridad sa usa ka cluster sa Kubernetes. Nakita namo kini nga mga problema sa mga provider nga naghatag sa mga cluster sa Kubernetes ug sa mga kliyente nga mianhi kanamo. Ug bisan gikan sa mga kliyente nga mianhi kanamo gikan sa ubang mga kompanya sa admin sa pagkonsulta. Sa ato pa, dako kaayo ang sukod sa trahedya.
Adunay literal nga tulo ka mga punto nga akong hisgutan karon:
- Mga katungod sa tiggamit vs katungod sa pod. Ang mga katungod sa tiggamit ug mga katungod sa pod dili parehas nga butang.
- Pagkolekta sa impormasyon bahin sa cluster. Akong ipakita nga makolekta nimo ang tanang impormasyon nga imong gikinahanglan gikan sa usa ka cluster nga walay espesyal nga katungod niini nga cluster.
- Pag-atake sa DoS sa cluster. Kung dili kami makakolekta og impormasyon, makahimo kami sa pagbutang og cluster sa bisan unsang kaso. Maghisgot ako bahin sa mga pag-atake sa DoS sa mga elemento sa pagkontrol sa cluster.
Ang laing kinatibuk-ang butang nga akong hisgutan mao ang akong gisulayan ang tanan niini, diin ako makaingon nga kini tanan nagtrabaho.
Gikuha namo isip basehan ang pag-instalar sa Kubernetes cluster gamit ang Kubespray. Kung adunay wala nahibal-an, kini usa ka hugpong sa mga tahas alang sa Ansible. Gigamit namo kini kanunay sa among trabaho. Ang maayo nga butang mao nga mahimo nimo kini i-roll bisan asa - mahimo nimo kining i-roll sa mga piraso nga puthaw o ngadto sa usa ka panganod sa bisan asa. Ang usa ka pamaagi sa pag-instalar nagtrabaho sa prinsipyo alang sa tanan.
Niini nga cluster aduna koy Kubernetes v1.14.5. Ang tibuok Cube cluster, nga atong tagdon, gibahin ngadto sa mga namespace, ang matag namespace iya sa usa ka bulag nga team, ug ang mga miyembro niini nga team adunay access sa matag namespace. Dili sila makaadto sa lainlaing mga namespaces, sa ilang kaugalingon ra. Apan adunay usa ka piho nga account sa admin nga adunay mga katungod sa tibuuk nga cluster.
Gisaad nako nga ang una natong buhaton mao ang pagkuha sa mga katungod sa admin sa cluster. Nagkinahanglan kami og espesyal nga giandam nga pod nga makaguba sa Kubernetes cluster. Ang kinahanglan lang natong buhaton mao ang paggamit niini sa Kubernetes cluster.
kubectl apply -f pod.yamlKini nga pod moabot sa usa sa mga master sa Kubernetes cluster. Ug pagkahuman niini ang cluster malipayong ibalik kanamo ang usa ka file nga gitawag og admin.conf. Sa Cube, kini nga file nagtipig sa tanan nga mga sertipiko sa tagdumala, ug sa samang higayon gi-configure ang cluster API. Ingon niini kadali ang pagkuha sa admin access, sa akong hunahuna, 98% sa mga cluster sa Kubernetes.
Akong balikon, kini pod gihimo sa usa ka developer sa imong cluster nga naay access sa pagdeploy sa iyang mga proposals ngadto sa usa ka gamay nga namespace, kining tanan gi-clamp sa RBAC. Wala siyay katungod. Apan bisan pa niana ang sertipiko gibalik.
Ug karon mahitungod sa usa ka espesyal nga giandam pod. Gipadagan namon kini sa bisan unsang imahe. Atong kuhaon ang debian:jessie isip usa ka pananglitan.
Adunay kami niini nga butang:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Unsa ang pagkamatugtanon? Ang mga master sa usa ka Kubernetes cluster kasagarang gimarkahan og butang nga gitawag og taint. Ug ang diwa sa kini nga "impeksyon" mao nga kini nag-ingon nga ang mga pod dili mahimong itudlo sa mga master node. Apan walay usa nga nagsamok sa pagpakita sa bisan unsa nga pod nga kini tolerant sa "infection". Ang seksyon sa Toleration nag-ingon lang nga kung ang pila ka node adunay NoSchedule, nan ang among node matugotan sa ingon nga impeksyon - ug wala’y mga problema.
Dugang pa, giingon namon nga ang among ilawom dili lamang matugoton, apan gusto usab nga piho nga target ang agalon. Tungod kay ang mga agalon adunay labing lamian nga butang nga kinahanglan namon - ang tanan nga mga sertipiko. Busa, giingon namon ang nodeSelector - ug kami adunay usa ka standard nga label sa mga masters, nga nagtugot kanimo sa pagpili gikan sa tanan nga mga node sa cluster sa eksakto nga mga node nga mga masters.
Uban niining duha ka mga seksyon moadto gyud siya sa agalon. Ug tugotan siya nga mopuyo didto.
Apan ang pag-adto lang sa agalon dili igo alang kanamo. Kini dili makahatag kanato ug bisan unsa. Busa sa sunod aduna kita niining duha ka butang:
hostNetwork: true
hostPID: true Gitino namo nga ang among pod, nga among gilusad, magpuyo sa kernel namespace, sa network namespace, ug sa PID namespace. Kung gilansad na ang pod sa master, makita niini ang tanan nga tinuod, live nga mga interface sa kini nga node, paminawa ang tanan nga trapiko ug makita ang PID sa tanan nga mga proseso.
Unya kini usa ka butang sa gagmay nga mga butang. Pagkuha ug etcd ug basaha ang imong gusto.
Ang labing makaiikag nga butang mao kini nga Kubernetes nga bahin, nga naa didto pinaagi sa default.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Ug ang esensya niini mao nga makasulti kami sa pod nga among gilunsad, bisan kung wala’y mga katungod sa kini nga cluster, nga gusto namon nga maghimo usa ka gidaghanon sa tipo nga hostPath. Kini nagpasabot sa pagkuha sa dalan gikan sa host diin kita maglunsad - ug pagkuha niini ingon nga gidaghanon. Ug unya gitawag namon kini nga ngalan: host. Gi-mount namo kining tibuok hostPath sulod sa pod. Niini nga pananglitan, ngadto sa / host directory.
Balikon ko kini pag-usab. Gisultihan namo ang pod nga moadto sa master, kuhaa ang hostNetwork ug hostPID didto - ug i-mount ang tibuok gamut sa master sulod niini nga pod.
Nasabtan nimo nga sa Debian kami adunay bash running, ug kini nga bash nagdagan ubos sa gamut. Sa ato pa, nakadawat lang kami og gamut sa master, nga wala’y bisan unsang mga katungod sa cluster sa Kubernetes.
Dayon ang tibuok nga buluhaton mao ang pag-adto sa sub directory /host /etc/kubernetes/pki, kung wala ko masayop, kuhaa ang tanang master certificates sa cluster didto ug, sa ingon, mahimong cluster administrator.
Kung tan-awon nimo kini nga paagi, kini ang pipila sa labing peligro nga mga katungod sa mga pod - bisan unsa pa ang mga katungod sa tiggamit:
Kung ako adunay mga katungod sa pagpadagan sa usa ka pod sa pipila ka namespace sa cluster, nan kini nga pod adunay kini nga mga katungod sa default. Makapadagan ko og mga pribilihiyo nga pod, ug kini sa kasagaran ang tanan nga mga katungod, halos nakagamot sa node.
Ang akong paborito mao ang Root user. Ug ang Kubernetes adunay kini nga Run As Non-Root nga kapilian. Kini usa ka matang sa proteksyon gikan sa usa ka hacker. Nahibal-an ba nimo kung unsa ang "Moldavian virus"? Kung kalit ka nga usa ka hacker ug moadto sa akong Kubernetes cluster, nan kami, mga kabus nga mga administrador, mangutana: "Palihug ipahibalo sa imong mga pod kung diin nimo i-hack ang akong cluster, modagan nga dili gamut. Kay kon dili, kini mahitabo nga kamo modagan sa proseso sa imong pod ubos sa gamut, ug kini mahimong kaayo sayon alang kaninyo sa hack kanako. Palihug panalipdan ang imong kaugalingon gikan sa imong kaugalingon."
Ang gidaghanon sa agianan sa host mao, sa akong opinyon, ang labing paspas nga paagi aron makuha ang gitinguha nga resulta gikan sa usa ka kumpol sa Kubernetes.
Apan unsay buhaton niining tanan?
Ang hunahuna nga kinahanglan moabut sa bisan kinsa nga normal nga administrador nga makasugat sa Kubernetes mao ang: "Oo, gisultihan ko ikaw, ang Kubernetes dili molihok. Adunay mga buslot niini. Ug ang tibuok Cube kay binuang.” Sa tinuud, adunay usa ka butang sama sa dokumentasyon, ug kung imong tan-awon didto, adunay usa ka seksyon .
Kini usa ka yaml nga butang - mahimo naton kini sa Kubernetes cluster - nga nagkontrol sa mga aspeto sa seguridad ilabi na sa paghulagway sa mga pod. Kana mao, sa tinuud, kini nagkontrol sa mga katungod sa paggamit sa bisan unsang hostNetwork, hostPID, pipila nga mga tipo sa volume nga naa sa mga pod sa pagsugod. Sa tabang sa Pod Security Policy, kining tanan mahulagway.
Ang labing makaiikag nga butang bahin sa Pod Security Policy mao nga sa Kubernetes cluster, ang tanan nga mga installer sa PSP dili lang gihulagway sa bisan unsang paagi, sila gi-disable lang pinaagi sa default. Ang Pod Security Policy gipalihok gamit ang admission plugin.
Okay, atong i-deploy ang Pod Security Policy ngadto sa cluster, ingnon ta nga aduna kitay mga service pod sa namespace, diin ang mga admin lang ang adunay access. Ingnon ta, sa ubang mga kaso, ang mga pod adunay limitado nga mga katungod. Tungod kay ang labing lagmit nga mga developer dili kinahanglan nga magpadagan sa mga pribilehiyo nga pod sa imong cluster.
Ug morag okay ra ang tanan kanamo. Ug ang among Kubernetes cluster dili ma-hack sa duha ka minuto.
Naay problema. Lagmit, kung ikaw adunay Kubernetes cluster, nan ang pagmonitor gi-install sa imong cluster. Moadto pa gani ko sa pagtagna nga kung ang imong cluster adunay monitoring, kini tawgon nga Prometheus.
Ang akong isulti kanimo mahimong balido alang sa Prometheus operator ug Prometheus nga gihatag sa lunsay nga porma niini. Ang pangutana mao nga kung dili nako makuha ang usa ka admin sa cluster nga dali, nan kini nagpasabut nga kinahanglan nako nga mangita pa. Ug makapangita ko sa tabang sa imong pagmonitor.
Tingali ang tanan nagbasa sa parehas nga mga artikulo sa Habré, ug ang pag-monitor nahimutang sa namespace sa pag-monitor. Ang tsart sa helm gitawag nga halos parehas alang sa tanan. Sa akong pagtag-an nga kung imong buhaton ang pag-install sa stable/prometheus, maabut nimo ang halos parehas nga mga ngalan. Ug lagmit dili na nako kinahanglan nga tag-an ang ngalan sa DNS sa imong cluster. Tungod kay kini standard.
Sunod kami adunay usa ka piho nga mga dev ns, diin mahimo nimong ipadagan ang usa ka piho nga pod. Ug unya gikan niini nga pod sayon ra kaayo ang pagbuhat og sama niini:
$ curl http://prometheus-kube-state-metrics.monitoring Ang prometheus-kube-state-metrics maoy usa sa mga exporter sa Prometheus nga nagkolekta ug metrics gikan sa Kubernetes API mismo. Adunay daghang mga datos didto, kung unsa ang nagdagan sa imong cluster, kung unsa kini, kung unsa ang imong mga problema niini.
Ingon usa ka yano nga pananglitan:
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
Pinaagi sa paghimo sa usa ka yano nga curl nga hangyo gikan sa usa ka dili pribilihiyo nga pod, makuha nimo ang mosunud nga kasayuran. Kung wala ka nahibal-an kung unsang bersyon sa Kubernetes ang imong gipadagan, dali ra kini isulti kanimo.
Ug ang labing makapaikag nga butang mao nga dugang sa pag-access sa kube-state-metrics, mahimo nimo nga dali nga ma-access ang Prometheus mismo direkta. Mahimo nimong kolektahon ang mga sukatan gikan didto. Mahimo ka pa nga maghimo mga sukatan gikan didto. Bisan sa teoretikal, mahimo nimong buhaton ang ingon nga pangutana gikan sa usa ka pungpong sa Prometheus, nga i-off ra kini. Ug ang imong pag-monitor mohunong sa pagtrabaho gikan sa cluster sa hingpit.
Ug dinhi ang pangutana mitungha kung ang bisan unsang eksternal nga pag-monitor nag-monitor sa imong pag-monitor. Bag-o lang ko nakahigayon sa pag-operate sa usa ka Kubernetes cluster nga walay bisan unsang mga sangputanan alang sa akong kaugalingon. Dili gani nimo mahibal-an nga nag-operate ako didto, tungod kay wala nay monitoring.
Sama sa PSP, gibati nga ang problema mao nga kining tanan nga mga uso nga teknolohiya - Kubernetes, Prometheus - wala gyud kini molihok ug puno sa mga lungag. Dili gyud.
Adunay usa ka butang - .
Kung ikaw usa ka normal nga admin, nan lagmit nahibal-an nimo ang bahin sa Patakaran sa Network nga kini usa ra ka yaml, diin daghan na sila sa cluster. Ug ang pipila ka Mga Patakaran sa Network siguradong dili kinahanglan. Ug bisan kung imong gibasa kung unsa ang Network Policy, nga kini usa ka yaml firewall sa Kubernetes, gitugotan ka nga limitahan ang mga katungod sa pag-access tali sa mga namespace, taliwala sa mga pods, nan sigurado ka nga nakahukom nga ang firewall sa yaml format sa Kubernetes gibase sa mga sunod nga abstraction. ... Dili, dili . Kini siguradong dili kinahanglan.
Bisan kung wala nimo gisultihan ang imong mga espesyalista sa seguridad nga gamit ang imong mga Kubernetes makahimo ka og usa ka dali ug yano nga firewall, ug usa ka labi ka granular niana. Kung wala pa nila nahibal-an kini ug dili ka magsamok kanimo: "Bueno, hatagi ako, hatagi ako ..." Unya sa bisan unsang kaso, kinahanglan nimo ang Patakaran sa Network aron babagan ang pag-access sa pipila nga mga lugar sa serbisyo nga mahimong makuha gikan sa imong cluster walay bisan unsa nga pagtugot.
Sama sa pananglitan nga akong gihatag, mahimo nimong makuha ang kube state metrics gikan sa bisan unsang namespace sa Kubernetes cluster nga walay katungod sa pagbuhat niini. Ang mga polisiya sa network nagsira sa pag-access gikan sa tanan nga uban nga mga namespaces ngadto sa monitoring namespace ug mao kana: walay access, walay mga problema. Sa tanan nga mga tsart nga naglungtad, pareho ang standard nga Prometheus ug ang Prometheus nga naa sa operator, adunay usa ka kapilian sa mga kantidad sa timon aron yano nga magamit ang mga palisiya sa network alang kanila. Kinahanglan nimo nga i-on kini ug molihok sila.
Adunay usa ka problema dinhi. Ingon nga usa ka normal nga bungot nga admin, lagmit nakahukom ka nga dili kinahanglan ang mga polisiya sa network. Ug pagkahuman sa pagbasa sa tanan nga mga lahi sa mga artikulo sa mga kapanguhaan sama sa Habr, nakahukom ka nga ang flannel, labi na sa mode nga host-gateway, mao ang labing kaayo nga butang nga imong mapili.
Unsay akong buhaton?
Mahimo nimong sulayan nga i-redeploy ang solusyon sa network nga naa nimo sa imong Kubernetes cluster, sulayi nga pulihan kini sa usa ka butang nga labi ka magamit. Alang sa parehas nga Calico, pananglitan. Apan gusto nako nga isulti dayon nga ang tahas sa pagbag-o sa solusyon sa network sa usa ka kumpol nga nagtrabaho sa Kubernetes dili kaayo hinungdanon. Gisulbad nako kini kaduha (sa duha ka higayon, bisan pa, sa teorya), apan gipakita pa namon kung giunsa kini buhaton sa Slurms. Alang sa among mga estudyante, among gipakita kung giunsa pagbag-o ang solusyon sa network sa usa ka cluster sa Kubernetes. Sa prinsipyo, mahimo nimong sulayan nga masiguro nga wala’y downtime sa cluster sa produksiyon. Apan lagmit dili ka molampos.
Ug ang problema sa pagkatinuod masulbad sa yano kaayo. Adunay mga sertipiko sa cluster, ug nahibal-an nimo nga ang imong mga sertipiko matapos sa usa ka tuig. Aw, kasagaran usa ka normal nga solusyon nga adunay mga sertipiko sa usa ka kumpol - ngano nga nabalaka kami, magpataas kami usa ka bag-ong kumpol sa duol, pasagdan nga madunot ang daan, ug i-redeploy ang tanan. Tinuod, kung kini madunot, kinahanglan kita nga molingkod sa usa ka adlaw, apan ania ang usa ka bag-ong pungpong.
Kung magpataas ka usa ka bag-ong cluster, sa samang higayon isulud ang Calico imbes nga flannel.
Unsa ang buhaton kung ang imong mga sertipiko gihatag sa usa ka gatos ka tuig ug dili nimo i-redeploy ang cluster? Adunay usa ka butang sama sa Kube-RBAC-Proxy. Kini usa ka cool kaayo nga pag-uswag, gitugotan ka nga i-embed ang kaugalingon ingon usa ka sulud sa sidecar sa bisan unsang pod sa cluster sa Kubernetes. Ug sa tinuud nagdugang kini nga pagtugot sa kini nga pod pinaagi sa RBAC sa Kubernetes mismo.
Adunay usa ka problema. Kaniadto, kini nga solusyon sa Kube-RBAC-Proxy gitukod sa Prometheus sa operator. Apan wala na siya. Karon ang mga modernong bersyon nagsalig sa kamatuoran nga ikaw adunay polisiya sa network ug isira kini gamit kini. Ug busa kinahanglan natong isulat pag-usab ang tsart og gamay. Sa tinuud, kung moadto ka sa , adunay mga pananglitan kung giunsa kini paggamit ingon mga sidecar, ug ang mga tsart kinahanglan nga isulat pag-usab sa labing gamay.
Adunay usa pa ka gamay nga problema. Dili lang ang Prometheus ang naghatag sa mga sukatan niini sa bisan kinsa. Ang tanan namong Kubernetes cluster component makahimo usab sa pagbalik sa ilang kaugalingong metrics.
Apan sa ako nang giingon, kung dili nimo ma-access ang cluster ug mangolekta og kasayuran, nan mahimo nimo labing menos makadaot.
Mao nga ipakita dayon nako ang duha ka paagi kung giunsa ang usa ka kumpol sa Kubernetes mahimong maguba.
Mokatawa ka kung sultihan ko ikaw niini, duha kini ka tinuod nga kaso sa kinabuhi.
Pamaagi usa. Pagkahurot sa kahinguhaan.
Maglunsad ta og laing espesyal nga pod. Kini adunay usa ka seksyon nga sama niini.
resources:
requests:
cpu: 4
memory: 4Gi Sama sa imong nahibal-an, ang mga hangyo mao ang kantidad sa CPU ug memorya nga gitagana sa host alang sa piho nga mga pod nga adunay mga hangyo. Kung kita adunay upat ka-core nga host sa usa ka Kubernetes cluster, ug upat ka mga CPU pod ang moabot didto nga adunay mga hangyo, kini nagpasabot nga wala nay pod nga adunay mga hangyo ang makaadto niini nga host.
Kung nagpadagan ko sa ingon nga pod, dayon akong ipadagan ang mando:
$ kubectl scale special-pod --replicas=...Unya walay lain nga makahimo sa pag-deploy sa Kubernetes cluster. Tungod kay ang tanan nga mga node mahurot sa mga hangyo. Ug sa ingon akong hunongon ang imong Kubernetes cluster. Kung buhaton nako kini sa gabii, mapahunong nako ang pag-deploy sa dugay nga panahon.
Kung atong tan-awon pag-usab ang dokumentasyon sa Kubernetes, atong makita kining butanga nga gitawag ug Limit Range. Nagtakda kini og mga kapanguhaan alang sa mga butang nga cluster. Mahimo kang magsulat ug Limit Range nga butang sa yaml, ipadapat kini sa pipila ka mga namespaces - ug unya niini nga namespace mahimo nimong isulti nga ikaw adunay default, maximum ug minimum nga mga kapanguhaan alang sa mga pod.
Uban sa tabang sa ingon nga butang, mahimo naton limitahan ang mga tiggamit sa piho nga mga namespace sa produkto sa mga team sa katakus nga ipakita ang tanan nga mga lahi sa daotan nga mga butang sa ilang mga pod. Apan ikasubo, bisan kung sultihan nimo ang tiggamit nga dili sila makalunsad og mga pod nga adunay mga hangyo alang sa labaw sa usa ka CPU, adunay usa ka talagsaon nga sukdanan nga sugo, o mahimo nila ang pag-scale pinaagi sa dashboard.
Ug dinhi gikan ang pamaagi numero dos. Naglunsad kami og 11 pod. Onse ka bilyon kana. Dili kini tungod kay nakahunahuna ko sa ingon nga numero, apan tungod kay ako mismo ang nakakita niini.
Tinuod nga istorya. Pagkagabii mogawas na unta ko sa opisina. Nakita nako ang usa ka grupo sa mga developers nga naglingkod sa suok, naglibog nga nagbuhat sa usa ka butang sa ilang mga laptop. Miadto ko sa mga lalaki ug nangutana: “Unsa may nahitabo nimo?”
Usa ka gamay nga sayo, mga alas nuwebe sa gabii, usa sa mga developer nangandam na sa pagpauli. Ug nakahukom ko: "Ipaubos nako karon ang akong aplikasyon sa usa." Gipugos nako ang usa, apan ang Internet mihinay og gamay. Gipindot niya pag-usab ang usa, gipindot niya ang usa, ug gi-klik ang Enter. Gikuha nako ang tanan nga akong mahimo. Unya ang Internet nabuhi - ug ang tanan nagsugod sa pag-scale sa kini nga numero.
Tinuod, kini nga istorya wala mahitabo sa Kubernetes; niadtong panahona kini mao ang Nomad. Natapos kini sa kamatuoran nga pagkahuman sa usa ka oras sa among mga pagsulay sa pagpahunong sa Nomad gikan sa padayon nga pagsulay sa pag-scale, mitubag si Nomad nga dili siya mohunong sa pag-scale ug dili na magbuhat bisan unsa pa. "Gikapoy na ko, lakaw na ko." Ug nikunot siya.
Natural, gisulayan nako nga buhaton ang parehas sa Kubernetes. Si Kubernetes wala malipay sa onse ka bilyon nga pod, siya miingon: "Dili ko mahimo. Labaw sa internal mouth guards." Apan 1 pod ang mahimo.
Agig tubag sa usa ka bilyon, ang Cube wala mag-withdraw sa iyang kaugalingon. Nagsugod na gyud siya ug scaling. Samtang nagpadayon ang proseso, mas daghang oras ang iyang gikuha sa paghimo og bag-ong mga pod. Apan nagpadayon gihapon ang proseso. Ang bugtong problema mao nga kung mahimo nako nga ilunsad ang mga pod nga walay kinutuban sa akong namespace, unya bisan kung wala’y mga hangyo ug mga limitasyon mahimo nako nga ilunsad ang daghang mga pod nga adunay pipila nga mga buluhaton nga sa tabang niini nga mga buluhaton ang mga node magsugod sa pagdugang sa memorya, sa CPU. Kung maglansad ako daghang mga pod, ang kasayuran gikan kanila kinahanglan nga itago, kana, etcd. Ug kung daghan kaayo nga kasayuran ang moabut didto, ang pagtipig nagsugod sa pagbalik nga hinay kaayo - ug ang Kubernetes nagsugod nga mapul-an.
Ug usa pa ka problema... Sama sa imong nahibal-an, ang mga elemento sa pagkontrol sa Kubernetes dili usa ka sentro nga butang, apan daghang mga sangkap. Sa partikular, adunay controller manager, scheduler, ug uban pa. Kining tanan nga mga lalaki magsugod sa pagbuhat sa wala kinahanglana, binuang nga trabaho sa samang higayon, nga sa paglabay sa panahon magsugod sa pagkuha sa dugang ug mas daghang panahon. Ang tigdumala sa tigdumala maghimo ug bag-ong mga pod. Ang scheduler mosulay sa pagpangita og bag-ong node alang kanila. Lagmit mahurot ka sa mga bag-ong node sa imong cluster sa dili madugay. Ang Kubernetes cluster magsugod sa pagtrabaho nga mas hinay ug mas hinay.
Apan nakahukom ko nga mopadayon pa. Sama sa imong nahibal-an, sa Kubernetes adunay usa ka butang nga gitawag nga serbisyo. Aw, pinaagi sa default sa imong mga kumpol, lagmit, ang serbisyo nagtrabaho gamit ang mga lamesa sa IP.
Kung nagpadagan ka usa ka bilyon nga pod, pananglitan, ug unya mogamit usa ka script aron mapugos ang Kubernetis sa paghimo og bag-ong mga serbisyo:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Sa tanang node sa cluster, mas daghan ug bag-ong mga lagda sa iptables ang mabuhat halos dungan. Dugang pa, usa ka bilyon nga mga lagda sa iptables ang mabuhat alang sa matag serbisyo.
Gisusi nako kining tibuok nga butang sa pipila ka libo, hangtod sa napulo. Ug ang problema mao nga naa na sa kini nga threshold medyo problemado ang paghimo sa ssh sa node. Tungod kay ang mga pakete, nga nag-agi sa daghang mga kadena, nagsugod nga mobati nga dili kaayo maayo.
Ug kini, usab, ang tanan nasulbad sa tabang sa Kubernetes. Adunay usa ka butang nga Resource quota. Nagtakda sa gidaghanon sa magamit nga mga kapanguhaan ug mga butang alang sa namespace sa cluster. Makahimo kita og yaml nga butang sa matag namespace sa Kubernetes cluster. Gamit kini nga butang, makaingon kita nga kita adunay usa ka piho nga gidaghanon sa mga hangyo ug mga limitasyon nga gigahin alang niini nga namespace, ug unya kita makaingon nga sa niini nga namespace posible nga makahimo og 10 ka serbisyo ug 10 pod. Ug ang usa ka developer mahimong labing menos matuk-an ang iyang kaugalingon sa mga gabii. Mosulti kaniya ang Kubernetes: "Dili nimo masukod ang imong mga pod sa kana nga kantidad, tungod kay ang kapanguhaan milapas sa quota." Mao na, nasulbad na ang problema. .
Usa ka suliran nga punto ang mitungha niining bahina. Gibati nimo kung unsa ka lisud ang paghimo og namespace sa Kubernetes. Aron mahimo kini, kinahanglan naton tagdon ang daghang mga butang.
Resource quota + Limitado nga Range + RBAC
• Paghimo og namespace
• Paghimo og limitrange sa sulod
• Paghimo sulod sa resourcequota
• Paghimo og serviceaccount para sa CI
• Paghimo rolebinding alang sa CI ug tiggamit
• Opsyonal nga ilunsad ang gikinahanglan nga mga pod sa serbisyo
Busa, gusto nakong pahimuslan kining higayona sa pagpaambit sa akong mga kalamboan. Adunay usa ka butang nga gitawag nga SDK operator. Kini usa ka paagi alang sa usa ka Kubernetes cluster sa pagsulat sa mga operator alang niini. Mahimo nimong isulat ang mga pahayag gamit ang Ansible.
Sa sinugdan kini gisulat sa Ansible, ug unya akong nakita nga adunay usa ka SDK operator ug gi-rewrote ang Ansible nga papel ngadto sa usa ka operator. Kini nga pahayag nagtugot kanimo sa paghimo og butang sa Kubernetes cluster nga gitawag og command. Sa sulod sa usa ka sugo, kini nagtugot kanimo sa paghulagway sa palibot alang niini nga sugo sa yaml. Ug sa sulod sa palibot sa team, gitugotan kami nga ihulagway nga naggahin kami daghang mga kapanguhaan.
Gamay nga usa .
Ug sa konklusyon. Unsa ang buhaton niining tanan?
Una. Ang Pod Security Policy maayo. Ug bisan pa sa kamatuoran nga walay bisan usa sa mga installer sa Kubernetes ang naggamit niini hangtod karon, kinahanglan gihapon nimo kining gamiton sa imong mga cluster.
Ang Patakaran sa Network dili lamang usa ka dili kinahanglan nga bahin. Kini mao ang gikinahanglan gayud sa usa ka cluster.
LimitRange/ResourceQuota - panahon na nga gamiton kini. Nagsugod kami sa paggamit niini sa dugay na nga panahon, ug sa dugay nga panahon sigurado ako nga ang tanan naggamit niini. Kini nahimo nga kini talagsaon.
Dugang pa sa akong gihisgutan sa panahon sa taho, adunay mga dili dokumentado nga mga bahin nga nagtugot kanimo sa pag-atake sa cluster. Gipagawas bag-o lang .
Ang ubang mga butang makapasubo ug makapasakit. Pananglitan, ubos sa pipila ka mga kondisyon, ang mga cubelet sa usa ka Kubernetes cluster makahatag sa mga sulod sa warlocks directory ngadto sa dili awtorisado nga tiggamit.
Adunay mga panudlo kung giunsa ang pag-reproduce sa tanan nga akong gisulti kanimo. Adunay mga file nga adunay mga pananglitan sa produksiyon kung unsa ang hitsura sa ResourceQuota ug Pod Security Policy. Ug mahimo nimong mahikap kining tanan.
Salamat sa tanan.
Source: www.habr.com