Seguridad ng Helm

Ang kakanyahan ng kuwento tungkol sa pinakasikat na manager ng package para sa Kubernetes ay maaaring ilarawan gamit ang isang emoji:

• ang kahon ay Helm (na ang pinakamalapit na bagay sa pinakabagong release ng Emoji);
• lock - seguridad;
• ang maliit na tao ang solusyon sa problema.

Sa katunayan, ang lahat ay magiging mas kumplikado, at ang kuwento ay puno ng mga teknikal na detalye tungkol sa Paano gawing ligtas ang Helm.

• Sa madaling sabi kung ano ang Helm kung sakaling hindi mo alam o nakalimutan. Anong mga problema ang nalulutas nito at kung saan ito matatagpuan sa ecosystem.
• Tingnan natin ang arkitektura ng Helm. Walang pag-uusap tungkol sa seguridad at kung paano gawing mas secure ang isang tool o solusyon nang hindi nauunawaan ang arkitektura ng bahagi.
• Talakayin natin ang mga bahagi ng Helm.
• Ang pinaka-sumunog na tanong ay ang hinaharap - ang bagong bersyon ng Helm 3. 

Nalalapat ang lahat sa artikulong ito sa Helm 2. Kasalukuyang ginagawa ang bersyong ito at malamang na ang kasalukuyang ginagamit mo, at ito ang bersyon na naglalaman ng mga panganib sa seguridad.

Tungkol sa tagapagsalita: Alexander Khayorov (allexx) ay umuunlad sa loob ng 10 taon, na tumutulong sa pagpapabuti ng nilalaman Moscow Python Conf++ at sumali sa komite Helm Summit. Ngayon siya ay nagtatrabaho sa Chainstack bilang isang development lead - ito ay isang hybrid sa pagitan ng isang development manager at isang tao na responsable para sa paghahatid ng mga huling release. Iyon ay, ito ay matatagpuan sa larangan ng digmaan, kung saan ang lahat ay nangyayari mula sa paglikha ng isang produkto hanggang sa operasyon nito.

Ang Chainstack ay isang maliit, aktibong lumalagong startup na ang misyon ay bigyang-daan ang mga kliyente na makalimutan ang tungkol sa imprastraktura at mga kumplikado ng pagpapatakbo ng mga desentralisadong aplikasyon; ang development team ay matatagpuan sa Singapore. Huwag hilingin sa Chainstack na magbenta o bumili ng cryptocurrency, ngunit mag-alok na pag-usapan ang tungkol sa enterprise blockchain frameworks, at masayang sasagutin ka nila.

timon

Ito ay isang package (chart) manager para sa Kubernetes. Ang pinaka-intuitive at unibersal na paraan upang dalhin ang mga application sa isang Kubernetes cluster.

Siyempre, pinag-uusapan natin ang tungkol sa mas estruktural at pang-industriyang diskarte kaysa sa paggawa ng sarili mong YAML manifests at pagsusulat ng maliliit na utility.

Ang timon ay ang pinakamahusay na kasalukuyang magagamit at sikat.

Bakit Helm? Pangunahin dahil sinusuportahan ito ng CNCF. Ang Cloud Native ay isang malaking organisasyon at ang pangunahing kumpanya para sa mga proyektong Kubernetes, etcd, Fluentd at iba pa.

Ang isa pang mahalagang katotohanan ay ang Helm ay isang napaka-tanyag na proyekto. Noong nagsimula akong magsalita tungkol sa kung paano gawing secure ang Helm noong Enero 2019, ang proyekto ay nagkaroon ng isang libong bituin sa GitHub. Sa pamamagitan ng Mayo mayroong 12 libo sa kanila.

Maraming tao ang interesado sa Helm, kaya kahit hindi mo pa ito ginagamit, makikinabang ka sa pag-alam tungkol sa seguridad nito. Mahalaga ang kaligtasan.

Ang pangunahing koponan ng Helm ay suportado ng Microsoft Azure at samakatuwid ay isang medyo matatag na proyekto, hindi katulad ng marami pang iba. Ang paglabas ng Helm 3 Alpha 2 noong kalagitnaan ng Hulyo ay nagpapahiwatig na napakaraming tao ang nagtatrabaho sa proyekto, at mayroon silang pagnanais at lakas na bumuo at mapabuti ang Helm.

Niresolba ng Helm ang ilang ugat na problema ng pamamahala ng application sa Kubernetes.

• Packaging ng application. Kahit na ang isang application tulad ng "Hello, World" sa WordPress ay binubuo na ng ilang mga serbisyo, at gusto mong pagsamahin ang mga ito.
• Pamamahala sa pagiging kumplikado na dulot ng pamamahala sa mga application na ito.
• Isang ikot ng buhay na hindi nagtatapos pagkatapos ma-install o ma-deploy ang application. Patuloy itong nabubuhay, kailangan itong ma-update, at tinutulungan ito ng Helm at sinusubukang dalhin ang mga tamang hakbang at patakaran para dito.

