🥇Introduksyon sa Helm 3

Tandaan. transl.: Ang Mayo 16 ng taong ito ay nagmamarka ng isang makabuluhang milestone sa pagbuo ng manager ng package para sa Kubernetes - Helm. Sa araw na ito, ipinakita ang unang alpha release ng hinaharap na pangunahing bersyon ng proyekto - 3.0 -. Ang paglabas nito ay magdadala ng makabuluhan at pinakahihintay na pagbabago sa Helm, kung saan marami sa komunidad ng Kubernetes ang may mataas na pag-asa. Kami mismo ay isa sa mga ito, dahil aktibong ginagamit namin ang Helm para sa pag-deploy ng application: isinama namin ito sa aming tool para sa pagpapatupad ng CI/CD werf at paminsan-minsan ay ginagawa natin ang ating kontribusyon sa pag-unlad ng upstream. Pinagsasama ng pagsasaling ito ang 7 tala mula sa opisyal na Helm blog, na nakatuon sa unang alpha release ng Helm 3 at pinag-uusapan ang kasaysayan ng proyekto at ang mga pangunahing tampok ng Helm 3. Ang kanilang may-akda ay si Matt "bacongobbler" Fisher, isang empleyado ng Microsoft at isa sa mga pangunahing nagpapanatili ng Helm.

Noong Oktubre 15, 2015, isinilang ang proyektong kilala ngayon bilang Helm. Isang taon lamang matapos itong itatag, sumali ang komunidad ng Helm sa Kubernetes, habang aktibong nagtatrabaho sa Helm 2. Noong Hunyo 2018, Helm sumali sa CNCF bilang isang pagbuo (incubating) proyekto. Fast forward sa kasalukuyan, at ang unang alpha release ng bagong Helm 3 ay paparating na. (ang paglabas na ito naganap na sa kalagitnaan ng Mayo - tantiya. transl.).

Sa bahaging ito, pag-uusapan ko kung saan nagsimula ang lahat, kung paano tayo nakarating sa kinalalagyan natin ngayon, ipakilala ang ilan sa mga natatanging feature na available sa unang alpha release ng Helm 3, at ipaliwanag kung paano namin pinaplano na sumulong.

Buod:

ang kasaysayan ng paglikha ng Helm;
isang malambot na paalam kay Tiller;
mga imbakan ng tsart;
pamamahala ng pagpapalaya;
mga pagbabago sa mga dependency sa tsart;
mga tsart ng aklatan;
anong susunod?

Ang kasaysayan ng Helm

Kapanganakan

Nagsimula ang Helm 1 bilang isang Open Source na proyekto na ginawa ni Deis. Kami ay isang maliit na startup hinihigop Microsoft sa tagsibol 2017. Ang aming isa pang Open Source na proyekto, na pinangalanang Deis, ay may tool deisctl, na ginamit (bukod sa iba pang mga bagay) upang i-install at patakbuhin ang Deis platform sa Kumpol ng armada. Noong panahong iyon, ang Fleet ay isa sa mga unang container orchestration platform.

Noong kalagitnaan ng 2015, nagpasya kaming magpalit ng kurso at inilipat ang Deis (noong panahong iyon, pinalitan ang pangalan ng Deis Workflow) mula Fleet patungong Kubernetes. Isa sa mga unang na-redesign ay ang installation tool. deisctl. Ginamit namin ito upang i-install at pamahalaan ang Deis Workflow sa Fleet cluster.

Ang Helm 1 ay nilikha sa imahe ng mga sikat na manager ng package tulad ng Homebrew, apt at yum. Ang pangunahing layunin nito ay pasimplehin ang mga gawain tulad ng packaging at pag-install ng mga application sa Kubernetes. Opisyal na ipinakilala ang Helm noong 2015 sa KubeCon conference sa San Francisco.

Ang aming unang pagtatangka sa Helm ay gumana, ngunit ito ay walang ilang malubhang limitasyon. Kumuha siya ng isang set ng Kubernetes manifests, na nilagyan ng mga generator bilang panimulang YAML blocks (front-matter)*, at na-load ang mga resulta sa Kubernetes.

* Tandaan. transl.: Mula sa unang bersyon ng Helm, ang YAML syntax ay pinili upang ilarawan ang mga mapagkukunan ng Kubernetes, at ang mga template ng Jinja at mga script ng Python ay sinusuportahan kapag nagsusulat ng mga configuration. Sumulat kami ng higit pa tungkol dito at sa istraktura ng unang bersyon ng Helm sa pangkalahatan sa kabanata na "Isang Maikling Kasaysayan ng Helm" materyal na ito.

