Si Pavel Selivanov, Southbridge solutions architect at Slurm teacher, ay nagbigay ng presentasyon sa DevOpsConf 2019. Ang pag-uusap na ito ay bahagi ng isa sa mga paksa ng malalim na kurso sa Kubernetes "Slurm Mega".
nagaganap sa Moscow noong Nobyembre 18-20.
— Moscow, Nobyembre 22-24.
laging available.
Sa ibaba ng cut ay isang transcript ng ulat.
Magandang hapon mga kasamahan at mga nakikiramay sa kanila. Ngayon ay magsasalita ako tungkol sa kaligtasan.
Nakikita ko na maraming security guard sa hall ngayon. Humihingi ako ng paumanhin sa iyo nang maaga kung gumagamit ako ng mga termino mula sa mundo ng seguridad na hindi eksakto tulad ng nakasanayan mo.
Nagkataon na mga anim na buwan na ang nakararaan ay nakatagpo ako ng isang pampublikong kumpol ng Kubernetes. Ang ibig sabihin ng publiko ay mayroong ika-XNUMX na bilang ng mga namespace; sa mga namespace na ito ay may mga user na nakahiwalay sa kanilang namespace. Ang lahat ng mga user na ito ay nabibilang sa iba't ibang kumpanya. Well, ipinapalagay na ang kumpol na ito ay dapat gamitin bilang isang CDN. Ibig sabihin, binibigyan ka nila ng isang cluster, binibigyan ka nila ng isang gumagamit doon, pumunta ka doon sa iyong namespace, i-deploy ang iyong mga harapan.
Sinubukan ng dati kong kumpanya na magbenta ng ganoong serbisyo. At ako ay hiniling na sundutin ang kumpol upang makita kung ang solusyon na ito ay angkop o hindi.
Dumating ako sa cluster na ito. Binigyan ako ng limitadong karapatan, limitadong namespace. Naunawaan ng mga lalaki doon kung ano ang kaligtasan. Nabasa nila ang tungkol sa Role-based access control (RBAC) sa Kubernetes - at pinilipit nila ito para hindi ako makapaglunsad ng mga pod nang hiwalay sa mga deployment. Hindi ko maalala ang problemang sinusubukan kong lutasin sa pamamagitan ng paglulunsad ng pod nang walang deployment, ngunit gusto ko talagang maglunsad ng isang pod. Para sa swerte, nagpasya akong makita kung ano ang mga karapatan ko sa cluster, kung ano ang maaari kong gawin, kung ano ang hindi ko magagawa, at kung ano ang kanilang nasira doon. Kasabay nito, sasabihin ko sa iyo kung ano ang mali nilang na-configure sa RBAC.
Nagkataon na sa loob ng dalawang minuto ay nakatanggap ako ng admin sa kanilang cluster, tiningnan ang lahat ng mga kalapit na namespaces, nakita doon ang mga tumatakbong production front ng mga kumpanya na nakabili na ng serbisyo at na-deploy. Halos hindi ko mapigilan ang aking sarili na pumunta sa harapan ng isang tao at maglagay ng ilang pagmumura sa pangunahing pahina.
Sasabihin ko sa iyo ang mga halimbawa kung paano ko ginawa ito at kung paano protektahan ang iyong sarili mula dito.
Pero magpapakilala muna ako. Ang pangalan ko ay Pavel Selivanov. Ako ay isang arkitekto sa Southbridge. Naiintindihan ko ang mga Kubernetes, DevOps at lahat ng uri ng magarbong bagay. Ang mga inhinyero ng Southbridge at ako ay nagtatayo ng lahat ng ito, at ako ay kumukonsulta.
Bilang karagdagan sa aming mga pangunahing aktibidad, naglunsad kami kamakailan ng mga proyektong tinatawag na Slurms. Sinisikap naming dalhin sa masa ang aming kakayahang magtrabaho kasama ang Kubernetes, para turuan ang ibang tao na makipagtulungan din sa mga K8.
Ano ang pag-uusapan ko ngayon? Malinaw ang paksa ng ulat - tungkol sa seguridad ng kumpol ng Kubernetes. Ngunit nais kong sabihin kaagad na ang paksang ito ay napakalaki - at samakatuwid ay nais kong agad na linawin kung ano ang tiyak na hindi ko pag-uusapan. Hindi ako magsasalita tungkol sa mga na-hackney na termino na nagamit na nang isang daang beses sa Internet. Lahat ng uri ng RBAC at mga sertipiko.
Pag-uusapan ko kung ano ang masakit sa akin at sa aking mga kasamahan tungkol sa seguridad sa isang cluster ng Kubernetes. Nakikita namin ang mga problemang ito kapwa sa mga provider na nagbibigay ng mga kumpol ng Kubernetes at sa mga kliyenteng pumupunta sa amin. At kahit na mula sa mga kliyente na pumupunta sa amin mula sa iba pang mga kumpanya ng pagkonsulta sa admin. Ibig sabihin, napakalaki talaga ng sukat ng trahedya.
Mayroong literal na tatlong punto na tatalakayin ko ngayon:
- Mga karapatan ng gumagamit kumpara sa mga karapatan sa pod. Ang mga karapatan ng user at mga karapatan sa pod ay hindi pareho.
- Pagkolekta ng impormasyon tungkol sa cluster. Ipapakita ko na maaari mong kolektahin ang lahat ng impormasyong kailangan mo mula sa isang cluster nang walang mga espesyal na karapatan sa cluster na ito.
- Pag-atake ng DoS sa kumpol. Kung hindi kami makakolekta ng impormasyon, makakapaglagay kami ng cluster sa anumang kaso. Magsasalita ako tungkol sa mga pag-atake ng DoS sa mga elemento ng kontrol ng kumpol.
Ang isa pang pangkalahatang bagay na babanggitin ko ay kung ano ang sinubukan ko sa lahat ng ito, kung saan tiyak kong masasabi na gumagana ang lahat.
Isinasaalang-alang namin bilang batayan ang pag-install ng isang Kubernetes cluster gamit ang Kubespray. Kung may hindi nakakaalam, isa talaga itong set ng mga tungkulin para sa Ansible. Ginagamit namin ito palagi sa aming trabaho. Ang magandang bagay ay maaari mong igulong ito kahit saan - maaari mo itong igulong sa mga piraso ng bakal o sa isang ulap sa isang lugar. Ang isang paraan ng pag-install ay gumagana sa prinsipyo para sa lahat.
Sa cluster na ito magkakaroon ako ng Kubernetes v1.14.5. Ang buong cluster ng Cube, na isasaalang-alang namin, ay nahahati sa mga namespace, ang bawat namespace ay kabilang sa isang hiwalay na koponan, at ang mga miyembro ng pangkat na ito ay may access sa bawat namespace. Hindi sila maaaring pumunta sa iba't ibang namespaces, sa sarili lang nila. Ngunit mayroong isang partikular na admin account na may mga karapatan sa buong cluster.
Nangako ako na ang unang gagawin natin ay ang pagkuha ng mga karapatan ng admin sa cluster. Kailangan namin ng espesyal na inihandang pod na sisira sa kumpol ng Kubernetes. Ang kailangan lang nating gawin ay ilapat ito sa cluster ng Kubernetes.
kubectl apply -f pod.yamlDarating ang pod na ito sa isa sa mga master ng Kubernetes cluster. At pagkatapos nito ay masayang ibabalik sa amin ng cluster ang isang file na tinatawag na admin.conf. Sa Cube, iniimbak ng file na ito ang lahat ng mga certificate ng administrator, at kasabay nito ay kino-configure ang cluster API. Ganito kadali makakuha ng admin access sa, sa tingin ko, 98% ng mga cluster ng Kubernetes.
Uulitin ko, ang pod na ito ay ginawa ng isang developer sa iyong cluster na may access na i-deploy ang kanyang mga panukala sa isang maliit na namespace, lahat ito ay na-clamp ng RBAC. Wala siyang karapatan. Ngunit gayunpaman ang sertipiko ay ibinalik.
At ngayon tungkol sa isang espesyal na inihanda na pod. Pinapatakbo namin ito sa anumang larawan. Kunin natin ang debian:jessie bilang isang halimbawa.
Mayroon kaming bagay na ito:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Ano ang pagpaparaya? Ang mga master sa isang Kubernetes cluster ay karaniwang minarkahan ng tinatawag na taint. At ang kakanyahan ng "impeksyon" na ito ay sinasabi nito na ang mga pod ay hindi maaaring italaga sa mga master node. Ngunit walang sinuman ang nag-abala upang ipahiwatig sa anumang pod na ito ay mapagparaya sa "impeksyon". Sinasabi lang ng seksyon ng Toleration na kung ang ilang node ay may NoSchedule, kung gayon ang aming node ay mapagparaya sa naturang impeksyon - at walang mga problema.
Dagdag pa, sinasabi namin na ang aming ilalim ay hindi lamang mapagparaya, ngunit nais din na partikular na i-target ang master. Dahil ang mga master ang may pinakamasarap na bagay na kailangan namin - lahat ng mga sertipiko. Samakatuwid, sinasabi namin ang nodeSelector - at mayroon kaming karaniwang label sa mga master, na nagbibigay-daan sa iyong pumili mula sa lahat ng mga node sa cluster nang eksakto sa mga node na master.
Sa dalawang seksyong ito ay tiyak na pupunta siya sa master. At papayagan siyang tumira doon.
Ngunit ang pagpunta lamang sa master ay hindi sapat para sa amin. Wala itong ibibigay sa amin. Kaya susunod na mayroon kaming dalawang bagay na ito:
hostNetwork: true
hostPID: true Tinukoy namin na ang aming pod, na aming ilulunsad, ay mabubuhay sa kernel namespace, sa network namespace, at sa PID namespace. Kapag nailunsad na ang pod sa master, makikita nito ang lahat ng tunay, live na interface ng node na ito, makinig sa lahat ng trapiko at makita ang PID ng lahat ng proseso.
Pagkatapos ito ay isang bagay ng maliliit na bagay. Kumuha ng etcd at basahin kung ano ang gusto mo.
Ang pinaka-kagiliw-giliw na bagay ay ang tampok na Kubernetes na ito, na naroroon bilang default.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host At ang esensya nito ay masasabi natin sa pod na ilulunsad natin, kahit na walang karapatan sa cluster na ito, na gusto nating lumikha ng dami ng uri ng hostPath. Nangangahulugan ito na kunin ang landas mula sa host kung saan ilulunsad namin - at kunin ito bilang volume. At pagkatapos ay tinawag namin itong pangalan: host. Ini-mount namin ang buong hostPath na ito sa loob ng pod. Sa halimbawang ito, sa /host na direktoryo.
Uulitin ko ulit. Sinabi namin sa pod na pumunta sa master, kunin ang hostNetwork at hostPID doon - at i-mount ang buong ugat ng master sa loob ng pod na ito.
Naiintindihan mo na sa Debian mayroon kaming bash running, at ang bash na ito ay tumatakbo sa ilalim ng root. Ibig sabihin, nakatanggap lang kami ng root sa master, nang walang anumang karapatan sa cluster ng Kubernetes.
Pagkatapos ang buong gawain ay pumunta sa sub directory /host /etc/kubernetes/pki, kung hindi ako nagkakamali, kunin ang lahat ng mga master certificate ng cluster doon at, nang naaayon, maging administrator ng cluster.
Kung titingnan mo ito sa ganitong paraan, ito ang ilan sa mga pinaka-mapanganib na karapatan sa mga pod - anuman ang mga karapatan ng user:
Kung may karapatan akong magpatakbo ng pod sa ilang namespace ng cluster, ang pod na ito ay may mga karapatang ito bilang default. Maaari akong magpatakbo ng mga privileged pod, at ang mga ito sa pangkalahatan ay lahat ng karapatan, halos nag-ugat sa node.
Ang paborito ko ay Root user. At ang Kubernetes ay may ganitong opsyon na Run As Non-Root. Ito ay isang uri ng proteksyon mula sa isang hacker. Alam mo ba kung ano ang "Moldavian virus"? Kung bigla kang naging hacker at pumunta sa aking Kubernetes cluster, kami, mahihirap na administrator, ay magtatanong: "Pakilagay sa iyong mga pod kung saan mo iha-hack ang aking cluster, tumakbo bilang hindi ugat. Kung hindi, mangyayari na patakbuhin mo ang proseso sa iyong pod sa ilalim ng root, at magiging napakadali para sa iyo na i-hack ako. Mangyaring protektahan ang iyong sarili mula sa iyong sarili."
Ang dami ng landas ng host ay, sa palagay ko, ang pinakamabilis na paraan upang makuha ang ninanais na resulta mula sa isang kumpol ng Kubernetes.
Ngunit ano ang gagawin sa lahat ng ito?
Ang iniisip na dapat dumating sa sinumang normal na administrator na makakatagpo ng Kubernetes ay: “Oo, sinabi ko sa iyo, hindi gumagana ang Kubernetes. May mga butas ito. At ang buong Cube ay kalokohan." Sa katunayan, mayroong isang bagay tulad ng dokumentasyon, at kung titingnan mo doon, mayroong isang seksyon .
Isa itong yaml object - magagawa natin ito sa Kubernetes cluster - na kumokontrol sa mga aspeto ng seguridad partikular sa paglalarawan ng mga pod. Iyon ay, sa katunayan, kinokontrol nito ang mga karapatang gumamit ng anumang hostNetwork, hostPID, ilang partikular na uri ng volume na nasa mga pod sa startup. Sa tulong ng Pod Security Policy, mailalarawan ang lahat ng ito.
Ang pinaka-kagiliw-giliw na bagay tungkol sa Pod Security Policy ay na sa Kubernetes cluster, ang lahat ng PSP installer ay hindi lamang inilarawan sa anumang paraan, sila ay hindi pinagana bilang default. Ang Pod Security Policy ay pinagana gamit ang admission plugin.
Okay, i-deploy natin ang Pod Security Policy sa cluster, sabihin nating mayroon tayong ilang service pod sa namespace, kung saan ang mga admin lang ang may access. Sabihin nating, sa lahat ng iba pang mga kaso, ang mga pod ay may limitadong mga karapatan. Dahil malamang na hindi kailangan ng mga developer na magpatakbo ng mga privileged pod sa iyong cluster.
At mukhang maayos na ang lahat sa amin. At hindi ma-hack ang aming Kubernetes cluster sa loob ng dalawang minuto.
May problema. Malamang, kung mayroon kang Kubernetes cluster, naka-install ang pagsubaybay sa iyong cluster. I would even go so far as to predict na kung may monitoring ang cluster mo, tatawagin itong Prometheus.
Ang sasabihin ko sa iyo ay magiging wasto para sa operator ng Prometheus at Prometheus na inihatid sa purong anyo nito. Ang tanong ay kung hindi ako makakapagpasok ng isang admin sa cluster nang napakabilis, nangangahulugan ito na kailangan kong maghanap pa. At maaari akong maghanap sa tulong ng iyong pagsubaybay.
Marahil lahat ay nagbabasa ng parehong mga artikulo sa Habré, at ang pagsubaybay ay matatagpuan sa namespace ng pagsubaybay. Ang Helm chart ay tinatawag na halos pareho para sa lahat. Sa palagay ko, kung gagawin mo ang helm install stable/prometheus, magkakaroon ka ng halos parehong mga pangalan. At malamang na hindi ko na kailangang hulaan ang pangalan ng DNS sa iyong kumpol. Dahil ito ay pamantayan.
Susunod, mayroon kaming isang partikular na dev ns, kung saan maaari kang magpatakbo ng isang partikular na pod. At pagkatapos ay mula sa pod na ito napakadaling gawin ang isang bagay tulad nito:
$ curl http://prometheus-kube-state-metrics.monitoring Ang prometheus-kube-state-metrics ay isa sa mga Prometheus exporter na nangongolekta ng mga sukatan mula sa Kubernetes API mismo. Mayroong maraming data doon, kung ano ang tumatakbo sa iyong kumpol, kung ano ito, kung ano ang mga problema mo dito.
Bilang isang simpleng halimbawa:
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
Sa pamamagitan ng paggawa ng simpleng curl request mula sa isang unprivileged pod, makukuha mo ang sumusunod na impormasyon. Kung hindi mo alam kung anong bersyon ng Kubernetes ang iyong pinapatakbo, madali nitong sasabihin sa iyo.
At ang pinaka-kagiliw-giliw na bagay ay na bilang karagdagan sa pag-access sa kube-state-metrics, madali mong ma-access ang Prometheus mismo nang direkta. Maaari kang mangolekta ng mga sukatan mula doon. Maaari ka ring bumuo ng mga sukatan mula doon. Kahit na ayon sa teorya, maaari kang bumuo ng ganoong query mula sa isang cluster sa Prometheus, na i-off lang ito. At ang iyong pagsubaybay ay titigil sa paggana mula sa cluster nang buo.
At dito lumalabas ang tanong kung sinusubaybayan ng anumang panlabas na pagsubaybay ang iyong pagsubaybay. Nakuha ko lang ang pagkakataong magpatakbo sa isang kumpol ng Kubernetes nang walang anumang kahihinatnan para sa aking sarili. Hindi mo malalaman na nag-o-operate ako doon, dahil wala nang monitoring.
Tulad ng sa PSP, parang ang problema ay ang lahat ng mga magarbong teknolohiyang ito - Kubernetes, Prometheus - hindi lang gumagana at puno ng mga butas. Hindi naman.
May ganoong bagay - .
Kung ikaw ay isang normal na admin, malamang na alam mo ang tungkol sa Patakaran sa Network na ito ay isa pang yaml, kung saan marami na ang mga ito sa cluster. At tiyak na hindi kailangan ang ilang Patakaran sa Network. At kahit na basahin mo kung ano ang Patakaran sa Network, na ito ay isang yaml firewall ng Kubernetes, pinapayagan ka nitong limitahan ang mga karapatan sa pag-access sa pagitan ng mga namespace, sa pagitan ng mga pod, at tiyak na nagpasya kang ang firewall sa yaml na format sa Kubernetes ay batay sa mga susunod na abstraction ... Hindi, hindi . Ito ay tiyak na hindi kinakailangan.
Kahit na hindi mo sinabi sa iyong mga espesyalista sa seguridad na gamit ang iyong mga Kubernetes maaari kang bumuo ng isang napakadali at simpleng firewall, at isang napaka-butil na firewall. Kung hindi pa nila alam ito at hindi ka na aabalahin: “Well, give me, give me...” At sa anumang kaso, kailangan mo ng Network Policy para harangan ang access sa ilang lugar ng serbisyo na maaaring makuha mula sa iyong cluster nang walang anumang pahintulot.
Gaya sa halimbawang ibinigay ko, maaari kang kumuha ng mga sukatan ng estado ng kube mula sa anumang namespace sa cluster ng Kubernetes nang walang anumang mga karapatan na gawin ito. Ang mga patakaran sa network ay nagsara ng pag-access mula sa lahat ng iba pang mga namespace sa pagsubaybay sa namespace at iyon lang: walang access, walang mga problema. Sa lahat ng mga chart na umiiral, pareho ang karaniwang Prometheus at ang Prometheus na nasa operator, mayroon lamang isang opsyon sa mga halaga ng timon upang paganahin lamang ang mga patakaran ng network para sa kanila. Kailangan mo lamang itong i-on at gagana ang mga ito.
Mayroon talagang isang problema dito. Bilang isang normal na may balbas na admin, malamang na nagpasya kang hindi kailangan ang mga patakaran sa network. At pagkatapos basahin ang lahat ng uri ng mga artikulo sa mga mapagkukunan tulad ng Habr, napagpasyahan mo na ang flannel, lalo na sa host-gateway mode, ay ang pinakamagandang bagay na maaari mong piliin.
Ano ang dapat gawin?
Maaari mong subukang i-redeploy ang network solution na mayroon ka sa iyong Kubernetes cluster, subukang palitan ito ng mas functional. Para sa parehong Calico, halimbawa. Ngunit gusto kong sabihin kaagad na ang gawain ng pagpapalit ng solusyon sa network sa isang Kubernetes working cluster ay medyo hindi mahalaga. Nalutas ko ito nang dalawang beses (parehong beses, gayunpaman, ayon sa teorya), ngunit ipinakita pa namin kung paano ito gagawin sa Slurms. Para sa aming mga mag-aaral, ipinakita namin kung paano baguhin ang solusyon sa network sa isang cluster ng Kubernetes. Sa prinsipyo, maaari mong subukang tiyakin na walang downtime sa cluster ng produksyon. Ngunit malamang na hindi ka magtatagumpay.
At ang problema ay talagang nalutas nang napakasimple. May mga certificate sa cluster, at alam mong mag-e-expire ang iyong mga certificate sa loob ng isang taon. Well, at kadalasan ay isang normal na solusyon na may mga certificate sa cluster - bakit tayo nag-aalala, magtataas tayo ng bagong cluster sa malapit, hahayaan ang luma na mabulok, at muling i-deploy ang lahat. Totoo, kapag ito ay bulok, kailangan nating umupo nang isang araw, ngunit narito ang isang bagong kumpol.
Kapag nagtaas ka ng bagong cluster, sabay na ilagay ang Calico sa halip na flannel.
Ano ang gagawin kung ang iyong mga sertipiko ay naibigay sa loob ng isang daang taon at hindi mo na muling ipapatupad ang kumpol? Mayroong isang bagay tulad ng Kube-RBAC-Proxy. Ito ay isang napaka-cool na pag-unlad, ito ay nagbibigay-daan sa iyong i-embed ang sarili bilang isang sidecar container sa anumang pod sa Kubernetes cluster. At talagang nagdaragdag ito ng pahintulot sa pod na ito sa pamamagitan ng RBAC ng Kubernetes mismo.
May isang problema. Noong nakaraan, ang Kube-RBAC-Proxy na solusyon na ito ay binuo sa Prometheus ng operator. Ngunit pagkatapos ay wala na siya. Ngayon ang mga modernong bersyon ay umaasa sa katotohanan na mayroon kang patakaran sa network at isara ito gamit ang mga ito. At samakatuwid kakailanganin nating muling isulat ang tsart nang kaunti. Sa katunayan, kung pupunta ka sa , may mga halimbawa kung paano ito gamitin bilang mga sidecar, at ang mga chart ay kailangang maisulat muli nang minimal.
May isa pang maliit na problema. Hindi lang si Prometheus ang namimigay ng mga sukatan nito sa sinuman. Lahat ng aming Kubernetes cluster component ay nakakapagbalik din ng sarili nilang mga sukatan.
Ngunit tulad ng sinabi ko na, kung hindi mo ma-access ang kumpol at mangolekta ng impormasyon, maaari kang gumawa ng ilang pinsala.
Kaya mabilis akong magpapakita ng dalawang paraan kung paano masisira ang isang Kubernetes cluster.
Matatawa ka kapag sinabi ko sa iyo ito, ito ay dalawang kaso sa totoong buhay.
Pamamaraan isa. Pagkaunti ng mga likas na yaman.
Maglunsad tayo ng isa pang espesyal na pod. Magkakaroon ito ng section na ganito.
resources:
requests:
cpu: 4
memory: 4Gi Tulad ng alam mo, ang mga kahilingan ay ang dami ng CPU at memorya na nakalaan sa host para sa mga partikular na pod na may mga kahilingan. Kung mayroon kaming four-core host sa isang Kubernetes cluster, at apat na CPU pod ang dumating doon na may mga kahilingan, nangangahulugan ito na wala nang mga pod na may mga kahilingan ang makakarating sa host na ito.
Kung magpapatakbo ako ng ganoong pod, patakbuhin ko ang utos:
$ kubectl scale special-pod --replicas=...Pagkatapos ay walang ibang makakapag-deploy sa cluster ng Kubernetes. Dahil ang lahat ng mga node ay mauubusan ng mga kahilingan. At sa gayon ay ititigil ko ang iyong Kubernetes cluster. Kung gagawin ko ito sa gabi, maaari kong ihinto ang mga deployment sa loob ng mahabang panahon.
Kung titingnan natin muli ang dokumentasyon ng Kubernetes, makikita natin ang bagay na ito na tinatawag na Limit Range. Nagtatakda ito ng mga mapagkukunan para sa mga bagay na kumpol. Maaari kang magsulat ng Limit Range object sa yaml, ilapat ito sa ilang mga namespace - at pagkatapos sa namespace na ito maaari mong sabihin na mayroon kang default, maximum at minimum na mapagkukunan para sa mga pod.
Sa tulong ng ganoong bagay, maaari naming limitahan ang mga user sa mga partikular na namespace ng produkto ng mga team sa kakayahang magpahiwatig ng lahat ng uri ng masasamang bagay sa kanilang mga pod. Ngunit sa kasamaang-palad, kahit na sabihin mo sa user na hindi sila makakapaglunsad ng mga pod na may mga kahilingan para sa higit sa isang CPU, mayroong napakagandang utos ng sukat, o maaari silang mag-scale sa pamamagitan ng dashboard.
At dito nagmula ang paraan ng numero ng dalawa. Naglulunsad kami ng 11 pod. Labing-isang bilyon iyon. Ito ay hindi dahil nakaisip ako ng ganoong numero, ngunit dahil ako mismo ang nakakita nito.
Tunay na kuwento. Kinagabihan ay malapit na akong lumabas ng opisina. Nakikita ko ang isang grupo ng mga developer na nakaupo sa sulok, galit na galit na gumagawa ng isang bagay gamit ang kanilang mga laptop. Lumapit ako sa mga lalaki at tinanong: "Ano ang nangyari sa iyo?"
Medyo kanina, bandang alas nuwebe ng gabi, naghahanda na ang isa sa mga developer para umuwi. At nagpasya ako: "I-scale ko na ngayon ang aking aplikasyon sa isa." Pinindot ko ang isa, ngunit medyo bumagal ang Internet. Pinindot niya ulit ang isa, pinindot niya ang isa, at pinindot ang Enter. Sinundot ko ang lahat ng aking makakaya. Pagkatapos ay nabuhay ang Internet - at ang lahat ay nagsimulang bumaba sa numerong ito.
Totoo, ang kuwentong ito ay hindi naganap sa Kubernetes; sa oras na iyon ito ay Nomad. Nagtapos ito sa katotohanan na pagkatapos ng isang oras ng aming mga pagtatangka na pigilan si Nomad mula sa patuloy na pagtatangka sa pag-scale, sumagot si Nomad na hindi siya titigil sa pag-scale at hindi na gagawa ng iba pa. "Pagod na ako, aalis na ako." At pumulupot siya.
Naturally, sinubukan kong gawin ang parehong sa Kubernetes. Hindi natuwa si Kubernetes sa labing-isang bilyong pods, sinabi niya: “I can’t. Lumalampas sa panloob na mga bantay sa bibig." Ngunit maaaring 1 pod.
Bilang tugon sa isang bilyon, ang Cube ay hindi nag-withdraw sa sarili nito. Nagsimula na talaga siyang mag-scale. Habang tumatagal ang proseso, mas maraming oras ang inabot niya para gumawa ng mga bagong pod. Ngunit nagpatuloy pa rin ang proseso. Ang tanging problema ay kung makakapaglunsad ako ng mga pod nang walang limitasyon sa aking namespace, kung gayon kahit na walang mga kahilingan at limitasyon ay maaari akong maglunsad ng napakaraming pod na may ilang mga gawain na sa tulong ng mga gawaing ito ay magsisimulang magdagdag ang mga node sa memorya, sa CPU. Kapag naglunsad ako ng napakaraming pod, ang impormasyon mula sa kanila ay dapat mapunta sa imbakan, iyon ay, atbp. At kapag masyadong maraming impormasyon ang dumating doon, ang imbakan ay nagsisimulang bumalik nang masyadong mabagal - at ang Kubernetes ay nagsisimulang maging mapurol.
At isa pang problema... Tulad ng alam mo, ang mga elemento ng kontrol ng Kubernetes ay hindi isang pangunahing bagay, ngunit maraming mga bahagi. Sa partikular, mayroong isang controller manager, scheduler, at iba pa. Ang lahat ng mga taong ito ay magsisimulang gumawa ng hindi kailangan, hangal na trabaho sa parehong oras, na sa paglipas ng panahon ay magsisimulang tumagal ng mas maraming oras. Ang controller manager ay gagawa ng mga bagong pod. Susubukan ng scheduler na maghanap ng bagong node para sa kanila. Malamang na maubusan ka ng mga bagong node sa iyong cluster sa lalong madaling panahon. Ang Kubernetes cluster ay magsisimulang gumana nang mas mabagal at mas mabagal.
Pero nagpasya akong lumayo pa. Tulad ng alam mo, sa Kubernetes mayroong isang bagay na tinatawag na serbisyo. Well, bilang default sa iyong mga kumpol, malamang, gumagana ang serbisyo gamit ang mga IP table.
Kung magpapatakbo ka ng isang bilyong pod, halimbawa, at pagkatapos ay gumamit ng script para pilitin ang Kubernetis na gumawa ng mga bagong serbisyo:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Sa lahat ng node ng cluster, parami nang parami ang mga bagong panuntunan ng iptables na bubuo ng humigit-kumulang sabay-sabay. Bukod dito, bubuo ng isang bilyong panuntunan ng iptables para sa bawat serbisyo.
Sinuri ko ang buong bagay na ito sa ilang libo, hanggang sampu. At ang problema ay nasa threshold na ito medyo may problemang gawin ang ssh sa node. Dahil ang mga pakete, na dumadaan sa napakaraming kadena, ay nagsisimulang makaramdam ng hindi maganda.
At ito rin, lahat ay nalutas sa tulong ng Kubernetes. Mayroong ganoong object ng Resource quota. Itinatakda ang bilang ng mga magagamit na mapagkukunan at mga bagay para sa namespace sa cluster. Maaari tayong gumawa ng yaml object sa bawat namespace ng Kubernetes cluster. Gamit ang bagay na ito, masasabi nating mayroon tayong tiyak na bilang ng mga kahilingan at limitasyon na inilalaan para sa namespace na ito, at pagkatapos ay masasabi nating sa namespace na ito posible na lumikha ng 10 serbisyo at 10 pod. At ang nag-iisang developer ay maaaring mabulunan man lang ang sarili sa gabi. Sasabihin sa kanya ng Kubernetes: "Hindi mo maaaring sukatin ang iyong mga pod sa halagang iyon, dahil ang mapagkukunan ay lumampas sa quota." Iyon lang, nalutas ang problema. .
Isang problemang punto ang lumitaw sa bagay na ito. Nararamdaman mo kung gaano kahirap na gumawa ng namespace sa Kubernetes. Upang malikha ito, kailangan nating isaalang-alang ang maraming bagay.
Quota ng mapagkukunan + Saklaw ng Limitasyon + RBAC
• Gumawa ng namespace
• Gumawa ng limitrange sa loob
• Lumikha sa loob ng resourcequota
• Gumawa ng serviceaccount para sa CI
• Gumawa ng rolebinding para sa CI at mga user
• Opsyonal na ilunsad ang mga kinakailangang service pod
Samakatuwid, nais kong gamitin ang pagkakataong ito upang ibahagi ang aking mga pag-unlad. Mayroong isang bagay na tinatawag na SDK operator. Ito ay isang paraan para sa isang Kubernetes cluster na magsulat ng mga operator para dito. Maaari kang sumulat ng mga pahayag gamit ang Ansible.
Sa una ito ay nakasulat sa Ansible, at pagkatapos ay nakita ko na mayroong isang SDK operator at muling isinulat ang papel na Ansible sa isang operator. Binibigyang-daan ka ng pahayag na ito na lumikha ng isang bagay sa cluster ng Kubernetes na tinatawag na command. Sa loob ng isang utos, pinapayagan ka nitong ilarawan ang kapaligiran para sa utos na ito sa yaml. At sa loob ng kapaligiran ng koponan, pinapayagan kaming ilarawan na naglalaan kami ng napakaraming mapagkukunan.
Little one .
At sa konklusyon. Ano ang gagawin sa lahat ng ito?
Una. Maganda ang Pod Security Policy. At sa kabila ng katotohanang wala sa mga installer ng Kubernetes ang gumagamit nito hanggang ngayon, kailangan mo pa ring gamitin ang mga ito sa iyong mga cluster.
Ang Patakaran sa Network ay hindi lamang isa pang hindi kinakailangang tampok. Ito ang talagang kailangan sa isang kumpol.
LimitRange/ResourceQuota - oras na para gamitin ito. Matagal na naming sinimulan itong gamitin, at sa loob ng mahabang panahon sigurado akong ginagamit ito ng lahat. Ito pala ay bihira.
Bilang karagdagan sa aking nabanggit sa panahon ng ulat, may mga hindi dokumentadong tampok na nagbibigay-daan sa iyo upang atakehin ang kumpol. Inilabas kamakailan .
May mga bagay na sobrang nakakalungkot at nakakasakit. Halimbawa, sa ilalim ng ilang partikular na kundisyon, ang mga cubelet sa isang Kubernetes cluster ay maaaring magbigay ng mga nilalaman ng direktoryo ng warlocks sa isang hindi awtorisadong user.
May mga tagubilin kung paano i-reproduce ang lahat ng sinabi ko sa iyo. May mga file na may mga halimbawa ng produksyon kung ano ang hitsura ng ResourceQuota at Pod Security Policy. At maaari mong hawakan ang lahat ng ito.
Salamat sa lahat.
Pinagmulan: www.habr.com