Bagging ito ay nakaayos sa isang malinaw na paraan: mayroong metadata nang buong alinsunod sa gawain ng isang regular na manager ng package para sa Linux, Windows o MacOS. Iyon ay, isang repositoryo, mga dependency sa iba't ibang mga pakete, meta impormasyon para sa mga aplikasyon, mga setting, mga tampok ng pagsasaayos, pag-index ng impormasyon, atbp. Hinahayaan ka ng Helm na makuha at gamitin ang lahat ng ito para sa mga application.

Pamamahala ng pagiging kumplikado. Kung marami kang application ng parehong uri, kailangan ang parameterization. Dito nanggagaling ang mga template, ngunit upang maiwasang makabuo ng sarili mong paraan ng paggawa ng mga template, maaari mong gamitin ang inaalok ng Helm sa labas ng kahon.

Pamamahala ng Lifecycle ng Application - sa aking opinyon, ito ang pinaka-kawili-wili at hindi nalutas na tanong. Ito ang dahilan kung bakit ako napunta sa Helm noong araw. Kailangan naming bantayan ang lifecycle ng application at gusto naming ilipat ang aming CI/CD at mga siklo ng aplikasyon sa paradigm na ito.

Hinahayaan ka ng Helm na:

• pamahalaan ang mga deployment, ipinakilala ang konsepto ng pagsasaayos at pagbabago;
• matagumpay na isagawa ang rollback;
• gumamit ng mga kawit para sa iba't ibang mga kaganapan;
• magdagdag ng mga karagdagang pagsusuri sa aplikasyon at tumugon sa kanilang mga resulta.

Tangi sa ryan May "baterya" ang helmet - isang malaking bilang ng mga masasarap na bagay na maaaring isama sa anyo ng mga plugin, na nagpapasimple sa iyong buhay. Ang mga plugin ay maaaring isulat nang nakapag-iisa, sila ay medyo nakahiwalay at hindi nangangailangan ng isang maayos na arkitektura. Kung gusto mong ipatupad ang isang bagay, inirerekomenda kong gawin ito bilang isang plugin, at pagkatapos ay posibleng isama ito sa upstream.

Ang Helm ay batay sa tatlong pangunahing konsepto:

• Repo ng Tsart — paglalarawan at hanay ng mga parameterization na posible para sa iyong manifest. 
• config —iyon ay, ang mga halaga na ilalapat (teksto, mga halaga ng numero, atbp.).
• Bitawan kinokolekta ang dalawang bahagi sa itaas, at magkasama silang nagiging Release. Maaaring i-bersyon ang mga release, at sa gayon ay makakamit ang isang organisadong ikot ng buhay: maliit sa oras ng pag-install at malaki sa panahon ng pag-upgrade, pag-downgrade o pag-rollback.

Arkitektura ng timon

Konseptwal na inilalarawan ng diagram ang mataas na antas na arkitektura ng Helm.

Hayaan mong ipaalala ko sa iyo na ang Helm ay isang bagay na may kaugnayan sa Kubernetes. Samakatuwid, hindi natin magagawa nang walang Kubernetes cluster (rectangle). Ang kube-apiserver component ay namamalagi sa master. Kung walang Helm mayroon kaming Kubeconfig. Ang Helm ay nagdadala ng isang maliit na binary, kung matatawag mo itong, Helm CLI utility, na naka-install sa isang computer, laptop, mainframe - sa kahit ano.

Pero hindi ito sapat. Ang Helm ay may bahagi ng server na tinatawag na Tiller. Kinakatawan nito ang mga interes ng Helm sa loob ng cluster; ito ay isang application sa loob ng cluster ng Kubernetes, tulad ng iba pa.

Ang susunod na bahagi ng Chart Repo ay isang repositoryo na may mga chart. Mayroong isang opisyal na imbakan, at maaaring mayroong isang pribadong imbakan ng isang kumpanya o proyekto.

Pakipagtulungan

Tingnan natin kung paano nakikipag-ugnayan ang mga bahagi ng arkitektura kapag gusto nating mag-install ng application gamit ang Helm.

• Nagsasalita tayo Helm install, i-access ang repositoryo (Chart Repo) at kumuha ng Helm chart.