Halimbawa, upang palitan ang isang field sa isang YAML file, kailangan mong idagdag ang sumusunod na construct sa manifest:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Napakaganda na ang mga template engine ay umiiral ngayon, hindi ba?

Para sa maraming kadahilanan, ang maagang installer ng Kubernetes na ito ay nangangailangan ng isang hard-coded na listahan ng mga manifest file at nagsagawa lamang ng maliit, nakapirming pagkakasunud-sunod ng mga kaganapan. Napakahirap gamitin kaya nahirapan ang Deis Workflow R&D team nang sinubukan nilang ilipat ang kanilang produkto sa platform na ito - gayunpaman, naihasik na ang mga binhi ng ideya. Ang aming unang pagtatangka ay isang magandang pagkakataon sa pag-aaral: napagtanto namin na kami ay tunay na madamdamin tungkol sa paglikha ng mga praktikal na tool na lumulutas sa mga pang-araw-araw na problema para sa aming mga user.

Batay sa karanasan ng mga nakaraang pagkakamali, nagsimula kaming bumuo ng Helm 2.

Paggawa ng Helm 2

Sa pagtatapos ng 2015, nakipag-ugnayan sa amin ang Google team. Gumagawa sila ng katulad na tool para sa Kubernetes. Ang Deployment Manager para sa Kubernetes ay isang port ng isang umiiral nang tool na ginamit para sa Google Cloud Platform. “Gusto ba namin,” ang tanong nila, “na gumugol ng ilang araw sa pagtalakay sa pagkakatulad at pagkakaiba?”

Noong Enero 2016, nagpulong ang mga Helm and Deployment Manager team sa Seattle upang makipagpalitan ng ideya. Ang mga negosasyon ay natapos sa isang ambisyosong plano: upang pagsamahin ang parehong mga proyekto upang lumikha ng Helm 2. Kasama sina Deis at Google, ang mga lalaki mula sa SkippBox (bahagi na ngayon ng Bitnami - tinatayang transl.), at nagsimula kaming gumawa sa Helm 2.

Nais naming panatilihin ang kadalian ng paggamit ng Helm, ngunit idagdag ang sumusunod:

mga template ng tsart para sa pagpapasadya;
pamamahala ng intra-cluster para sa mga koponan;
world-class na imbakan ng tsart;
matatag na format ng pakete na may opsyon sa lagda;
isang malakas na pangako sa semantic versioning at pagpapanatili ng backward compatibility sa pagitan ng mga bersyon.

Upang makamit ang mga layuning ito, may idinagdag na pangalawang elemento sa Helm ecosystem. Ang bahagi ng intra-cluster na ito ay tinawag na Tiller at responsable sa pag-install ng mga Helm chart at pamamahala sa mga ito.

Mula nang ilabas ang Helm 2 noong 2016, nagdagdag ang Kubernetes ng ilang pangunahing inobasyon. Idinagdag ang control-based na access control (RBAC), na kalaunan ay pinalitan ang Attribute-Based Access Control (ABAC). Ang mga bagong uri ng mapagkukunan ay ipinakilala (Ang mga deployment ay nasa beta pa noong panahong iyon). Naimbento ang Custom Resource Definition (orihinal na tinatawag na Third Party Resources o TPRs). At higit sa lahat, lumitaw ang isang hanay ng pinakamahuhusay na kagawian.

Sa gitna ng lahat ng pagbabagong ito, patuloy na pinaglilingkuran ni Helm ang mga user ng Kubernetes nang tapat. Pagkatapos ng tatlong taon at maraming mga bagong karagdagan, malinaw na oras na para gumawa ng mga makabuluhang pagbabago sa codebase upang matiyak na patuloy na matutugunan ng Helm ang lumalaking pangangailangan ng isang umuusbong na ecosystem.

Isang malambot na paalam kay Tiller

Sa panahon ng pagbuo ng Helm 2, ipinakilala namin si Tiller bilang bahagi ng aming pagsasama sa Deployment Manager ng Google. May mahalagang papel ang Tiller para sa mga team na nagtatrabaho sa loob ng isang karaniwang cluster: pinahintulutan nito ang iba't ibang mga espesyalista na nagpapatakbo ng imprastraktura na makipag-ugnayan sa parehong hanay ng mga release.

