Pagkatapos iniharap namin ang kanyang kuya - . Ito ay isang Open Source na proyekto na ginagamit upang i-install ang mga bahagi ng system sa isang Kubernetes cluster, na maaaring tawaging mga add-on.
Bakit may mga karagdagan pa?
Hindi lihim na ang Kubernetes ay hindi isang ready-made na all-in-one na produkto, at upang makabuo ng isang "pang-adulto" na cluster kakailanganin mo ng iba't ibang mga karagdagan. Tutulungan ka ng Addon-operator na i-install, i-configure at panatilihing napapanahon ang mga add-on na ito.
Ang pangangailangan para sa mga karagdagang bahagi sa cluster ay isiwalat sa mga kasamahan . Sa madaling salita, ang sitwasyon sa Kubernetes sa ngayon ay para sa isang simpleng pag-install na "maglaro sa paligid" maaari kang makayanan ang mga bahagi sa labas ng kahon, para sa mga developer at pagsubok maaari kang magdagdag ng Ingress, ngunit para sa isang buong pag-install, tungkol sa kung saan maaari mong sabihin na "handa na ang iyong produksyon", kailangan mong magdagdag ng isang dosenang iba't ibang mga add-on: isang bagay para sa pagsubaybay, isang bagay para sa pag-log, huwag kalimutan ang ingress at cert-manager, pumili ng mga grupo ng mga node, magdagdag ng mga patakaran sa network, season may mga setting ng sysctl at pod autoscaler...
Ano ang mga detalye ng pagtatrabaho sa kanila?
Tulad ng ipinapakita ng kasanayan, ang bagay ay hindi limitado sa isang pag-install. Para kumportableng gumana sa cluster, ang mga add-on ay kailangang i-update, i-disable (alisin sa cluster), at gusto mong subukan ang ilan bago i-install ang mga ito sa production cluster.
Kaya, marahil sapat na ang Ansible dito? Siguro. Pero Sa pangkalahatan, ang mga ganap na add-on ay hindi nabubuhay nang walang mga setting. Maaaring mag-iba ang mga setting na ito depende sa variant ng cluster (aws, gce, azure, bare-metal, do, ...). Ang ilang mga setting ay hindi maaaring tukuyin nang maaga; dapat silang makuha mula sa cluster. At ang cluster ay hindi static: para sa ilang mga setting kailangan mong subaybayan ang mga pagbabago. At narito ang Ansible ay nawawala na: kailangan mo ng isang programa na nakatira sa isang kumpol, i.e. Operator ng Kubernetes.
Yung mga sumubok nito sa trabaho , sasabihin nila na ang mga gawain ng pag-install at pag-update ng mga add-on at mga setting ng pagsubaybay ay maaaring ganap na malutas gamit ang para sa shell-operator. Maaari kang magsulat ng isang script na gagawa ng isang kondisyon kubectl apply at subaybayan, halimbawa, ConfigMap, kung saan iimbak ang mga setting. Ito ay tinatayang kung ano ang ipinatupad sa addon-operator.
Paano ito nakaayos sa addon-operator?
Kapag lumilikha ng bagong solusyon, nagpatuloy kami mula sa mga sumusunod na prinsipyo:
- Dapat suportahan ng add-on installer templating at declarative configuration. Hindi kami gumagawa ng mga magic script na nag-i-install ng mga add-on. Gumagamit ang Addon-operator ng Helm upang mag-install ng mga addon. Upang mai-install, kailangan mong lumikha ng isang tsart at piliin ang mga halaga na gagamitin para sa pagsasaayos.
- Ang mga setting ay maaaring bumuo sa pag-install, maaari silang maging makuha mula sa clusterO makatanggap ng mga update, pagsubaybay sa mga mapagkukunan ng kumpol. Ang mga operasyong ito ay maaaring ipatupad gamit ang mga kawit.
- Ang mga setting ay maaaring mag-imbak sa isang kumpol. Upang mag-imbak ng mga setting sa cluster, isang ConfigMap/addon-operator ay nilikha at ang Addon-operator ay sinusubaybayan ang mga pagbabago sa ConfigMap na ito. Ang Addon-operator ay nagbibigay sa mga hook ng access sa mga setting gamit ang mga simpleng convention.
- Ang pagdaragdag ay depende sa mga setting. Kung nagbago ang mga setting, ilalabas ng Addon-operator ang Helm chart na may mga bagong value. Tinawag namin ang kumbinasyon ng tsart ng Helm, mga halaga para dito at mga hook ng isang module (tingnan sa ibaba para sa higit pang mga detalye).
- pagtatanghal ng dula. Walang mga magic release script. Ang mekanismo ng pag-update ay katulad ng isang regular na application - mangolekta ng mga add-on at addon-operator sa isang imahe, i-tag ang mga ito at i-roll out ang mga ito.
- Kontrol ng resulta. Maaaring magbigay ang Addon-operator ng mga sukatan para sa Prometheus.
Ano ang padding sa addon-operator?
Ang isang karagdagan ay maaaring ituring na anumang bagay na nagdaragdag ng mga bagong function sa cluster. Halimbawa, ang pag-install ng Ingress ay isang magandang halimbawa ng isang add-on. Maaari itong maging anumang operator o controller na may sariling CRD: prometheus-operator, cert-manager, kube-controller-manager, atbp. O isang bagay na maliit, ngunit mas madaling gamitin - halimbawa, secret copier, na kinokopya ang mga lihim ng registry sa mga bagong namespace, o sysctl tuner, na nagko-configure ng mga parameter ng sysctl sa mga bagong node.
Upang ipatupad ang mga add-on, ang Addon-operator ay nagbibigay ng ilang mga konsepto:
- Helm chart ginamit upang mag-install ng iba't ibang software sa cluster - halimbawa, Prometheus, Grafana, nginx-ingress. Kung ang kinakailangang bahagi ay may Helm chart, ang pag-install nito gamit ang Addon-operator ay magiging napakasimple.
- Imbakan ng halaga. Karaniwang mayroong maraming iba't ibang setting ang mga helm chart na maaaring magbago sa paglipas ng panahon. Sinusuportahan ng Addon-operator ang pag-iimbak ng mga setting na ito at maaaring subaybayan ang kanilang mga pagbabago upang muling mai-install ang Helm chart na may mga bagong halaga.
- Mga kawit ay mga executable na file na pinapatakbo ng Addon-operator sa mga event at nag-a-access sa values ββstore. Maaaring subaybayan ng hook ang mga pagbabago sa cluster at i-update ang mga value sa values ββstore. Yung. Gamit ang mga hook, maaari kang gumawa ng pagtuklas upang mangolekta ng mga halaga mula sa cluster sa pagsisimula o ayon sa isang iskedyul, o maaari kang gumawa ng tuluy-tuloy na pagtuklas, pagkolekta ng mga halaga mula sa cluster batay sa mga pagbabago sa cluster.
- Modyul ay isang kumbinasyon ng isang Helm chart, isang value store at mga hook. Maaaring paganahin o hindi paganahin ang mga module. Ang hindi pagpapagana ng module ay nangangahulugan ng pagtanggal sa lahat ng mga release ng Helm chart. Ang mga module ay maaaring paganahin ang kanilang mga sarili nang pabago-bago, halimbawa, kung ang lahat ng mga module na kailangan nito ay pinagana o kung natuklasan ng pagtuklas ang mga kinakailangang parameter sa mga kawit - ginagawa ito gamit ang isang auxiliary na naka-enable na script.
- Mga pandaigdigang kawit. Ang mga ito ay mga kawit "sa kanilang sarili", hindi sila kasama sa mga module at may access sa isang pandaigdigang tindahan ng mga halaga, ang mga halaga ay magagamit sa lahat ng mga kawit sa mga module.
Paano gumagana ang mga bahaging ito nang magkasama? Tingnan natin ang larawan mula sa dokumentasyon:
Mayroong dalawang sitwasyon sa trabaho:
- Ang global hook ay na-trigger ng isang kaganapan - halimbawa, kapag nagbago ang isang mapagkukunan sa cluster. Pinoproseso ng hook na ito ang mga pagbabago at isinusulat ang mga bagong halaga sa pandaigdigang tindahan ng mga halaga. Napansin ng Addon-operator na nagbago ang pandaigdigang storage at sinisimulan ang lahat ng module. Ang bawat module, gamit ang mga hook nito, ay tumutukoy kung kailangan itong paganahin at i-update ang mga value store nito. Kung pinagana ang module, sisimulan ng Addon-operator ang pag-install ng Helm chart. Sa kasong ito, ang Helm chart ay may access sa mga value mula sa module storage at mula sa global storage.
- Ang pangalawang senaryo ay mas simple: ang isang module hook ay na-trigger ng isang kaganapan at nagbabago ng mga halaga sa tindahan ng mga halaga ng module. Napansin ito ng Addon-operator at inilunsad ang Helm chart na may mga na-update na halaga.
Ang karagdagan ay maaaring ipatupad bilang isang solong hook, o bilang isang Helm chart, o kahit bilang ilang umaasa na mga module - depende ito sa pagiging kumplikado ng component na ini-install sa cluster at sa nais na antas ng flexibility ng configuration. Halimbawa, sa repositoryo () mayroong isang sysctl-tuner add-on, na ipinapatupad bilang isang simpleng module na may hook at isang Helm chart, at gamit ang values ββstore, na ginagawang posible na magdagdag ng mga setting sa pamamagitan ng pag-edit ng ConfigMap.
Paghahatid ng mga update
Ilang salita tungkol sa pag-aayos ng mga update sa bahagi na ini-install ng Addon-operator.
Upang patakbuhin ang Addon-operator sa isang kumpol, kailangan mo bumuo ng isang imahe na may mga karagdagan sa anyo ng mga hook at Helm chart file, magdagdag ng binary file addon-operator at lahat ng kailangan mo para sa mga kawit: bash, kubectl, jq, python atbp. Pagkatapos ay maaaring i-roll out ang larawang ito sa cluster bilang isang regular na application, at malamang na gusto mong ayusin ang isa o isa pang scheme ng pag-tag. Kung kakaunti ang mga cluster, maaaring angkop ang parehong diskarte tulad ng sa mga application: bagong release, bagong bersyon, pumunta sa lahat ng cluster at itama ang imahe ng Pods. Gayunpaman, sa kaso ng isang rollout sa isang malaking bilang ng mga cluster, ang konsepto ng self-update mula sa isang channel ay mas angkop para sa amin.
Narito kung paano namin ito ginagawa:
- Ang channel ay mahalagang identifier na maaaring itakda sa anumang bagay (halimbawa, dev/stage/ea/stable).
- Ang pangalan ng channel ay ang tag ng larawan. Kapag kailangan mong maglunsad ng mga update sa isang channel, isang bagong larawan ang bubuuin at ita-tag gamit ang pangalan ng channel.
- Kapag lumitaw ang isang bagong imahe sa registry, ang Addon-operator ay ire-restart at ilulunsad kasama ang bagong larawan.
Hindi ito pinakamahusay na kasanayan, tulad ng nakasulat sa . Hindi inirerekomenda na gawin ito, ngunit pinag-uusapan natin isang regular na application na nakatira sa parehong kumpol. Sa kaso ng Addon-operator, ang isang application ay maraming Deployment na nakakalat sa mga cluster, at ang pag-update sa sarili ay nakakatulong nang malaki at nagpapadali sa buhay.
Tumulong ang mga channel at sa pagsubok: kung mayroong isang auxiliary cluster, maaari mong i-configure ito sa channel stage at ilunsad dito ang mga update bago ito ilunsad sa mga channel ea ΠΈ stable. Kung may kumpol sa channel ea may naganap na error, maaari mo itong ilipat sa stable, habang ang problema sa cluster na ito ay sinisiyasat. Kung ang cluster ay inalis sa aktibong suporta, lilipat ito sa "frozen" na channel nito - halimbawa, freeze-2019-03-20.
Bilang karagdagan sa pag-update ng mga hook at Helm chart, maaaring kailanganin mo update at bahagi ng third party. Halimbawa, may napansin kang bug sa conditional node-exporter at naisip mo pa kung paano ito i-patch. Susunod, binuksan mo ang PR at naghihintay para sa bagong release na dumaan sa lahat ng mga kumpol at dagdagan ang bersyon ng imahe. Upang hindi maghintay nang walang katapusan, maaari mong buuin ang iyong node-exporter at lumipat dito bago tanggapin ang PR.
Sa pangkalahatan, magagawa ito nang walang Addon-operator, ngunit sa Addon-operator ang module para sa pag-install ng node-exporter ay makikita sa isang repository, ang Dockerfile para sa pagbuo ng iyong imahe ay maaaring itago doon, nagiging mas madali para sa lahat ng kalahok sa ang proseso upang maunawaan kung ano ang mangyayari... At kung mayroong ilang mga kumpol, pagkatapos ay nagiging mas madali upang parehong subukan ang iyong PR at ilunsad ang isang bagong bersyon!
Ang organisasyong ito ng pag-update ng bahagi ay matagumpay na gumagana para sa amin, ngunit anumang iba pang naaangkop na pamamaraan ay maaaring ipatupad - pagkatapos ng lahat sa kasong ito, ang Addon-operator ay isang simpleng binary file.
Konklusyon
Ang mga prinsipyong ipinatupad sa Addon-operator ay nagbibigay-daan sa iyo na bumuo ng isang transparent na proseso para sa paggawa, pagsubok, pag-install at pag-update ng mga add-on sa isang cluster, katulad ng mga proseso ng pagbuo ng mga regular na application.
Ang mga add-on para sa Addon-operator sa module na format (Helm chart + hooks) ay maaaring gawing available sa publiko. Kami, ang kumpanya ng Flant, ay nagpaplano na i-publish ang aming mga pag-unlad sa anyo ng mga naturang karagdagan sa panahon ng tag-araw. Sumali sa pagbuo sa GitHub (, ), subukang gumawa ng sarili mong karagdagan batay sa ΠΈ , maghintay ng balita sa HabrΓ© at sa aming !
PS
Basahin din sa aming blog:
- Β«";
- Β«'.
Pinagmulan: www.habr.com