• Nakikipag-ugnayan ang Helm utility (Helm CLI) sa Kubeconfig upang malaman kung aling cluster ang kokontakin. 
• Nang matanggap ang impormasyong ito, tinutukoy ng utility ang Tiller, na matatagpuan sa aming cluster, bilang isang application. 
• Tinawag ni Tiller ang Kube-apiserver upang magsagawa ng mga aksyon sa Kubernetes, lumikha ng ilang bagay (mga serbisyo, pod, replika, sikreto, atbp.).

Susunod, gagawin nating kumplikado ang diagram upang makita ang vector ng pag-atake na maaaring malantad sa buong arkitektura ng Helm sa kabuuan. At pagkatapos ay susubukan naming protektahan siya.

Vektor ng pag-atake

Ang unang potensyal na mahinang punto ay privileged API-gumagamit. Bilang bahagi ng scheme, ito ay isang hacker na nakakuha ng admin access sa Helm CLI.

Unprivileged API user maaari ring magdulot ng panganib kung ito ay nasa malapit na lugar. Magkakaroon ng ibang konteksto ang naturang user, halimbawa, maaari siyang ayusin sa isang cluster namespace sa mga setting ng Kubeconfig.

Ang pinaka-kagiliw-giliw na vector ng pag-atake ay maaaring isang proseso na naninirahan sa loob ng isang kumpol sa isang lugar malapit sa Tiller at maa-access ito. Ito ay maaaring isang web server o microservice na nakikita ang network environment ng cluster.

Ang isang kakaiba, ngunit lalong popular, na variant ng pag-atake ay kinabibilangan ng Chart Repo. Ang isang tsart na ginawa ng isang walang prinsipyong may-akda ay maaaring maglaman ng mga hindi ligtas na mapagkukunan, at makukumpleto mo ito sa pamamagitan ng pananalig. O maaari nitong palitan ang chart na dina-download mo mula sa opisyal na imbakan at, halimbawa, lumikha ng mapagkukunan sa anyo ng mga patakaran at palakihin ang pag-access nito.

Subukan nating palayasin ang mga pag-atake mula sa lahat ng apat na panig na ito at alamin kung saan may mga problema sa arkitektura ng Helm, at kung saan, marahil, wala.

Palakihin natin ang diagram, magdagdag ng higit pang mga elemento, ngunit panatilihin ang lahat ng mga pangunahing bahagi.

Ang Helm CLI ay nakikipag-ugnayan sa Chart Repo, nakikipag-ugnayan sa Kubeconfig, at ang gawain ay inililipat sa cluster sa Tiller component.

Ang Tiller ay kinakatawan ng dalawang bagay:

• Tiller-deploy svc, na naglalantad ng isang partikular na serbisyo;
• Tiller-deploy pod (sa diagram sa isang kopya sa isang replica), kung saan tumatakbo ang buong load, na nag-a-access sa cluster.

Iba't ibang protocol at scheme ang ginagamit para sa pakikipag-ugnayan. Mula sa pananaw ng seguridad, pinakainteresado kami sa:

• Ang mekanismo kung saan ina-access ng Helm CLI ang chart repo: anong protocol, mayroong authentication at kung ano ang maaaring gawin dito.
• Ang protocol kung saan nakikipag-ugnayan ang Helm CLI, gamit ang kubectl, kay Tiller. Ito ay isang RPC server na naka-install sa loob ng cluster.
• Ang Tiller mismo ay naa-access sa mga microservice na naninirahan sa cluster at nakikipag-ugnayan sa Kube-apiserver.

Talakayin natin ang lahat ng mga lugar na ito sa pagkakasunud-sunod.

RBAC

Walang saysay na pag-usapan ang anumang seguridad para sa Helm o anumang iba pang serbisyo sa loob ng cluster maliban kung pinagana ang RBAC.

Mukhang hindi ito ang pinakabagong rekomendasyon, ngunit sigurado ako na maraming mga tao ang hindi pa rin pinagana ang RBAC kahit na sa produksyon, dahil ito ay maraming kaguluhan at maraming mga bagay na kailangang i-configure. Gayunpaman, hinihikayat ko kayong gawin ito.

https://rbac.dev/ — website na abogado para sa RBAC. Naglalaman ito ng isang malaking halaga ng mga kagiliw-giliw na materyales na makakatulong sa iyo na mag-set up ng RBAC, ipakita kung bakit ito ay mabuti at kung paano karaniwang mamuhay kasama nito sa produksyon.

Susubukan kong ipaliwanag kung paano gumagana ang Tiller at RBAC. Gumagana ang Tiller sa loob ng cluster sa ilalim ng isang partikular na account ng serbisyo. Kadalasan, kung hindi naka-configure ang RBAC, ito ang magiging superuser. Sa pangunahing configuration, magiging admin si Tiller. Ito ang dahilan kung bakit madalas na sinasabi na ang Tiller ay isang SSH tunnel sa iyong cluster. Sa katunayan, ito ay totoo, kaya maaari kang gumamit ng isang hiwalay na nakalaang account ng serbisyo sa halip na ang Default na Account ng Serbisyo sa diagram sa itaas.