Dahil ang role-based na access control (RBAC) ay pinagana bilang default sa Kubernetes 1.6, naging mas mahirap ang pakikipagtulungan sa Tiller sa produksyon. Dahil sa napakaraming posibleng mga patakaran sa seguridad, ang aming posisyon ay mag-alok ng isang permissive na configuration bilang default. Nagbigay-daan ito sa mga baguhan na mag-eksperimento sa Helm at Kubernetes nang hindi na kailangang sumabak muna sa mga setting ng seguridad. Sa kasamaang palad, ang pagsasaayos ng pahintulot na ito ay maaaring magbigay sa user ng masyadong malawak na hanay ng mga pahintulot na hindi nila kailangan. Ang mga inhinyero ng DevOps at SRE ay kailangang matuto ng mga karagdagang hakbang sa pagpapatakbo kapag nag-i-install ng Tiller sa isang multi-tenant cluster.

Matapos malaman kung paano ginamit ng komunidad ang Helm sa mga partikular na sitwasyon, napagtanto namin na ang sistema ng pamamahala ng paglabas ng Tiller ay hindi kailangang umasa sa isang bahagi ng intra-cluster upang mapanatili ang estado o paggana bilang isang sentral na hub para sa pagpapalabas ng impormasyon. Sa halip, maaari lang kaming makatanggap ng impormasyon mula sa server ng Kubernetes API, makabuo ng tsart sa panig ng kliyente, at mag-imbak ng talaan ng pag-install sa Kubernetes.

Ang pangunahing layunin ng Tiller ay maaaring makamit nang walang Tiller, kaya isa sa aming mga unang desisyon tungkol sa Helm 3 ay ang ganap na talikuran si Tiller.

Nang wala na si Tiller, ang modelo ng seguridad ng Helm ay pinasimple na. Sinusuportahan na ngayon ng Helm 3 ang lahat ng modernong paraan ng seguridad, pagkakakilanlan, at awtorisasyon ng mga kasalukuyang Kubernetes. Ang mga pahintulot sa helm ay tinutukoy gamit kubeconfig file. Maaaring paghigpitan ng mga administrator ng cluster ang mga karapatan ng user sa anumang antas ng granularity. Naka-save pa rin ang mga release sa loob ng cluster, at nananatiling buo ang natitirang functionality ng Helm.

Mga imbakan ng tsart

Sa isang mataas na antas, ang isang chart repository ay isang lugar kung saan maaaring iimbak at ibahagi ang mga chart. Ang Helm client ay nag-package at nagpapadala ng mga chart sa repository. Sa madaling salita, ang repositoryo ng mga chart ay isang primitive na HTTP server na may index.yaml file at ilang naka-package na chart.

Bagama't may ilang bentahe ang Charts Repository API na nakakatugon sa karamihan ng mga pangunahing kinakailangan sa storage, mayroon ding ilang disadvantage:

Ang mga imbakan ng chart ay hindi tugma sa karamihan ng mga pagpapatupad ng seguridad na kinakailangan sa isang kapaligiran ng produksyon. Ang pagkakaroon ng karaniwang API para sa pagpapatunay at awtorisasyon ay napakahalaga sa mga sitwasyon ng produksyon.
Ang mga tool ng provenance ng chart ng Helm, na ginagamit para lagdaan, i-verify ang integridad at pinagmulan ng isang chart, ay isang opsyonal na bahagi ng proseso ng pag-publish ng Chart.
Sa mga sitwasyong may maraming user, ang parehong chart ay maaaring i-upload ng isa pang user, na nagdodoble sa dami ng espasyong kinakailangan para mag-imbak ng parehong nilalaman. Ang mga mas matalinong repository ay binuo upang malutas ang problemang ito, ngunit hindi sila bahagi ng pormal na detalye.
Ang paggamit ng iisang index file para sa paghahanap, pag-iimbak ng metadata, at pagkuha ng mga chart ay naging mahirap na bumuo ng mga secure na pagpapatupad ng maraming user.

Proyekto Pamamahagi ng Docker (kilala rin bilang Docker Registry v2) ay ang kahalili sa Docker Registry at mahalagang gumaganap bilang isang hanay ng mga tool para sa packaging, pagpapadala, pag-iimbak at paghahatid ng mga imahe ng Docker. Maraming malalaking serbisyo sa cloud ang nag-aalok ng mga produktong nakabatay sa Pamamahagi. Salamat sa tumaas na atensyong ito, nakinabang ang proyekto ng Pamamahagi mula sa mga taon ng mga pagpapabuti, pinakamahuhusay na kagawian sa seguridad, at pagsubok sa field na naging dahilan upang ito ay isa sa pinakamatagumpay na unsung heroes ng mundo ng Open Source.

