Pavel Selivanov, mbunifu wa Southbridge solutions na mwalimu wa Slurm, alitoa wasilisho katika DevOpsConf 2019. Mazungumzo haya ni sehemu ya mojawapo ya mada za kozi ya kina kuhusu Kubernetes "Slurm Mega".
hufanyika huko Moscow mnamo Novemba 18-20.
- Moscow, Novemba 22-24.
inapatikana kila wakati.
Chini ya kata ni nakala ya ripoti.
Mchana mzuri, wenzako na wale wanaowahurumia. Leo nitazungumzia usalama.
Naona kuna walinzi wengi ukumbini leo. Ninakuomba msamaha mapema ikiwa nitatumia masharti kutoka kwa ulimwengu wa usalama sio kama kawaida kwako.
Ilifanyika kwamba kama miezi sita iliyopita nilikutana na nguzo moja ya umma ya Kubernetes. Umma inamaanisha kuwa kuna idadi ya nth ya nafasi za majina; katika nafasi hizi za majina kuna watumiaji waliotengwa katika nafasi zao za majina. Watumiaji hawa wote ni wa makampuni tofauti. Kweli, ilichukuliwa kuwa nguzo hii inapaswa kutumika kama CDN. Hiyo ni, wanakupa nguzo, wanakupa mtumiaji huko, unaenda huko kwenye nafasi yako ya majina, peleka pande zako.
Kampuni yangu ya awali ilijaribu kuuza huduma kama hiyo. Na niliulizwa kupiga nguzo ili kuona ikiwa suluhisho hili linafaa au la.
Nilikuja kwenye kundi hili. Nilipewa haki chache, nafasi ndogo ya majina. Vijana pale walielewa usalama ni nini. Walisoma kuhusu Udhibiti wa Ufikiaji wa Wajibu (RBAC) katika Kubernetes - na waliupindisha ili nisiweze kuzindua maganda kando na usambazaji. Sikumbuki shida niliyokuwa nikijaribu kutatua kwa kuzindua ganda bila kupelekwa, lakini kwa kweli nilitaka kuzindua ganda tu. Kwa bahati nzuri, niliamua kuona ni haki gani ninazo kwenye kundi, ninachoweza kufanya, kile ambacho siwezi kufanya, na kile ambacho wamekiharibu hapo. Wakati huo huo, nitakuambia kile ambacho wamesanidi vibaya katika RBAC.
Ilifanyika kwamba katika dakika mbili nilipokea admin kwa nguzo yao, nikatazama nafasi zote za majina ya jirani, nikaona pale maeneo ya uzalishaji wa makampuni ambayo tayari yamenunua huduma na kupelekwa. Sikuweza kujizuia kwenda mbele ya mtu na kuweka neno la matusi kwenye ukurasa kuu.
Nitakuambia kwa mifano jinsi nilifanya hivyo na jinsi ya kujikinga na hili.
Lakini kwanza, acha nijitambulishe. Jina langu ni Pavel Selivanov. Mimi ni mbunifu huko Southbridge. Ninaelewa Kubernetes, DevOps na kila aina ya vitu vya kupendeza. Wahandisi wa Southbridge na mimi tunaunda haya yote, na ninashauriana.
Mbali na shughuli zetu kuu, hivi karibuni tumezindua miradi inayoitwa Slurms. Tunajaribu kuleta uwezo wetu wa kufanya kazi na Kubernetes kidogo kwa umati, kuwafundisha watu wengine pia kufanya kazi na K8.
Nitazungumza nini leo? Mada ya ripoti ni dhahiri - kuhusu usalama wa nguzo ya Kubernetes. Lakini nataka kusema mara moja kwamba mada hii ni kubwa sana - na kwa hivyo nataka kufafanua mara moja kile ambacho hakika sitazungumza. Sitazungumza juu ya maneno ya hackneyed ambayo tayari yametumika mara mia kwenye mtandao. Kila aina ya RBAC na vyeti.
Nitazungumza kuhusu kile kinachoniumiza mimi na wenzangu kuhusu usalama katika kundi la Kubernetes. Tunaona matatizo haya kati ya watoa huduma wanaotoa makundi ya Kubernetes na miongoni mwa wateja wanaokuja kwetu. Na hata kutoka kwa wateja wanaokuja kwetu kutoka kwa kampuni zingine za wasimamizi wa ushauri. Yaani ukubwa wa mkasa kwa kweli ni mkubwa sana.
Kuna mambo matatu ambayo nitazungumzia leo:
- Haki za mtumiaji dhidi ya haki za pod. Haki za mtumiaji na haki za pod si kitu sawa.
- Kukusanya taarifa kuhusu nguzo. Nitaonyesha kwamba unaweza kukusanya taarifa zote unazohitaji kutoka kwa kundi bila kuwa na haki maalum katika kundi hili.
- Shambulio la DoS kwenye nguzo. Ikiwa hatuwezi kukusanya habari, tutaweza kuweka nguzo kwa hali yoyote. Nitazungumza kuhusu mashambulizi ya DoS kwenye vipengele vya udhibiti wa nguzo.
Jambo lingine la jumla ambalo nitataja ni kile nilijaribu haya yote, ambayo naweza kusema kwa hakika kuwa yote yanafanya kazi.
Tunachukua kama msingi usakinishaji wa nguzo ya Kubernetes kwa kutumia Kubespray. Ikiwa mtu yeyote hajui, hii ni seti ya majukumu ya Ansible. Tunaitumia mara kwa mara katika kazi zetu. Jambo jema ni kwamba unaweza kuikunja mahali popote - unaweza kuikunja kwenye vipande vya chuma au kwenye wingu mahali fulani. Njia moja ya ufungaji inafanya kazi kwa kanuni kwa kila kitu.
Katika kundi hili nitakuwa na Kubernetes v1.14.5. Kundi zima la Mchemraba, ambalo tutazingatia, limegawanywa katika nafasi za majina, kila nafasi ya majina ni ya timu tofauti, na washiriki wa timu hii wanaweza kufikia kila nafasi ya majina. Hawawezi kwenda kwa nafasi tofauti za majina, kwao tu. Lakini kuna akaunti fulani ya msimamizi ambayo ina haki kwa kikundi kizima.
Niliahidi kwamba jambo la kwanza tutakalofanya ni kupata haki za msimamizi kwa nguzo. Tunahitaji ganda maalum ambalo litavunja nguzo ya Kubernetes. Tunachohitaji kufanya ni kuitumia kwa nguzo ya Kubernetes.
kubectl apply -f pod.yamlPonda hili litafika kwa mmoja wa mabwana wa nguzo ya Kubernetes. Na baada ya hii nguzo itaturudishia faili inayoitwa admin.conf kwa furaha. Katika Cube, faili hii huhifadhi vyeti vyote vya msimamizi, na wakati huo huo husanidi API ya nguzo. Hivi ndivyo ilivyo rahisi kupata ufikiaji wa msimamizi, nadhani, 98% ya vikundi vya Kubernetes.
Narudia, ganda hili lilitengenezwa na msanidi programu katika nguzo yako ambaye ana uwezo wa kupeleka mapendekezo yake katika nafasi moja ndogo ya majina, yote yamebanwa na RBAC. Hakuwa na haki. Lakini hata hivyo cheti kilirudishwa.
Na sasa kuhusu pod iliyoandaliwa maalum. Tunaendesha kwenye picha yoyote. Wacha tuchukue debian:jessie kama mfano.
Tunayo jambo hili:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Uvumilivu ni nini? Masters katika kundi la Kubernetes kawaida huwekwa alama ya kitu kinachoitwa taint. Na kiini cha "maambukizi" haya ni kwamba inasema kwamba pods haziwezi kupewa nodes za bwana. Lakini hakuna mtu anayejisumbua kuonyesha katika pod yoyote kwamba ni uvumilivu kwa "maambukizi". Sehemu ya Kuvumiliana inasema tu kwamba ikiwa node fulani ina NoSchedule, basi node yetu inastahimili maambukizi hayo - na hakuna matatizo.
Zaidi ya hayo, tunasema kwamba chini yetu sio tu ya kuvumilia, lakini pia inataka kulenga hasa bwana. Kwa sababu mabwana wana jambo la ladha zaidi tunalohitaji - vyeti vyote. Kwa hivyo, tunasema nodeSelector - na tunayo lebo ya kawaida kwenye mabwana, ambayo hukuruhusu kuchagua kutoka kwa nodi zote kwenye nguzo haswa nodi hizo ambazo ni mabwana.
Kwa sehemu hizi mbili hakika atakuja kwa bwana. Na ataruhusiwa kuishi huko.
Lakini kuja tu kwa bwana haitoshi kwetu. Hii haitatupa chochote. Kwa hivyo, tunayo mambo mawili yafuatayo:
hostNetwork: true
hostPID: true Tunabainisha kuwa ganda letu, ambalo tunazindua, litaishi katika nafasi ya majina ya kernel, katika nafasi ya majina ya mtandao, na katika nafasi ya majina ya PID. Mara tu ganda limezinduliwa kwa bwana, litaweza kuona miingiliano yote halisi, ya moja kwa moja ya nodi hii, kusikiliza trafiki yote na kuona PID ya michakato yote.
Kisha ni suala la mambo madogo. Chukua etcd na usome unachotaka.
Jambo la kuvutia zaidi ni kipengele hiki cha Kubernetes, ambacho kipo hapo kwa chaguo-msingi.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Na kiini chake ni kwamba tunaweza kusema kwenye ganda ambalo tunazindua, hata bila haki kwa nguzo hii, kwamba tunataka kuunda kiasi cha aina ya hostPath. Hii inamaanisha kuchukua njia kutoka kwa seva pangishi ambayo tutazindua - na kuichukua kama sauti. Na kisha tunaiita jina: mwenyeji. Tunaweka Njia hii ya mwenyeji ndani ya ganda. Katika mfano huu, kwa saraka ya mwenyeji.
Nitairudia tena. Tuliiambia ganda kuja kwa bwana, kupata hostNetwork na hostPID huko - na kuweka mzizi mzima wa bwana ndani ya ganda hili.
Unaelewa kuwa katika Debian tuna bash inayoendesha, na bash hii inaendesha chini ya mizizi. Hiyo ni, tumepokea mzizi kwa bwana, bila kuwa na haki yoyote katika nguzo ya Kubernetes.
Kisha kazi yote ni kwenda kwenye saraka ndogo / mwenyeji /etc/kubernetes/pki, ikiwa sijakosea, chukua vyeti vyote vikuu vya nguzo hapo na, ipasavyo, kuwa msimamizi wa nguzo.
Ukiiangalia kwa njia hii, hizi ni baadhi ya haki hatari zaidi katika ganda - bila kujali ni haki gani mtumiaji anayo:
Ikiwa nina haki ya kuendesha ganda katika nafasi fulani ya jina la nguzo, basi ganda hili lina haki hizi kwa chaguo-msingi. Ninaweza kuendesha maganda ya upendeleo, na hizi kwa ujumla ni haki zote, kwa kweli mizizi kwenye nodi.
Ninachopenda ni mtumiaji wa Mizizi. Na Kubernetes ina chaguo hili la Run As Non-Root. Hii ni aina ya ulinzi kutoka kwa hacker. Je! unajua "virusi vya Moldavian" ni nini? Ikiwa wewe ni mdukuzi ghafla na unakuja kwenye nguzo yangu ya Kubernetes, basi sisi, wasimamizi maskini, tunauliza: "Tafadhali onyesha kwenye maganda yako ambayo utavamia nguzo yangu, kukimbia kama isiyo na mizizi. Vinginevyo, itatokea kwamba utaendesha mchakato kwenye ganda lako chini ya mizizi, na itakuwa rahisi sana kwako kuniteka. Tafadhali jilinde dhidi yako mwenyewe."
Kiasi cha njia ya mwenyeji ni, kwa maoni yangu, njia ya haraka zaidi ya kupata matokeo unayotaka kutoka kwa nguzo ya Kubernetes.
Lakini nini cha kufanya na haya yote?
Wazo ambalo linapaswa kuja kwa msimamizi yeyote wa kawaida ambaye hukutana na Kubernetes ni: "Ndio, nilikuambia, Kubernetes haifanyi kazi. Kuna mashimo ndani yake. Na Mchemraba wote ni ujinga." Kwa kweli, kuna kitu kama hati, na ukiangalia hapo, kuna sehemu .
Hiki ni kitu cha yaml - tunaweza kukiunda katika nguzo ya Kubernetes - ambayo inadhibiti vipengele vya usalama hasa katika maelezo ya maganda. Hiyo ni, kwa kweli, inadhibiti haki za kutumia hostNetwork yoyote, hostPID, aina fulani za sauti ambazo ziko kwenye maganda wakati wa kuanza. Kwa msaada wa Sera ya Usalama wa Pod, yote haya yanaweza kuelezewa.
Jambo la kufurahisha zaidi kuhusu Sera ya Usalama ya Pod ni kwamba katika nguzo ya Kubernetes, wasakinishaji wote wa PSP hawajaelezewa tu kwa njia yoyote, wamezimwa tu kwa chaguo-msingi. Sera ya Usalama ya Pod imewashwa kwa kutumia programu-jalizi ya uandikishaji.
Sawa, hebu tuweke Sera ya Usalama ya Pod kwenye nguzo, tuseme kwamba tunayo maganda ya huduma kwenye nafasi ya majina, ambayo wasimamizi pekee ndio wanaoweza kufikia. Wacha tuseme, katika visa vingine vyote, maganda yana haki ndogo. Kwa sababu uwezekano mkubwa wa wasanidi programu hawahitaji kuendesha maganda ya upendeleo kwenye kundi lako.
Na kila kitu kinaonekana kuwa sawa na sisi. Na nguzo yetu ya Kubernetes haiwezi kudukuliwa kwa dakika mbili.
Kuna tatizo. Uwezekano mkubwa zaidi, ikiwa una kikundi cha Kubernetes, basi ufuatiliaji umewekwa kwenye nguzo yako. Ningeenda mbali zaidi kutabiri kwamba ikiwa nguzo yako ina ufuatiliaji, itaitwa Prometheus.
Ninachotaka kukuambia kitakuwa halali kwa mwendeshaji wa Prometheus na Prometheus iliyotolewa katika hali yake safi. Swali ni kwamba ikiwa siwezi kupata msimamizi kwenye nguzo haraka sana, basi hii inamaanisha kuwa ninahitaji kuangalia zaidi. Na ninaweza kutafuta kwa usaidizi wa ufuatiliaji wako.
Pengine kila mtu alisoma makala sawa kuhusu Habré, na ufuatiliaji unapatikana katika nafasi ya majina ya ufuatiliaji. Chati ya usukani inaitwa takribani sawa kwa kila mtu. Ninadhania kuwa ukifanya helm install stable/prometheus, utaishia na takriban majina yale yale. Na uwezekano mkubwa sitalazimika hata kukisia jina la DNS kwenye nguzo yako. Kwa sababu ni kiwango.
Ifuatayo tunayo dev ns fulani, ambayo unaweza kuendesha ganda fulani. Na kisha kutoka kwa ganda hili ni rahisi sana kufanya kitu kama hiki:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics ni mmoja wa wasafirishaji wa Prometheus ambaye hukusanya vipimo kutoka kwa Kubernetes API yenyewe. Kuna data nyingi hapo, ni nini kinachoendesha kwenye nguzo yako, ni nini, una shida gani nayo.
Kama mfano rahisi:
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
Kwa kufanya ombi rahisi la curl kutoka kwa pod isiyo na upendeleo, unaweza kupata taarifa zifuatazo. Ikiwa hujui ni toleo gani la Kubernetes unaloendesha, itakuambia kwa urahisi.
Na jambo la kuvutia zaidi ni kwamba pamoja na kupata kube-state-metrics, unaweza kupata Prometheus yenyewe kwa urahisi moja kwa moja. Unaweza kukusanya vipimo kutoka hapo. Unaweza hata kuunda vipimo kutoka hapo. Hata kinadharia, unaweza kuunda swali kama hilo kutoka kwa nguzo huko Prometheus, ambayo itaizima tu. Na ufuatiliaji wako utaacha kufanya kazi kutoka kwa nguzo kabisa.
Na hapa swali linatokea ikiwa ufuatiliaji wowote wa nje unafuatilia ufuatiliaji wako. Nilipata fursa ya kufanya kazi katika kundi la Kubernetes bila matokeo yoyote kwangu. Huwezi hata kujua kwamba ninafanya kazi huko, kwa kuwa hakuna tena ufuatiliaji wowote.
Kama ilivyo kwa PSP, inahisi kama tatizo ni kwamba teknolojia hizi zote maridadi - Kubernetes, Prometheus - hazifanyi kazi na zimejaa mashimo. Si kweli.
Kuna kitu kama hicho - .
Ikiwa wewe ni msimamizi wa kawaida, basi uwezekano mkubwa unajua kuhusu Sera ya Mtandao kwamba hii ni yaml nyingine, ambayo tayari kuna mengi yao kwenye nguzo. Na baadhi ya Sera za Mtandao hakika hazihitajiki. Na hata ukisoma Sera ya Mtandao ni nini, kwamba ni firewall yaml ya Kubernetes, hukuruhusu kupunguza haki za ufikiaji kati ya nafasi za majina, kati ya maganda, basi hakika uliamua kuwa ukuta wa moto katika umbizo la yaml huko Kubernetes unategemea vifupisho vifuatavyo. ... Hapana, hapana. Hakika hii sio lazima.
Hata kama hukuwaambia wataalamu wako wa usalama kwamba kwa kutumia Kubernetes yako unaweza kutengeneza ngome rahisi na rahisi sana, na yenye punjepunje sana. Ikiwa bado hawajui hili na hawakusumbui: "Sawa, nipe, nipe ..." Kisha kwa hali yoyote, unahitaji Sera ya Mtandao ili kuzuia ufikiaji wa baadhi ya maeneo ya huduma ambayo yanaweza kuvutwa kutoka kwa nguzo yako. bila idhini yoyote.
Kama katika mfano nilioutoa, unaweza kuvuta vipimo vya hali ya kube kutoka kwa nafasi yoyote ya majina kwenye nguzo ya Kubernetes bila kuwa na haki yoyote ya kufanya hivyo. Sera za mtandao zimefunga ufikiaji kutoka kwa nafasi zingine zote za majina hadi nafasi ya majina ya ufuatiliaji na ndivyo hivyo: hakuna ufikiaji, hakuna shida. Katika chati zote zilizopo, Prometheus ya kawaida na Prometheus iliyo kwenye opereta, kuna chaguo tu katika maadili ya usukani ili kuwezesha sera za mtandao kwao. Unahitaji tu kuiwasha na watafanya kazi.
Kweli kuna tatizo moja hapa. Kwa kuwa ni msimamizi wa kawaida mwenye ndevu, kuna uwezekano mkubwa uliamua kuwa sera za mtandao hazihitajiki. Na baada ya kusoma kila aina ya makala kuhusu nyenzo kama Habr, uliamua kwamba flana, hasa kwa hali ya lango la mwenyeji, ndilo jambo bora zaidi unaweza kuchagua.
Nini cha kufanya?
Unaweza kujaribu kupeleka tena suluhisho la mtandao ambalo unalo kwenye kundi lako la Kubernetes, jaribu kulibadilisha na kitu kinachofanya kazi zaidi. Kwa Calico sawa, kwa mfano. Lakini nataka kusema mara moja kwamba kazi ya kubadilisha suluhisho la mtandao katika nguzo ya kazi ya Kubernetes sio ndogo sana. Niliitatua mara mbili (mara zote mbili, hata hivyo, kinadharia), lakini tulionyesha jinsi ya kuifanya kwenye Slurms. Kwa wanafunzi wetu, tulionyesha jinsi ya kubadilisha suluhu ya mtandao katika kundi la Kubernetes. Kimsingi, unaweza kujaribu kuhakikisha kuwa hakuna wakati wa kupumzika kwenye nguzo ya uzalishaji. Lakini labda hautafanikiwa.
Na tatizo ni kweli kutatuliwa kwa urahisi sana. Kuna vyeti kwenye nguzo, na unajua kwamba vyeti vyako vitaisha baada ya mwaka mmoja. Kweli, na kawaida suluhisho la kawaida na cheti kwenye nguzo - kwa nini tuna wasiwasi, tutainua nguzo mpya karibu, tuache ile ya zamani ioze, na kusambaza kila kitu tena. Kweli, inapooza, itabidi tukae kwa siku, lakini hapa kuna nguzo mpya.
Unapoinua nguzo mpya, wakati huo huo ingiza Calico badala ya flannel.
Nini cha kufanya ikiwa vyeti vyako vimetolewa kwa miaka mia moja na hautapeleka tena nguzo? Kuna kitu kama Kube-RBAC-Proxy. Hili ni jambo la kupendeza sana, hukuruhusu kujipachika yenyewe kama chombo cha kando kwa ganda lolote kwenye nguzo ya Kubernetes. Na kwa kweli inaongeza idhini kwa ganda hili kupitia RBAC ya Kubernetes yenyewe.
Kuna tatizo moja. Hapo awali, suluhisho hili la Kube-RBAC-Proksi lilijengwa kwenye Prometheus ya operator. Lakini basi alikuwa amekwenda. Sasa matoleo ya kisasa yanategemea ukweli kwamba una sera ya mtandao na uifunge ukitumia. Na kwa hivyo tutalazimika kuandika tena chati kidogo. Kwa kweli, ikiwa utaenda , kuna mifano ya jinsi ya kutumia hii kama kando, na chati zitalazimika kuandikwa upya kwa uchache.
Kuna shida moja ndogo zaidi. Prometheus sio pekee anayekabidhi metrics zake kwa mtu yeyote. Vipengee vyetu vyote vya Kubernetes pia vinaweza kurejesha vipimo vyake.
Lakini kama nilivyokwisha sema, ikiwa huwezi kufikia nguzo na kukusanya habari, basi unaweza angalau kufanya madhara.
Kwa hivyo nitaonyesha haraka njia mbili jinsi nguzo ya Kubernetes inaweza kuharibiwa.
Utacheka nikikuambia hivi, hizi ni kesi mbili za maisha halisi.
Mbinu ya kwanza. Upungufu wa rasilimali.
Wacha tuzindua ganda lingine maalum. Itakuwa na sehemu kama hii.
resources:
requests:
cpu: 4
memory: 4Gi Kama unavyojua, maombi ni kiasi cha CPU na kumbukumbu ambayo imehifadhiwa kwa seva pangishi kwa maganda maalum yenye maombi. Ikiwa tuna seva pangishi ya msingi nne katika kundi la Kubernetes, na maganda manne ya CPU yanafika hapo na maombi, inamaanisha kuwa hakuna maganda mengine yenye maombi yataweza kuja kwa seva pangishi hii.
Ikiwa nitaendesha ganda kama hilo, basi nitaendesha amri:
$ kubectl scale special-pod --replicas=...Kisha hakuna mtu mwingine atakayeweza kupeleka kwenye nguzo ya Kubernetes. Kwa sababu nodi zote zitaisha maombi. Na kwa hivyo nitasimamisha nguzo yako ya Kubernetes. Nikifanya hivi jioni, naweza kusimamisha utumaji kwa muda mrefu sana.
Ikiwa tutaangalia tena hati za Kubernetes, tutaona kitu hiki kinachoitwa Kiwango cha Kikomo. Inaweka rasilimali kwa vitu vya nguzo. Unaweza kuandika kitu cha Safu ya Kikomo katika yaml, kuitumia kwa nafasi fulani za majina - na kisha katika nafasi hii ya majina unaweza kusema kuwa una rasilimali chaguo-msingi, kiwango cha juu na cha chini zaidi kwa maganda.
Kwa usaidizi wa kitu kama hicho, tunaweza kuweka kikomo kwa watumiaji katika nafasi mahususi za majina ya bidhaa za timu katika uwezo wa kuonyesha kila aina ya vitu vibaya kwenye ganda zao. Lakini kwa bahati mbaya, hata ukimwambia mtumiaji kwamba hawezi kuzindua ganda na maombi ya CPU zaidi ya moja, kuna amri ya kiwango cha ajabu, au wanaweza kufanya ukubwa kupitia dashibodi.
Na hapa ndipo njia namba mbili inatoka. Tunazindua maganda 11. Hiyo ni bilioni kumi na moja. Hii sio kwa sababu nilikuja na nambari kama hiyo, lakini kwa sababu niliiona mwenyewe.
Hadithi ya kweli. Majira ya jioni nilikuwa karibu kuondoka ofisini. Ninaona kikundi cha watengenezaji wameketi kwenye kona, wakifanya kitu kwa bidii na kompyuta zao za mkononi. Ninaenda kwa wavulana na kuuliza: "Ni nini kilikupata?"
Mapema kidogo, karibu saa tisa jioni, mmoja wa watengenezaji alikuwa akijiandaa kwenda nyumbani. Na niliamua: "Sasa nitapunguza ombi langu hadi moja." Nilibonyeza moja, lakini Mtandao ulipungua kidogo. Akabonyeza tena, akabonyeza moja na kubofya Enter. Nilipiga kila nilichoweza. Kisha mtandao ukawa hai - na kila kitu kilianza kupungua hadi nambari hii.
Ukweli, hadithi hii haikufanyika Kubernetes; wakati huo ilikuwa Nomad. Ilimalizika na ukweli kwamba baada ya saa moja ya majaribio yetu ya kumzuia Nomad kutoka kwa majaribio ya kuendelea ya kuongeza kiwango, Nomad alijibu kwamba hataacha kuongeza na hatafanya chochote kingine. "Nimechoka, naondoka." Naye akajikunja.
Kwa kawaida, nilijaribu kufanya vivyo hivyo kwenye Kubernetes. Kubernetes hakufurahishwa na maganda ya bilioni kumi na moja, alisema: "Siwezi. Inazidi walinzi wa ndani wa kinywa." Lakini maganda 1 yanaweza.
Kwa kukabiliana na bilioni moja, Cube haikujiondoa yenyewe. Kweli alianza kuongeza. Kadiri mchakato ulivyoendelea, ndivyo ilichukua muda zaidi kuunda maganda mapya. Lakini bado mchakato uliendelea. Shida pekee ni kwamba ikiwa naweza kuzindua maganda bila kikomo kwenye nafasi yangu ya jina, basi hata bila maombi na mipaka naweza kuzindua maganda mengi na kazi kadhaa ambazo kwa msaada wa kazi hizi nodi zitaanza kuongezwa kwenye kumbukumbu, kwenye CPU. Ninapozindua maganda mengi, habari kutoka kwao inapaswa kwenda kwenye hifadhi, yaani, nk. Na habari nyingi zinapofika hapo, hifadhi huanza kurudi polepole sana - na Kubernetes huanza kuwa wepesi.
Na shida moja zaidi ... Kama unavyojua, vipengele vya udhibiti wa Kubernetes sio jambo moja kuu, lakini vipengele kadhaa. Hasa, kuna meneja wa mtawala, mpangilio, na kadhalika. Vijana hawa wote wataanza kufanya kazi isiyo ya lazima, ya kijinga kwa wakati mmoja, ambayo baada ya muda itaanza kuchukua muda zaidi na zaidi. Kidhibiti kidhibiti kitaunda maganda mapya. Mratibu atajaribu kutafuta nodi mpya kwao. Uwezekano mkubwa zaidi utaishiwa na nodi mpya kwenye nguzo yako hivi karibuni. Kundi la Kubernetes litaanza kufanya kazi polepole na polepole.
Lakini niliamua kwenda mbali zaidi. Kama unavyojua, huko Kubernetes kuna kitu kama huduma. Naam, kwa chaguo-msingi katika makundi yako, uwezekano mkubwa, huduma inafanya kazi kwa kutumia meza za IP.
Ukiendesha ganda bilioni moja, kwa mfano, na kisha utumie hati kulazimisha Kubernetis kuunda huduma mpya:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Kwenye nodi zote za nguzo, sheria zaidi na zaidi za iptables mpya zitatolewa takriban wakati huo huo. Zaidi ya hayo, sheria bilioni moja za iptables zitatolewa kwa kila huduma.
Niliangalia jambo hili lote kwenye elfu kadhaa, hadi kumi. Na shida ni kwamba tayari kwenye kizingiti hiki ni shida sana kufanya ssh kwa nodi. Kwa sababu pakiti, kupitia minyororo mingi, huanza kujisikia si nzuri sana.
Na hii, pia, yote inatatuliwa kwa msaada wa Kubernetes. Kuna kitu kama hiki cha mgao wa Rasilimali. Huweka idadi ya rasilimali na vitu vinavyopatikana kwa nafasi ya majina kwenye nguzo. Tunaweza kuunda kitu cha yaml katika kila nafasi ya majina ya nguzo ya Kubernetes. Kutumia kitu hiki, tunaweza kusema kwamba tuna idadi fulani ya maombi na mipaka iliyotengwa kwa nafasi hii ya jina, na kisha tunaweza kusema kwamba katika nafasi hii ya majina inawezekana kuunda huduma 10 na pods 10. Na msanidi programu mmoja anaweza angalau kujisonga jioni. Kubernetes atamwambia: "Huwezi kuongeza maganda yako hadi kiasi hicho, kwa sababu rasilimali inazidi kiwango." Hiyo ndiyo yote, shida imetatuliwa. .
Jambo moja la shida linatokea katika suala hili. Unahisi jinsi inavyokuwa vigumu kuunda nafasi ya majina katika Kubernetes. Ili kuunda, tunahitaji kuzingatia mambo mengi.
Kiasi cha rasilimali + Masafa ya Kikomo + RBAC
• Unda nafasi ya majina
• Unda mipaka ya ndani
• Unda ndani ya upendeleo wa rasilimali
• Unda akaunti ya huduma kwa CI
• Unda jukumu la CI na watumiaji
• Kwa hiari zindua maganda ya huduma muhimu
Kwa hiyo, ningependa kuchukua fursa hii kuchangia maendeleo yangu. Kuna kitu kama hicho kinachoitwa opereta wa SDK. Hii ni njia ya nguzo ya Kubernetes kuandika waendeshaji kwa ajili yake. Unaweza kuandika taarifa kwa kutumia Ansible.
Mwanzoni iliandikwa kwa Ansible, na kisha nikaona kwamba kulikuwa na opereta wa SDK na nikaandika upya jukumu la Ansible kuwa opereta. Taarifa hii hukuruhusu kuunda kitu kwenye nguzo ya Kubernetes inayoitwa amri. Ndani ya amri, hukuruhusu kuelezea mazingira ya amri hii katika yaml. Na ndani ya mazingira ya timu, huturuhusu kuelezea kuwa tunatenga rasilimali nyingi.
Kidogo .
Na kwa kumalizia. Nini cha kufanya na haya yote?
Kwanza. Sera ya Usalama wa Pod ni nzuri. Na licha ya ukweli kwamba hakuna hata mmoja wa wasakinishaji wa Kubernetes anayezitumia hadi leo, bado unahitaji kuzitumia kwenye vikundi vyako.
Sera ya Mtandao sio tu kipengele kingine kisichohitajika. Hiki ndicho kinachohitajika sana kwenye nguzo.
LimitRange/ResourceQuota - ni wakati wa kuitumia. Tulianza kutumia hii muda mrefu uliopita, na kwa muda mrefu nilikuwa na hakika kwamba kila mtu alikuwa akiitumia. Ilibadilika kuwa hii ni nadra.
Mbali na yale niliyotaja wakati wa ripoti, kuna vipengele visivyo na kumbukumbu vinavyokuwezesha kushambulia nguzo. Iliyotolewa hivi karibuni .
Mambo mengine yanasikitisha na kuumiza. Kwa mfano, chini ya hali fulani, cubelets katika kundi la Kubernetes inaweza kutoa yaliyomo kwenye orodha ya vitalu kwa mtumiaji ambaye hajaidhinishwa.
Kuna maagizo ya jinsi ya kuzaliana kila kitu nilichokuambia. Kuna faili zilizo na mifano ya uzalishaji ya jinsi ResourceQuota na Sera ya Usalama ya Pod inaonekana. Na unaweza kugusa haya yote.
Shukrani kwa wote.
Chanzo: mapenzi.com