Kapag sinimulan mo ang Helm at na-install ito sa server sa unang pagkakataon, maaari mong itakda ang account ng serbisyo gamit --service-account. Papayagan ka nitong gumamit ng user na may pinakamababang kinakailangang hanay ng mga karapatan. Totoo, kakailanganin mong lumikha ng ganoong "garland": Role and RoleBinding.

Sa kasamaang palad, hindi ito gagawin ni Helm para sa iyo. Ikaw o ang iyong Kubernetes cluster administrator ay kailangang maghanda ng set ng Mga Tungkulin at RoleBinding para sa service-account nang maaga upang maipasa ang Helm.

Ang tanong ay lumitaw - ano ang pagkakaiba sa pagitan ng Role at ClusterRole? Ang pagkakaiba ay gumagana ang ClusterRole para sa lahat ng namespace, hindi tulad ng mga regular na RoleBinding at RoleBinding, na gumagana lamang para sa isang espesyal na namespace. Maaari mong i-configure ang mga patakaran para sa buong cluster at lahat ng namespace, o i-personalize para sa bawat namespace nang paisa-isa.

Ito ay nagkakahalaga ng pagbanggit na RBAC solves isa pang malaking problema. Maraming tao ang nagrereklamo na ang Helm, sa kasamaang-palad, ay hindi multitenancy (hindi sumusuporta sa multitenancy). Kung maraming team ang kumonsumo ng cluster at gumamit ng Helm, imposibleng mag-set up ng mga patakaran at limitahan ang kanilang access sa cluster na ito, dahil may partikular na account ng serbisyo kung saan tumatakbo ang Helm, at ginagawa nito ang lahat ng mapagkukunan sa cluster mula sa ilalim nito , na kung minsan ay napaka-abala. Ito ay totoo - tulad ng binary file mismo, tulad ng proseso, Ang Helm Tiller ay walang konsepto ng multitenancy.

Gayunpaman, mayroong isang mahusay na paraan na nagbibigay-daan sa iyong patakbuhin ang Tiller nang maraming beses sa isang kumpol. Walang problema dito, maaaring ilunsad ang Tiller sa bawat namespace. Kaya, maaari mong gamitin ang RBAC, Kubeconfig bilang isang konteksto, at limitahan ang pag-access sa isang espesyal na Helm.

Magiging ganito.

Halimbawa, mayroong dalawang Kubeconfig na may konteksto para sa magkaibang team (dalawang namespace): X Team para sa development team at admin cluster. Ang admin cluster ay may sarili nitong malawak na Tiller, na matatagpuan sa Kube-system namespace, isang naaayon na advanced na service-account. At isang hiwalay na namespace para sa development team, magagawa nilang i-deploy ang kanilang mga serbisyo sa isang espesyal na namespace.

Ito ay isang maisasagawa na diskarte, ang Tiller ay hindi masyadong gutom sa kapangyarihan na ito ay lubos na makakaapekto sa iyong badyet. Isa ito sa mga mabilisang solusyon.

Huwag mag-atubiling i-configure ang Tiller nang hiwalay at bigyan ang Kubeconfig ng konteksto para sa koponan, para sa isang partikular na developer o para sa kapaligiran: Dev, Staging, Production (ito ay duda na ang lahat ay nasa parehong cluster, gayunpaman, magagawa ito).

Sa pagpapatuloy ng aming kuwento, lumipat tayo mula sa RBAC at pag-usapan ang tungkol sa ConfigMaps.

ConfigMaps

Gumagamit ang Helm ng ConfigMaps bilang data store nito. Noong pinag-usapan natin ang tungkol sa arkitektura, walang database kahit saan na mag-iimbak ng impormasyon tungkol sa mga release, configuration, rollback, atbp. ConfigMaps ang ginagamit para dito.

Ang pangunahing problema sa ConfigMaps ay kilala - sila ay hindi ligtas sa prinsipyo; imposibleng mag-imbak ng sensitibong data. Pinag-uusapan natin ang lahat ng hindi dapat lumampas sa serbisyo, halimbawa, mga password. Ang pinaka-katutubong paraan para sa Helm ngayon ay ang lumipat mula sa paggamit ng ConfigMaps sa mga lihim.

Ginagawa ito nang napakasimple. I-override ang setting ng Tiller at tukuyin na magiging mga lihim ang storage. Pagkatapos para sa bawat deployment makakatanggap ka ng hindi isang ConfigMap, ngunit isang lihim.