Ngunit alam mo ba na ang Distribution Project ay idinisenyo upang ipamahagi ang anumang anyo ng nilalaman, hindi lamang mga imahe ng lalagyan?

Salamat sa mga pagsisikap Buksan ang Inisyatiba ng Container (o OCI), ang mga Helm chart ay maaaring ilagay sa anumang Distribution instance. Sa ngayon, ang prosesong ito ay pang-eksperimento. Ang suporta sa pag-login at iba pang mga feature na kailangan para sa isang buong Helm 3 ay kasalukuyang ginagawa, ngunit nasasabik kaming matuto mula sa mga pagtuklas na ginawa ng mga OCI at Distribution team sa mga nakaraang taon. At sa pamamagitan ng kanilang paggabay at paggabay, nalaman namin kung ano ang pakiramdam ng pagpapatakbo ng isang magagamit na serbisyo sa laki.

Available ang isang mas detalyadong paglalarawan ng ilang paparating na pagbabago sa mga repositoryo ng Helm chart по ссылке.

Pamamahala ng release

Sa Helm 3, ang estado ng aplikasyon ay sinusubaybayan sa loob ng cluster ng isang pares ng mga bagay:

release object - kumakatawan sa isang application instance;
lihim na bersyon ng release - kumakatawan sa nais na estado ng application sa isang tiyak na punto ng oras (halimbawa, ang paglabas ng isang bagong bersyon).

Hamon helm install lumilikha ng isang release object at release na bersyon ng sikreto. Tumawag helm upgrade nangangailangan ng isang release object (na maaari itong baguhin) at lumikha ng isang bagong release na bersyon ng sikreto na naglalaman ng mga bagong halaga at isang inihandang manifest.

Ang object ng release ay naglalaman ng impormasyon tungkol sa release, kung saan ang release ay isang partikular na pag-install ng pinangalanang chart at mga value. Inilalarawan ng object na ito ang top-level na metadata tungkol sa release. Nagpapatuloy ang release object sa buong lifecycle ng application at ang may-ari ng lahat ng mga lihim ng bersyon ng release, pati na rin ang lahat ng object na direktang ginawa ng Helm chart.

Iniuugnay ng lihim ng bersyon ng release ang isang release sa isang serye ng mga pagbabago (pag-install, mga update, rollback, pagtanggal).

Sa Helm 2, ang mga rebisyon ay lubos na pare-pareho. Tumawag helm install nilikha v1, ang kasunod na pag-update (pag-upgrade) - v2, at iba pa. Ang lihim ng release at release na bersyon ay na-collapse sa isang bagay na kilala bilang rebisyon. Ang mga pagbabago ay inimbak sa parehong namespace bilang Tiller, na nangangahulugang ang bawat release ay "global" sa mga tuntunin ng namespace; bilang resulta, isang instance lang ng pangalan ang maaaring gamitin.

Sa Helm 3, ang bawat release ay nauugnay sa isa o higit pang mga lihim ng bersyon ng release. Palaging inilalarawan ng object ng release ang kasalukuyang release na naka-deploy sa Kubernetes. Ang bawat release version secret ay naglalarawan lamang ng isang bersyon ng release na iyon. Ang isang pag-upgrade, halimbawa, ay lilikha ng isang bagong lihim na bersyon ng release at pagkatapos ay babaguhin ang object ng paglabas upang tumuro sa bagong bersyon na iyon. Sa kaso ng rollback, maaari mong gamitin ang mga lihim ng nakaraang bersyon ng release upang ibalik ang release sa isang nakaraang estado.

Pagkatapos iwanan ang Tiller, ang Helm 3 ay nag-iimbak ng data ng release sa parehong namespace bilang ang release. Binibigyang-daan ka ng pagbabagong ito na mag-install ng chart na may parehong pangalan ng release sa ibang namespace, at ang data ay nai-save sa pagitan ng mga pag-update/pag-reboot ng cluster sa etcd. Halimbawa, maaari mong i-install ang WordPress sa "foo" namespace at pagkatapos ay sa "bar" namespace, at ang parehong mga release ay maaaring pangalanan na "wordpress".

Mga pagbabago sa mga dependency sa chart

Naka-pack na mga tsart (gamit ang helm package) para sa paggamit sa Helm 2 ay maaaring i-install sa Helm 3, gayunpaman ang chart development workflow ay ganap na na-overhaul, kaya ang ilang mga pagbabago ay dapat gawin upang ipagpatuloy ang chart development sa Helm 3. Sa partikular, ang chart dependency management system ay nagbago.

