Upang ganap na makabisado ang Kubernetes, kailangan mong malaman ang iba't ibang paraan upang masukat ang mga mapagkukunan ng cluster: sa pamamagitan ng , ito ay isa sa mga pangunahing gawain ng Kubernetes. Nagbigay kami ng mataas na antas na pangkalahatang-ideya ng pahalang at patayong autoscaling at mga mekanismo ng pagbabago ng laki ng kumpol, pati na rin ang mga rekomendasyon sa kung paano epektibong gamitin ang mga ito.
Artikulo isinalin ng team na nagpatupad ng autoscaling sa .
Bakit mahalagang pag-isipan ang tungkol sa pag-scale
- isang tool para sa pamamahala ng mapagkukunan at orkestrasyon. Siyempre, masarap mag-usisa sa mga cool na feature ng pag-deploy, pagsubaybay, at pamamahala ng mga pod (ang pod ay isang pangkat ng mga container na inilunsad bilang tugon sa isang kahilingan).
Gayunpaman, dapat mo ring isipin ang mga sumusunod na katanungan:
- Paano sukatin ang mga module at application?
- Paano mapanatiling gumagana at mahusay ang mga lalagyan?
- Paano tumugon sa patuloy na pagbabago sa code at mga workload mula sa mga user?
Ang pag-configure ng mga cluster ng Kubernetes upang balansehin ang mga mapagkukunan at pagganap ay maaaring maging mahirap at nangangailangan ng ekspertong kaalaman sa mga panloob na gawain ng Kubernetes. Ang workload ng iyong aplikasyon o mga serbisyo ay maaaring mag-iba-iba sa buong araw o kahit sa loob ng isang oras, kaya ang pagbabalanse ay pinakamahusay na isipin bilang isang patuloy na proseso.
Mga antas ng autoscaling ng Kubernetes
Ang epektibong autoscaling ay nangangailangan ng koordinasyon sa pagitan ng dalawang antas:
- Antas ng pod, kabilang ang pahalang (Horizontal Pod Autoscaler, HPA) at vertical na autoscaler (Vertical Pod Autoscaler, VPA). Sini-scale nito ang mga available na mapagkukunan para sa iyong mga container.
- Cluster level, na pinamamahalaan ng Cluster Autoscaler (CA), na nagpapataas o nagpapababa sa bilang ng mga node sa loob ng cluster.
Horizontal Autoscaler (HPA) module
Gaya ng ipinahihiwatig ng pangalan, sinusukat ng HPA ang bilang ng mga replika ng pod. Karamihan sa mga devop ay gumagamit ng CPU at memory load bilang mga trigger para sa pagbabago ng bilang ng mga replika. Gayunpaman, posible na sukatin ang sistema batay sa , kanilang o kahit na .
Mataas na antas ng operating diagram ng HPA:
- Patuloy na sinusuri ng HPA ang mga halaga ng sukatan na tinukoy sa panahon ng pag-install sa isang default na pagitan ng 30 segundo.
- Sinusubukan ng HPA na dagdagan ang bilang ng mga module kung maabot ang tinukoy na threshold.
- Ina-update ng HPA ang bilang ng mga replika sa loob ng deployment/replication controller.
- Ang deployment/replication controller ay nagde-deploy ng anumang kinakailangang karagdagang module.
Sinisimulan ng HPA ang proseso ng pag-deploy ng module kapag naabot na ang metric threshold
Kapag gumagamit ng HPA, isaalang-alang ang sumusunod:
- Ang default na pagitan ng pagsusuri ng HPA ay 30 segundo. Itinatakda ito ng watawat horizontal-pod-autoscaler-sync-period sa controller manager.
- Ang default na kamag-anak na error ay 10%.
- Pagkatapos ng huling pagtaas sa bilang ng mga module, inaasahan ng HPA na mag-stabilize ang mga sukatan sa loob ng tatlong minuto. Ang agwat na ito ay itinakda ng bandila horizontal-pod-autoscaler-upscale-delay.
- Pagkatapos ng huling pagbawas sa bilang ng mga module, ang HPA ay naghihintay ng limang minuto upang maging matatag. Ang agwat na ito ay itinakda ng bandila horizontal-pod-autoscaler-downscale-delay.
- Pinakamahusay na gumagana ang HPA sa mga deployment object kaysa sa mga replication controller. Ang pahalang na autoscaling ay hindi tugma sa rolling update, na direktang nagmamanipula ng mga replication controller. Sa pag-deploy, ang bilang ng mga replika ay direktang nakasalalay sa mga bagay sa pag-deploy.
Vertical na autoscaling ng mga pod
Ang Vertical autoscaling (VPA) ay naglalaan ng higit (o mas kaunting) oras ng CPU o memory sa mga kasalukuyang pod. Angkop para sa stateful o stateless pods, ngunit pangunahing inilaan para sa stateful services. Gayunpaman, maaari mo ring gamitin ang VPA para sa mga stateless na module kung kailangan mong awtomatikong isaayos ang dami ng unang inilaan na mapagkukunan.
Tumutugon din ang VPA sa mga kaganapan sa OOM (out of memory). Ang pagpapalit ng oras at memorya ng CPU ay nangangailangan ng pag-restart ng mga pod. Kapag na-restart, iginagalang ng VPA ang badyet ng alokasyon () upang magarantiya ang pinakamababang kinakailangang bilang ng mga module.
Maaari mong itakda ang minimum at maximum na mapagkukunan para sa bawat module. Kaya, maaari mong limitahan ang maximum na halaga ng inilalaan na memorya sa 8 GB. Ito ay kapaki-pakinabang kung ang kasalukuyang mga node ay tiyak na hindi makakapaglaan ng higit sa 8 GB ng memorya sa bawat lalagyan. Ang mga detalyadong pagtutukoy at mekanismo ng pagpapatakbo ay inilarawan sa .
Bilang karagdagan, ang VPA ay may isang kawili-wiling function ng rekomendasyon (VPA Recommender). Sinusubaybayan nito ang paggamit ng mapagkukunan at mga kaganapan sa OOM ng lahat ng mga module upang magmungkahi ng bagong memory at mga halaga ng oras ng CPU batay sa isang matalinong algorithm batay sa mga makasaysayang sukatan. Mayroon ding API na kumukuha ng pod handle at nagbabalik ng mga iminungkahing halaga ng mapagkukunan.
Kapansin-pansin na hindi sinusubaybayan ng VPA Recommender ang "limitasyon" ng mapagkukunan. Maaari itong magresulta sa pagmonopolyo ng module ng mga mapagkukunan sa loob ng mga node. Mas mainam na itakda ang limitasyon sa antas ng namespace upang maiwasan ang malaking memorya o pagkonsumo ng CPU.
High-level na pamamaraan ng pagpapatakbo ng VPA:
- Patuloy na sinusuri ng VPA ang mga halaga ng sukatan na tinukoy sa panahon ng pag-install sa isang default na pagitan ng 10 segundo.
- Kung maabot ang tinukoy na threshold, susubukan ng VPA na baguhin ang inilalaang halaga ng mga mapagkukunan.
- Ina-update ng VPA ang bilang ng mga mapagkukunan sa loob ng deployment/replication controller.
- Kapag ang mga module ay na-restart, ang lahat ng mga bagong mapagkukunan ay inilalapat sa mga nilikhang pagkakataon.
Idinaragdag ng VPA ang kinakailangang halaga ng mga mapagkukunan
Pakitandaan ang mga sumusunod na punto kapag gumagamit ng VPA:
- Ang pag-scale ay nangangailangan ng mandatoryong pag-restart ng pod. Ito ay kinakailangan upang maiwasan ang hindi matatag na operasyon pagkatapos gumawa ng mga pagbabago. Para sa pagiging maaasahan, ang mga module ay nire-restart at ipinamamahagi sa mga node batay sa mga bagong inilaan na mapagkukunan.
- Ang VPA at HPA ay hindi pa tugma sa isa't isa at hindi maaaring tumakbo sa parehong mga pod. Kung gumagamit ka ng parehong mekanismo ng pag-scale sa parehong cluster, tiyaking pinipigilan ng iyong mga setting ang mga ito na ma-activate sa parehong mga bagay.
- Tinutugunan ng VPA ang mga kahilingan sa container para sa mga mapagkukunan batay lamang sa nakaraan at kasalukuyang paggamit. Hindi ito nagtatakda ng mga limitasyon sa paggamit ng mapagkukunan. Maaaring may mga problema sa mga application na hindi gumagana nang tama at nagsisimulang kumuha ng higit at higit pang mga mapagkukunan, hahantong ito sa pag-off ng Kubernetes sa pod na ito.
- Ang VPA ay nasa maagang yugto pa ng pag-unlad. Maging handa na ang sistema ay maaaring sumailalim sa ilang mga pagbabago sa malapit na hinaharap. Maaari mong basahin ang tungkol sa ΠΈ . Kaya, may mga planong ipatupad ang magkasanib na operasyon ng VPA at HPA, pati na rin ang pag-deploy ng mga module kasama ng isang vertical na patakaran sa autoscaling para sa kanila (halimbawa, isang espesyal na label na 'nangangailangan ng VPA').
Autoscaling ng isang Kubernetes cluster
Binabago ng Cluster Autoscaler (CA) ang bilang ng mga node batay sa bilang ng mga naghihintay na pod. Pana-panahong sinusuri ng system ang mga nakabinbing module - at pinapataas ang laki ng cluster kung kailangan ng mas maraming mapagkukunan at kung ang cluster ay hindi lalampas sa itinatag na mga limitasyon. Nakikipag-ugnayan ang CA sa cloud service provider, humihiling ng mga karagdagang node mula rito, o naglalabas ng mga idle. Ang unang pangkalahatang magagamit na bersyon ng CA ay ipinakilala sa Kubernetes 1.8.
Mataas na antas na pamamaraan ng operasyon ng SA:
- Sinusuri ng CA ang mga nakabinbing module sa default na pagitan ng 10 segundo.
- Kung ang isa o higit pang mga pod ay nasa standby na estado dahil ang cluster ay walang sapat na magagamit na mga mapagkukunan upang ilaan ang mga ito, sinusubukan nitong magbigay ng isa o higit pang mga karagdagang node.
- Kapag inilaan ng cloud service provider ang kinakailangang node, sasali ito sa cluster at handang ihatid ang mga pod.
- Ang scheduler ng Kubernetes ay namamahagi ng mga nakabinbing pod sa isang bagong node. Kung pagkatapos nito ang ilang mga module ay mananatili pa rin sa isang naghihintay na estado, ang proseso ay paulit-ulit at ang mga bagong node ay idaragdag sa cluster.
Awtomatikong provisioning ng mga cluster node sa cloud
Isaalang-alang ang sumusunod kapag gumagamit ng CA:
- Tinitiyak ng CA na ang lahat ng pod sa cluster ay may puwang upang tumakbo, anuman ang pag-load ng CPU. Sinusubukan din nitong tiyakin na walang mga hindi kinakailangang node sa cluster.
- Inirerehistro ng CA ang pangangailangang mag-scale pagkatapos ng humigit-kumulang 30 segundo.
- Kapag hindi na kailangan ang isang node, magde-default ang CA sa paghihintay ng 10 minuto bago i-scale ang system.
- Ang sistema ng autoscaling ay may konsepto ng mga expander. Ito ay iba't ibang mga diskarte para sa pagpili ng isang pangkat ng mga node kung saan idadagdag ang mga bagong node.
- Gamitin ang opsyon nang may pananagutan cluster-autoscaler.kubernetes.io/safe-to-evict (true). Kung mag-i-install ka ng maraming pod, o kung marami sa mga ito ang nakakalat sa lahat ng node, higit na mawawalan ka ng kakayahang i-scale out ang cluster.
- Gamitin upang maiwasang matanggal ang mga pod, na maaaring magsanhi sa mga bahagi ng iyong application na ganap na mabigo.
Paano nakikipag-ugnayan ang mga autoscaler ng Kubernetes sa isa't isa
Para sa perpektong pagkakatugma, dapat ilapat ang autoscaling sa parehong antas ng pod (HPA/VPA) at antas ng cluster. Nakikipag-ugnayan sila sa isa't isa sa medyo simple:
- Ang mga HPA o VPA ay nag-a-update ng mga replika ng pod o mga mapagkukunang nakalaan sa mga kasalukuyang pod.
- Kung walang sapat na mga node para sa nakaplanong pag-scale, mapapansin ng CA ang pagkakaroon ng mga pod sa isang naghihintay na estado.
- Ang CA ay naglalaan ng mga bagong node.
- Ang mga module ay ipinamamahagi sa mga bagong node.
Collaborative Kubernetes scale-out system
Mga karaniwang pagkakamali sa autoscaling ng Kubernetes
Mayroong ilang mga karaniwang problema na nararanasan kapag sinusubukang ipatupad ang autoscaling.
Nakadepende ang HPA at VPA sa mga sukatan at ilang dating data. Kung hindi sapat na mga mapagkukunan ang inilalaan, ang mga module ay mababawasan at hindi makakabuo ng mga sukatan. Sa kasong ito, hindi kailanman mangyayari ang autoscaling.
Ang scaling operation mismo ay sensitibo sa oras. Gusto naming mabilis na mag-scale ang mga module at cluster - bago mapansin ng mga user ang anumang problema o pagkabigo. Samakatuwid, ang average na oras ng pag-scale para sa mga pod at ang cluster ay dapat isaalang-alang.
Mainam na senaryo - 4 na minuto:
- 30 segundo. I-update ang mga sukatan ng target: 30β60 segundo.
- 30 segundo. Sinusuri ng HPA ang mga halaga ng sukatan: 30 segundo.
- Wala pang 2 segundo. Ginagawa ang mga pod at napupunta sa status ng paghihintay: 1 segundo.
- Wala pang 2 segundo. Nakikita ng CA ang mga naghihintay na module at nagpapadala ng mga tawag sa mga provision node: 1 segundo.
- 3 minuto. Ang cloud provider ay naglalaan ng mga node. Naghihintay ang mga K8 hanggang sa maging handa sila: hanggang 10 minuto (depende sa ilang salik).
Pinakamasamang sitwasyon (mas makatotohanan) - 12 minuto:
- 30 segundo. I-update ang mga sukatan ng target.
- 30 segundo. Sinusuri ng HPA ang mga halaga ng sukatan.
- Wala pang 2 segundo. Ang mga pod ay ginawa at pumasok sa standby na estado.
- Wala pang 2 segundo. Ang CA ay nakikita ang naghihintay na mga module at gumagawa ng mga tawag upang ibigay ang mga node.
- 10 minuto. Ang cloud provider ay naglalaan ng mga node. Ang K8 ay naghihintay hanggang sa sila ay handa na. Ang oras ng paghihintay ay depende sa ilang mga kadahilanan, tulad ng pagkaantala ng vendor, pagkaantala sa OS, at mga tool sa suporta.
Huwag malito ang mga mekanismo ng pag-scale ng mga cloud provider sa aming CA. Ang huli ay tumatakbo sa loob ng isang Kubernetes cluster, habang ang cloud provider engine ay gumagana sa isang node distribution basis. Hindi nito alam kung ano ang nangyayari sa iyong mga pod o application. Ang mga sistemang ito ay gumagana nang magkatulad.
Paano pamahalaan ang pag-scale sa Kubernetes
- Ang Kubernetes ay isang resource management at orchestration tool. Ang mga operasyon para sa pamamahala ng mga pod at cluster resources ay isang mahalagang milestone sa pag-master ng Kubernetes.
- Unawain ang lohika ng pod scalability na isinasaalang-alang ang HPA at VPA.
- Ang CA ay dapat lamang gamitin kung mayroon kang mahusay na pag-unawa sa mga pangangailangan ng iyong mga pod at lalagyan.
- Upang mahusay na i-configure ang isang cluster, kailangan mong maunawaan kung paano gumagana ang iba't ibang mga scaling system nang magkasama.
- Kapag tinatantya ang oras ng pag-scale, isaisip ang pinakamasama at pinakamainam na sitwasyon.
Pinagmulan: www.habr.com