Maaari kang magtaltalan na ang mga lihim mismo ay isang kakaibang konsepto at hindi masyadong secure. Gayunpaman, ito ay nagkakahalaga ng pag-unawa na ang mga developer ng Kubernetes mismo ang gumagawa nito. Simula sa bersyon 1.10, i.e. Sa loob ng mahabang panahon ngayon, posible, kahit sa mga pampublikong ulap, na ikonekta ang tamang imbakan upang mag-imbak ng mga lihim. Gumagawa na ngayon ang team ng mga paraan para mas mahusay na maipamahagi ang access sa mga lihim, indibidwal na pod, o iba pang entity.

Mas mainam na ilipat ang Storage Helm sa mga lihim, at sila naman, ay naka-secure sa gitna.

Siyempre mananatili ito limitasyon ng imbakan ng data na 1 MB. Gumagamit ang Helm dito ng etcd bilang distributed storage para sa ConfigMaps. At doon ay isinasaalang-alang nila na ito ay isang angkop na tipak ng data para sa pagtitiklop, atbp. Mayroong isang kawili-wiling talakayan tungkol dito sa Reddit, inirerekumenda ko ang paghahanap ng nakakatawang pagbabasa para sa katapusan ng linggo o pagbabasa ng katas dito.

Mga Repos ng Tsart

Ang mga chart ay ang pinaka-mahina sa lipunan at maaaring maging mapagkukunan ng "Man in the middle", lalo na kung gumagamit ka ng stock solution. Una sa lahat, pinag-uusapan natin ang tungkol sa mga repositoryo na nakalantad sa pamamagitan ng HTTP.

Talagang kailangan mong ilantad ang Helm Repo sa HTTPS - ito ang pinakamahusay na opsyon at mura.

Tandaan ang mekanismo ng lagda ng tsart. Ang teknolohiya ay simple bilang impiyerno. Ito ang parehong bagay na ginagamit mo sa GitHub, isang regular na PGP machine na may pampubliko at pribadong key. I-set up at siguraduhin, pagkakaroon ng mga kinakailangang key at pagpirma sa lahat, na ito talaga ang iyong tsart.

Bilang karagdagan, Sinusuportahan ng kliyente ng helm ang TLS (hindi sa server-side na HTTP sense, ngunit mutual TLS). Maaari mong gamitin ang mga susi ng server at kliyente upang makipag-usap. Sa totoo lang, hindi ako gumagamit ng ganoong mekanismo dahil hindi ko gusto ang mutual certificate. Talaga, chartmuseum - ang pangunahing tool para sa pag-set up ng Helm Repo para sa Helm 2 - sinusuportahan din ang pangunahing auth. Maaari mong gamitin ang pangunahing auth kung ito ay mas maginhawa at mas tahimik.

Mayroon ding isang plugin helm-gcs, na nagbibigay-daan sa iyong mag-host ng mga Chart Repos sa Google Cloud Storage. Ito ay medyo maginhawa, gumagana nang mahusay at medyo ligtas, dahil ang lahat ng inilarawan na mga mekanismo ay na-recycle.

Kung pinagana mo ang HTTPS o TLS, gumamit ng mTLS, at pinagana ang pangunahing auth upang higit pang mabawasan ang mga panganib, makakakuha ka ng secure na channel ng komunikasyon sa Helm CLI at Chart Repo.

gRPC API

Ang susunod na hakbang ay napakahalaga - upang ma-secure ang Tiller, na matatagpuan sa kumpol at, sa isang banda, isang server, sa kabilang banda, ito mismo ang nag-a-access sa iba pang mga bahagi at sinusubukang magpanggap na isang tao.

Gaya ng nasabi ko na, ang Tiller ay isang serbisyong naglalantad ng gRPC, ang kliyente ng Helm ay dumarating dito sa pamamagitan ng gRPC. Bilang default, siyempre, hindi pinagana ang TLS. Kung bakit ito ginawa ay isang mapagtatalunang tanong, tila sa akin ay pasimplehin ang pag-setup sa simula.

Para sa produksyon at maging sa pagtatanghal, inirerekomenda kong i-enable ang TLS sa gRPC.

Sa palagay ko, hindi tulad ng mTLS para sa mga tsart, ito ay angkop dito at ginagawa nang napakasimple - bumuo ng isang imprastraktura ng PQI, lumikha ng isang sertipiko, ilunsad ang Tiller, ilipat ang sertipiko sa panahon ng pagsisimula. Pagkatapos nito, maaari mong isagawa ang lahat ng utos ng Helm, na ipinapakita ang iyong sarili sa nabuong certificate at pribadong key.

Sa ganitong paraan mapoprotektahan mo ang iyong sarili mula sa lahat ng kahilingan sa Tiller mula sa labas ng cluster.