Ang sistema ng pamamahala ng dependency ng chart ay lumipat mula sa requirements.yaml и requirements.lock sa Chart.yaml и Chart.lock. Nangangahulugan ito na ang mga chart na gumamit ng command helm dependency, nangangailangan ng ilang setup upang gumana sa Helm 3.

Tingnan natin ang isang halimbawa. Magdagdag tayo ng dependency sa chart sa Helm 2 at tingnan kung ano ang mga pagbabago kapag lumipat sa Helm 3.

Sa Helm 2 requirements.yaml ganito ang hitsura:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Sa Helm 3, ang parehong dependency ay makikita sa iyong Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Ang mga tsart ay dina-download pa rin at inilalagay sa direktoryo charts/, kaya mga subchart (mga subchart), nakahiga sa catalog charts/, ay patuloy na gagana nang walang mga pagbabago.

Ipinapakilala ang Mga Tsart ng Aklatan

Sinusuportahan ng Helm 3 ang isang klase ng mga chart na tinatawag na library chart (tsart ng aklatan). Ang chart na ito ay ginagamit ng iba pang mga chart, ngunit hindi gumagawa ng anumang release artifact sa sarili nitong. Ang mga template ng chart ng library ay maaari lamang magdeklara ng mga elemento define. Binabalewala lang ang ibang nilalaman. Nagbibigay-daan ito sa mga user na muling gumamit at magbahagi ng mga snippet ng code na maaaring magamit sa maraming chart, sa gayon ay maiiwasan ang pagdoble at pagsunod sa prinsipyo DRY.

Ang mga tsart ng aklatan ay idineklara sa seksyon dependencies sa file Chart.yaml. Ang pag-install at pamamahala sa mga ito ay hindi naiiba sa ibang mga chart.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Nasasabik kami tungkol sa mga kaso ng paggamit na bubuksan ng bahaging ito para sa mga developer ng chart, pati na rin ang pinakamahuhusay na kagawian na maaaring lumabas mula sa mga chart ng library.

Ano ang susunod?

Ang Helm 3.0.0-alpha.1 ay ang pundasyon kung saan nagsisimula kaming bumuo ng bagong bersyon ng Helm. Sa artikulong inilarawan ko ang ilang mga kagiliw-giliw na tampok ng Helm 3. Marami sa kanila ay nasa maagang yugto pa ng pag-unlad at ito ay normal; Ang punto ng isang alpha release ay upang subukan ang ideya, mangalap ng feedback mula sa mga naunang gumagamit, at kumpirmahin ang aming mga pagpapalagay.

Sa sandaling ang bersyon ng alpha ay inilabas (tandaan na ito ay nangyari na — tinatayang. transl.), magsisimula kaming tumanggap ng mga patch para sa Helm 3 mula sa komunidad. Kailangan mong lumikha ng isang matibay na pundasyon na nagbibigay-daan sa bagong functionality na mabuo at mapagtibay, at para madama ng mga user na kasangkot sa proseso sa pamamagitan ng pagbubukas ng mga tiket at paggawa ng mga pag-aayos.

Sinubukan kong i-highlight ang ilan sa mga pangunahing pagpapahusay na darating sa Helm 3, ngunit ang listahang ito ay hindi nangangahulugang kumpleto. Kasama sa buong roadmap para sa Helm 3 ang mga feature gaya ng mga pinahusay na diskarte sa pag-update, mas malalim na pagsasama sa mga OCI registries, at ang paggamit ng mga JSON schema para i-validate ang mga value ng chart. Plano rin naming linisin ang codebase at i-update ang mga bahagi nito na napabayaan sa nakalipas na tatlong taon.

Kung sa tingin mo ay may napalampas kami, gusto naming marinig ang iyong mga saloobin!

Sumali sa talakayan sa aming Mga slack na channel:

#helm-users para sa mga katanungan at simpleng komunikasyon sa komunidad;
#helm-dev para talakayin ang mga pull request, code at mga bug.

Maaari ka ring makipag-chat sa aming lingguhang Mga Tawag sa Pampublikong Developer tuwing Huwebes sa 19:30 MSK. Ang mga pagpupulong ay nakatuon sa pagtalakay sa mga isyung pinagsusumikapan ng mga pangunahing developer at ng komunidad, pati na rin ang mga paksa ng talakayan para sa linggo. Kahit sino ay maaaring sumali at makilahok sa pulong. Available ang link sa Slack channel #helm-dev.

PS mula sa tagasalin

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Pagpapakilala ng Helm 3