Kaya, na-secure namin ang channel ng koneksyon sa Tiller, napag-usapan na namin ang RBAC at inayos ang mga karapatan ng apiserver ng Kubernetes, na binabawasan ang domain kung saan maaari itong makipag-ugnayan.

Protektadong Helm

Tingnan natin ang huling diagram. Ito ay ang parehong arkitektura na may parehong mga arrow.

Ang lahat ng mga koneksyon ay maaari na ngayong ligtas na iguguhit sa berde:

• para sa Chart Repo gumagamit kami ng TLS o mTLS at basic na auth;
• mTLS para sa Tiller, at nalantad ito bilang serbisyo ng gRPC na may TLS, gumagamit kami ng mga certificate;
• gumagamit ang cluster ng isang espesyal na account ng serbisyo na may Role at RoleBinding. 

Na-secure na namin ang cluster, ngunit may isang matalinong nagsabi:

"Mayroon lamang isang ganap na ligtas na solusyon - isang naka-off na computer, na matatagpuan sa isang kongkretong kahon at binabantayan ng mga sundalo."

Mayroong iba't ibang paraan upang manipulahin ang data at maghanap ng mga bagong vector ng pag-atake. Gayunpaman, tiwala ako na makakamit ng mga rekomendasyong ito ang isang pangunahing pamantayan ng industriya para sa kaligtasan.

Bonus

Ang bahaging ito ay hindi direktang nauugnay sa seguridad, ngunit magiging kapaki-pakinabang din. Ipapakita ko sa iyo ang ilang mga kawili-wiling bagay na kakaunti lang ang nakakaalam. Halimbawa, kung paano maghanap ng mga chart - opisyal at hindi opisyal.

Sa repositoryo github.com/helm/charts Ngayon ay may humigit-kumulang 300 chart at dalawang stream: stable at incubator. Alam na alam ng sinumang mag-aambag kung gaano kahirap na lumipat mula sa incubator patungo sa kuwadra, at kung gaano kadaling lumipad palabas ng kuwadra. Gayunpaman, hindi ito ang pinakamahusay na tool upang maghanap ng mga chart para sa Prometheus at kung ano pa man ang gusto mo, sa isang simpleng dahilan - hindi ito isang portal kung saan maaari kang maginhawang maghanap ng mga pakete.

Pero may serbisyo hub.helm.sh, na ginagawang mas maginhawang maghanap ng mga chart. Pinakamahalaga, marami pang mga panlabas na repositoryo at halos 800 anting-anting na magagamit. Dagdag pa, maaari mong ikonekta ang iyong repository kung sa ilang kadahilanan ay hindi mo gustong ipadala ang iyong mga chart sa stable.

Subukan ang hub.helm.sh at sabay nating paunlarin ito. Ang serbisyong ito ay nasa ilalim ng proyekto ng Helm, at maaari ka ring mag-ambag sa UI nito kung ikaw ay isang front-end na developer at gusto lang pagandahin ang hitsura.

Nais ko ring maakit ang iyong pansin Open Service Broker API integration. Mukhang mahirap at hindi malinaw, ngunit nalulutas nito ang mga problema na kinakaharap ng lahat. Hayaan akong ipaliwanag sa isang simpleng halimbawa.

Mayroong Kubernetes cluster kung saan gusto naming magpatakbo ng isang klasikong application - WordPress. Sa pangkalahatan, ang isang database ay kailangan para sa buong pag-andar. Mayroong maraming iba't ibang mga solusyon, halimbawa, maaari mong ilunsad ang iyong sariling statefull na serbisyo. Hindi ito masyadong maginhawa, ngunit ginagawa ito ng maraming tao.

Ang iba, tulad namin sa Chainstack, ay gumagamit ng mga pinamamahalaang database tulad ng MySQL o PostgreSQL para sa kanilang mga server. Iyon ang dahilan kung bakit ang aming mga database ay matatagpuan sa isang lugar sa cloud.

Ngunit lumitaw ang isang problema: kailangan naming ikonekta ang aming serbisyo sa isang database, lumikha ng lasa ng database, ilipat ang kredensyal at kahit papaano ay pamahalaan ito. Ang lahat ng ito ay karaniwang ginagawa nang manu-mano ng system administrator o developer. At walang problema kapag kakaunti ang mga aplikasyon. Kapag marami sila, kailangan mo ng combine. Mayroong ganoong harvester - ito ay Service Broker. Pinapayagan ka nitong gumamit ng isang espesyal na plugin para sa isang pampublikong cloud cluster at mag-order ng mga mapagkukunan mula sa provider sa pamamagitan ng Broker, na parang ito ay isang API. Upang gawin ito, maaari mong gamitin ang mga native na tool ng Kubernetes.

Ito ay napaka-simple. Maaari kang mag-query, halimbawa, Managed MySQL sa Azure na may base tier (maaari itong i-configure). Gamit ang Azure API, ang database ay gagawin at ihahanda para sa paggamit. Hindi mo kailangang panghimasukan ito, ang plugin ang may pananagutan para dito. Halimbawa, ibabalik ng OSBA (Azure plugin) ang kredensyal sa serbisyo at ipapasa ito sa Helm. Magagawa mong gamitin ang WordPress gamit ang cloud MySQL, hindi haharapin ang mga pinamamahalaang database at huwag mag-alala tungkol sa mga statefull na serbisyo sa loob.

Masasabi nating gumaganap ang Helm bilang pandikit na, sa isang banda, ay nagbibigay-daan sa iyong mag-deploy ng mga serbisyo, at sa kabilang banda, ubusin ang mga mapagkukunan ng mga cloud provider.

Maaari kang sumulat ng sarili mong plugin at gamitin ang buong kwentong ito sa lugar. Pagkatapos ay magkakaroon ka lang ng sarili mong plugin para sa corporate Cloud provider. Inirerekomenda kong subukan ang diskarteng ito, lalo na kung mayroon kang malaking sukat at gusto mong mabilis na i-deploy ang dev, staging, o ang buong imprastraktura para sa isang feature. Gagawin nitong mas madali ang buhay para sa iyong mga operasyon o DevOps.

Ang isa pang natuklasan na nabanggit ko na ay plugin ng helm-gcs, na nagbibigay-daan sa iyong gumamit ng Google-buckets (imbakan ng object) para mag-imbak ng mga Helm chart.

Kailangan mo lamang ng apat na utos upang simulan ang paggamit nito:

1. i-install ang plugin;
2. simulan ito;
3. itakda ang landas sa bucket, na matatagpuan sa gcp;
4. mag-publish ng mga tsart sa karaniwang paraan.

Ang kagandahan ay ang katutubong gcp na pamamaraan ay gagamitin para sa awtorisasyon. Maaari kang gumamit ng service account, developer account, kahit anong gusto mo. Ito ay napaka-maginhawa at walang gastos sa pagpapatakbo. Kung ikaw, tulad ko, ay nagpo-promote ng opsless na pilosopiya, kung gayon ito ay magiging maginhawa, lalo na para sa mga maliliit na koponan.

Mga alternatibo

Ang Helm ay hindi lamang ang solusyon sa pamamahala ng serbisyo. Mayroong maraming mga katanungan tungkol dito, na marahil kung bakit ang ikatlong bersyon ay lumitaw nang napakabilis. Syempre may mga alternatibo.

Ang mga ito ay maaaring mga espesyal na solusyon, halimbawa, Ksonnet o Metaparticle. Maaari mong gamitin ang iyong mga klasikong tool sa pamamahala ng imprastraktura (Ansible, Terraform, Chef, atbp.) para sa parehong mga layunin na pinag-usapan ko.

Sa wakas may solusyon na Framework ng Operator, na ang katanyagan ay lumalaki.

Ang Operator Framework ay ang nangungunang alternatibong Helm na dapat isaalang-alang.

Ito ay mas katutubong sa CNCF at Kubernetes, ngunit ang hadlang sa pagpasok ay mas mataas, kailangan mong mag-program nang higit pa at ilarawan ang mga manifest nang mas kaunti.

Mayroong iba't ibang mga addon, tulad ng Draft, Scaffold. Mas pinadali nila ang buhay, halimbawa, pinapasimple nila ang cycle ng pagpapadala at paglulunsad ng Helm para sa mga developer na mag-deploy ng isang pagsubok na kapaligiran. Tatawagin ko silang empowerers.

Narito ang isang visual na tsart kung nasaan ang lahat.

Sa x-axis ay ang antas ng iyong personal na kontrol sa kung ano ang nangyayari, sa y-axis ay ang antas ng nativeness ng Kubernetes. Ang bersyon 2 ng Helm ay nahuhulog sa isang lugar sa gitna. Sa bersyon 3, hindi napakalaki, ngunit parehong kontrol at ang antas ng katutubo ay napabuti. Ang mga solusyon sa antas ng Ksonnet ay mas mababa pa rin kahit sa Helm 2. Gayunpaman, sulit na tingnan ang mga ito upang malaman kung ano pa ang nasa mundong ito. Siyempre, ang iyong configuration manager ay mapapailalim sa iyong kontrol, ngunit ito ay ganap na hindi katutubong sa Kubernetes.

Ang Operator Framework ay ganap na katutubong sa Kubernetes at nagbibigay-daan sa iyo na pamahalaan ito nang mas elegante at maingat (ngunit tandaan ang tungkol sa antas ng pagpasok). Sa halip, ito ay angkop para sa isang dalubhasang aplikasyon at ang paglikha ng pamamahala para dito, sa halip na isang mass harvester para sa pag-iimpake ng malaking bilang ng mga aplikasyon gamit ang Helm.

Pinapabuti lang ng mga extender ang kontrol nang kaunti, umaakma sa daloy ng trabaho, o pumutol sa mga pipeline ng CI/CD.

Ang kinabukasan ng Helm

Ang magandang balita ay darating na ang Helm 3. Ang alpha na bersyon ng Helm 3.0.0-alpha.2 ay inilabas na, maaari mo itong subukan. Ito ay medyo matatag, ngunit ang pag-andar ay limitado pa rin.

Bakit kailangan mo ng Helm 3? Una sa lahat, ito ay isang kwento tungkol sa pagkawala ni Tiller, bilang isang bahagi. Ito, tulad ng naiintindihan mo na, ay isang malaking hakbang pasulong, dahil mula sa punto ng view ng seguridad ng arkitektura, ang lahat ay pinasimple.

Noong ginawa ang Helm 2, na noong panahon ng Kubernetes 1.8 o mas maaga pa, marami sa mga konsepto ay hindi pa nasa hustong gulang. Halimbawa, ang konsepto ng CRD ay aktibong ipinapatupad na ngayon, at gagawin ni Helm gumamit ng CRDupang mag-imbak ng mga istruktura. Magiging posible na gamitin lamang ang kliyente at hindi mapanatili ang bahagi ng server. Alinsunod dito, gumamit ng mga katutubong Kubernetes na utos upang gumana sa mga istruktura at mapagkukunan. Ito ay isang malaking hakbang pasulong.

Lilitaw suporta para sa mga katutubong repositoryo ng OCI (Open Container Initiative). Ito ay isang malaking inisyatiba, at ang Helm ay pangunahing interesado upang mai-post ang mga chart nito. Dumating sa punto na, halimbawa, sinusuportahan ng Docker Hub ang maraming pamantayan ng OCI. Hindi ko hulaan, ngunit marahil ang mga klasikong tagapagbigay ng repositoryo ng Docker ay magsisimulang magbigay sa iyo ng pagkakataong i-host ang iyong mga Helm chart.

Ang kontrobersyal na kuwento para sa akin ay suporta ni Lua, bilang isang templating engine para sa pagsusulat ng mga script. Hindi ako isang malaking tagahanga ni Lua, ngunit ito ay magiging isang ganap na opsyonal na tampok. Sinuri ko ito ng 3 beses - hindi na kakailanganin ang paggamit ng Lua. Samakatuwid, ang mga gustong gumamit ng Lua, ang mga may gusto kay Go, sumali sa aming malaking kampo at gumamit ng go-tmpl para dito.

Sa wakas, ang talagang kulang sa akin ay paglitaw ng schema at pagpapatunay ng uri ng data. Wala nang magiging problema sa int o string, hindi na kailangang balutin ang zero sa double quotes. May lalabas na JSONS schema na magbibigay-daan sa iyong tahasang ilarawan ito para sa mga value.

Ire-rework nang husto modelong batay sa kaganapan. Inilarawan na ito sa konsepto. Tingnan ang Helm 3 branch, at makikita mo kung gaano karaming mga kaganapan at kawit at iba pang mga bagay ang naidagdag, na lubos na magpapasimple at, sa kabilang banda, magdaragdag ng kontrol sa mga proseso ng pag-deploy at mga reaksyon sa mga ito.

Ang Helm 3 ay magiging mas simple, mas ligtas, at mas masaya, hindi dahil hindi namin gusto ang Helm 2, ngunit dahil nagiging mas advanced ang Kubernetes. Alinsunod dito, maaaring gamitin ng Helm ang mga pagpapaunlad ng Kubernetes at lumikha ng mahuhusay na tagapamahala para sa Kubernetes dito.

Isa pang magandang balita ay iyon DevOpsConf Sasabihin sa iyo ni Alexander Khayorov, maaari bang maging ligtas ang mga lalagyan? Ipaalala namin sa iyo na ang kumperensya sa pagsasama ng mga proseso ng pag-unlad, pagsubok at operasyon ay gaganapin sa Moscow Setyembre 30 at Oktubre 1. Magagawa mo pa rin ito hanggang Agosto 20 magsumite ng ulat at sabihin sa amin ang tungkol sa iyong karanasan sa solusyon isa sa marami mga gawain ng diskarte sa DevOps.

Sundan ang mga checkpoint at balita sa kumperensya sa newsletter и channel ng telegrama.

Pinagmulan: www.habr.com