L'essenza di a storia nantu à u gestore di pacchetti più populari per Kubernetes puderia esse rapprisintatu cù un emoji:
- a scatula hè Helm (chì hè a cosa più vicinu à l'ultima versione Emoji);
- serratura - sicurità;
- u picculu omu hè a suluzione à u prublema.
In fatti, tuttu serà un pocu più cumplicatu, è a storia hè piena di dettagli tecnichi Cumu fà Helm sicuru.
- In breve ciò chì Helm hè in casu chì ùn sapete micca o scurdate. Chì prublemi risolve è induve si trova in l'ecosistema.
- Fighjemu l'architettura Helm. Nisuna conversazione nantu à a sicurità è cumu fà un strumentu o suluzione più sicura hè cumpleta senza capisce l'architettura di u cumpunente.
- Discutemu di cumpunenti Helm.
- A quistione più ardente hè u futuru - a nova versione di Helm 3.
Tuttu in questu articulu s'applica à Helm 2. Questa versione hè attualmente in produzzione è hè più prubabilmente quella chì avete aduprà, è hè a versione chì cuntene i risichi di sicurità.
À propositu di u parlante: Alexander Khayorov () hà sviluppatu dapoi 10 anni, aiutendu à migliurà u cuntenutu è hà unitu à u cumitatu . Avà travaglia in Chainstack cum'è un capu di sviluppu - questu hè un hibridu trà un manager di sviluppu è una persona chì hè rispunsevule per a consegna di e versioni finali. Questu hè, si trova nantu à u campu di battaglia, induve tuttu passa da a creazione di un pruduttu à u so funziunamentu.
Chainstack hè una piccula startup in crescita attiva chì a so missione hè di permette à i clienti di scurdà di l'infrastruttura è a cumplessità di l'operazioni di l'applicazioni decentralizate; u squadra di sviluppu si trova in Singapore. Ùn dumandate micca à Chainstack di vende o cumprà criptocurrency, ma offre di parlà di i frameworki di blockchain d'impresa, è vi risponderanu cun piacè.
Helm
Questu hè un gestore di pacchetti (chart) per Kubernetes. U modu più intuitivu è universale per purtà l'applicazioni à un cluster Kubernetes.
Semu, sicuru, parlendu di un accostu più strutturale è industriale chè di creà i vostri manifesti YAML è scrive picculi utilities.
Helm hè u megliu chì hè attualmente dispunibule è populari.
Perchè Helm? Principalmente perchè hè supportatu da u CNCF. Cloud Native hè una grande urganizazione è hè a parent company per prughjetti Kubernetes, etcd, Fluentd è altri.
Un altru fattu impurtante hè chì Helm hè un prughjettu assai populari. Quandu aghju cuminciatu à parlà di cumu fà Helm sicuru in ghjennaghju 2019, u prughjettu avia mille stelle in GitHub. Da maghju ci era 12 mila di elli.
Parechje persone sò interessate in Helm, cusì ancu s'ellu ùn l'avete micca utilizatu ancu, vi prufittà di cunnosce a so sicurità. A sicurità hè impurtante.
U core Helm team hè supportatu da Microsoft Azure è hè dunque un prughjettu abbastanza stabile, à u cuntrariu di parechji altri. A liberazione di Helm 3 Alpha 2 à a mità di lugliu indica chì ci sò assai persone chì travaglianu nantu à u prugettu, è anu u desideriu è l'energia di sviluppà è migliurà Helm.
Helm risolve parechji prublemi radicali di gestione di l'applicazioni in Kubernetes.
- Imballaggio di l'applicazione. Ancu una applicazione cum'è "Hello, World" in WordPress hè digià custituita da parechji servizii, è vulete imballate inseme.
- Gestisce a cumplessità chì vene cù a gestione di queste applicazioni.
- Un ciclu di vita chì ùn finisci micca dopu chì l'applicazione hè stallata o implementata. Cuntinueghja à campà, deve esse aghjurnatu, è Helm aiuta cù questu è prova di portà e misure è e pulitiche ghjustificate per questu.
Insaccatura hè urganizatu in modu chjaru: ci sò metadata in piena cunfurmità cù u travagliu di un gestore di pacchetti regulare per Linux, Windows o MacOS. Questu hè, un repository, dipendenze nantu à diversi pacchetti, meta infurmazione per l'applicazioni, paràmetri, funzioni di cunfigurazione, indexazione di l'infurmazioni, etc. Helm permette di ottene è aduprà tuttu questu per l'applicazioni.
Gestione di cumplessità. Se tenete parechje applicazioni di u stessu tipu, allora a parametrizzazione hè necessaria. I mudelli venenu da questu, ma per evità di avè da vene cù u vostru propiu modu di creà mudelli, pudete aduprà ciò chì Helm prupone fora di a scatula.
Gestione di u Ciclu di Vita di l'Applicazione - in u mo parè, questu hè a quistione più interessante è micca risolta. Hè per quessa ch'e aghju vinutu à Helm in u ghjornu. Avemu bisognu di monitorà u ciclu di vita di l'applicazioni è vulianu trasfurmà u nostru CI / CD è i ciculi di l'applicazione à questu paradigma.
Helm vi permette di:
- gestisce e implementazioni, introduce u cuncettu di cunfigurazione è rivisione;
- rializà successu rollback;
- aduprà ganci per diversi avvenimenti;
- aghjunghje cuntrolli di l'applicazione supplementari è risponde à i so risultati.
Inoltre Helm hà "batterie" - un gran numaru di cose gustose chì ponu esse incluse in forma di plugins, simplificà a vostra vita. I plugins ponu esse scritti indipindentamente, sò abbastanza isolati è ùn anu micca bisognu di una architettura armoniosa. Se vulete implementà qualcosa, ricumandemu di fà cum'è un plugin, è possibbilmente includendu in upstream.
Helm hè basatu annantu à trè cuncetti principali:
- Chart Repo - descrizzione è array di parametrizzazioni pussibuli per u vostru manifestu.
- Config - vale à dì i valori chì saranu applicati (testu, valori numerichi, etc.).
- Release raccoglie i dui cumpunenti superiore, è inseme si trasformanu in Release. E versioni ponu esse versionate, ottenendu cusì un ciculu di vita urganizatu: chjuca à u mumentu di a stallazione è grande à u mumentu di l'upgrade, downgrade o rollback.
Architettura di Helm
U diagramma descrive conceptualmente l'architettura di altu livellu di Helm.
Lasciami ricurdà chì Helm hè qualcosa ligatu à Kubernetes. Dunque, ùn pudemu micca fà senza un cluster Kubernetes (rectangle). U cumpunente kube-apiserver reside nantu à u maestru. Senza Helm avemu Kubeconfig. Helm porta un picculu binariu, se pudete chjamà cusì, Helm CLI utility, chì hè stallatu in un computer, laptop, mainframe - nantu à qualcosa.
Ma questu ùn hè micca abbastanza. Helm hà un cumpunente di servitore chjamatu Tiller. Rapprisenta l'interessi di Helm in u cluster; hè una applicazione in u cluster Kubernetes, cum'è qualsiasi altru.
U prossimu cumpunente di Chart Repo hè un repository cù charts. Ci hè un repositoriu ufficiale, è pò esse un repositoriu privatu di una cumpagnia o prughjettu.
Interaction
Fighjemu cumu i cumpunenti di l'architettura interagiscenu quandu vulemu installà una applicazione cù Helm.
- Parlemu
Helm install, accede à u repository (Chart Repo) è uttene un graficu Helm.
- L'utilità Helm (Helm CLI) interagisce cù Kubeconfig per capisce quale cluster cuntattà.
- Dopu avè ricevutu sta infurmazione, l'utilità si riferisce à Tiller, chì si trova in u nostru cluster, cum'è una applicazione.
- Tiller chjama Kube-apiserver per realizà azzioni in Kubernetes, creà alcuni oggetti (servizi, pods, rèpliche, secreti, etc.).
In seguitu, complicà u diagramma per vede u vettore d'attaccu chì tutta l'architettura Helm in tuttu pò esse esposta. È tandu pruveremu di prutege.
Vettore d'attaccu
U primu puntu debule potenziale hè API privilegiata-l 'utilizatori. Comu parte di u schema, questu hè un pirate chì hà acquistatu l'accessu amministratore à l'Helm CLI.
Utenti API senza privilegiu pò ancu esse un periculu s'ellu hè in qualchì locu vicinu. Un tali utilizatore averà un cuntestu diversu, per esempiu, pò esse riparatu in un spaziu di nome di cluster in i paràmetri di Kubeconfig.
U vettore d'attaccu più interessante pò esse un prucessu chì si trova in un cluster in un locu vicinu à Tiller è pò accede. Questu pò esse un servitore web o microserviziu chì vede l'ambiente di a rete di u cluster.
Una variante di attaccu esotica, ma sempre più populari, implica Chart Repo. Un gràficu creatu da un autore senza scrupulu pò cuntene risorse insicure, è vi compie cù a fede. O pò rimpiazzà a carta chì scaricate da u repositoriu ufficiale è, per esempiu, crea una risorsa in forma di pulitiche è escalate u so accessu.
Pruvemu di scaccià l'attacchi da tutti questi quattru lati è scopre induve ci sò prublemi in l'architettura Helm, è induve, forsi, ùn ci hè nimu.
Ingrandemu u diagramma, aghjunghje più elementi, ma mantene tutti i cumpunenti basi.
L'Helm CLI cumunicà cù u Chart Repo, interagisce cù Kubeconfig, è u travagliu hè trasferitu à u cluster à u cumpunente Tiller.
Tiller hè rapprisintatu da dui ogetti:
- Tiller-deploy svc, chì espone un certu serviziu;
- Tiller-deploy pod (in u diagramma in una sola copia in una replica), nantu à quale tutta a carica corre, chì accede à u cluster.
Diversi protokolli è schemi sò usati per l'interazzione. Da un puntu di vista di sicurità, ci interessa più à:
- U mecanismu da quale Helm CLI accede à u repo chart: quale protocolu, ci hè autentificazione è ciò chì pò esse fattu cun ellu.
- U protokollu da quale Helm CLI, utilizendu kubectl, cumunicà cù Tiller. Questu hè un servitore RPC installatu in u cluster.
- Tiller stessu hè accessibile à i microservizi chì residenu in u cluster è interagisce cù u Kube-apiserver.
Discutemu tutti questi spazii in ordine.
RBAC
Ùn ci hè nunda di parlà di alcuna sicurità per Helm o qualsiasi altru serviziu in u cluster, salvu chì RBAC hè attivatu.
Sembra chì questu ùn hè micca l'ultime ricunniscenza, ma sò sicuru chì assai persone ùn anu micca attivatu RBAC ancu in a produzzione, perchè hè assai fugliali è assai cose deve esse cunfigurate. Tuttavia, vi incuraghjemu à fà questu.
- avucatu di u situ web per RBAC. Contene una quantità enorme di materiali interessanti chì vi aiuterà à stallà RBAC, dimustrà perchè hè bonu è cumu si basamente vive cun ellu in a produzzione.
Pruvaraghju di spiegà cumu funziona Tiller è RBAC. Tiller travaglia in u cluster sottu un certu contu di serviziu. Di genere, se RBAC ùn hè micca cunfiguratu, questu serà u superuser. In a cunfigurazione basica, Tiller serà un amministratore. Hè per quessa chì si dice spessu chì Tiller hè un tunnel SSH à u vostru cluster. In fatti, questu hè veru, cusì pudete aduprà un cuntu di serviziu dedicatu separatu invece di u Contu di serviziu predeterminatu in u schema sopra.
Quandu avete inizializatu Helm è installate nantu à u servitore per a prima volta, pudete stabilisce u contu di serviziu utilizendu --service-account. Questu permetterà di utilizà un utilizatore cù u minimu minimu di diritti. True, vi tuccherà à creà un tali "ghirlanda": Role è RoleBinding.
Sfurtunatamente, Helm ùn farà micca questu per voi. Voi o u vostru amministratore di cluster Kubernetes avete bisognu di preparà un set di Roles and RoleBindings per u serviziu di serviziu in anticipu per passà Helm.
A quistione sorge - chì hè a diffarenza trà Role è ClusterRole? A diffarenza hè chì ClusterRole travaglia per tutti i spazii di nomi, à u cuntrariu di Role regulare è RoleBindings, chì travaglianu solu per un spaziu di nomi specializatu. Pudete cunfigurà pulitiche per tuttu u cluster è tutti i spazii di nomi, o persunalizate per ogni spaziu di nomi individualmente.
Hè da nutà chì RBAC risolve un altru prublema maiò. Parechje persone si lamentanu chì Helm, sfurtunatamenti, ùn hè micca multitenancy (ùn sustene micca multitenancy). Se parechji squadre cunsumanu un cluster è utilizanu Helm, hè basicamente impussibile di stabilisce e pulitiche è limità u so accessu in questu cluster, perchè ci hè un certu contu di serviziu sottu à quale Helm corre, è crea tutte e risorse in u cluster da sottu. , chì qualchì volta assai inconveniente. Questu hè veru - cum'è u schedariu binariu stessu, cum'è u prucessu, Helm Tiller ùn hà micca cuncettu di multitenancy.
Tuttavia, ci hè una grande manera chì vi permette di eseguisce Tiller parechje volte in un cluster. Ùn ci hè micca prublema cù questu, Tiller pò esse lanciatu in ogni namespace. Cusì, pudete aduprà RBAC, Kubeconfig cum'è un cuntestu, è limità l'accessu à un Helm speciale.
Serà cusì.
Per esempiu, ci sò dui Kubeconfigs cun cuntestu per e diverse squadre (dui spazii di nomi): X Team per a squadra di sviluppu è u cluster admin. U cluster admin hà u so propiu Tiller largu, chì si trova in u spaziu di nomi di u sistema Kube, un cuntu di serviziu avanzatu currispundente. È un spaziu di nome separatu per a squadra di sviluppu, puderanu implementà i so servizii à un spaziu di nome speciale.
Questu hè un approcciu praticabile, Tiller ùn hè micca cusì fame di putere chì affetterà assai u vostru budgetu. Questa hè una di e soluzioni veloci.
Sentite liberu di cunfigurà Tiller separatamente è furnisce Kubeconfig cun cuntestu per a squadra, per un sviluppatore specificu o per l'ambiente: Dev, Staging, Production (hè dubbitu chì tuttu serà in u stessu cluster, però, questu pò esse fattu).
Cuntinuendu a nostra storia, andemu da RBAC è parlemu di ConfigMaps.
ConfigMaps
Helm usa ConfigMaps cum'è u so magazzinu di dati. Quandu avemu parlatu di l'architettura, ùn ci era micca una basa di dati in ogni locu chì guardà l'infurmazioni nantu à e versioni, cunfigurazioni, rollbacks, etc. ConfigMaps hè utilizatu per questu.
U prublema principali cun ConfigMaps hè cunnisciutu - in principiu ùn sò micca sicuri; hè impussibile di almacenà dati sensittivi. Parlemu di tuttu ciò chì ùn deve micca esse fora di u serviziu, per esempiu, password. U modu più nativu per Helm avà hè di passà da l'usu di ConfigMaps à i secreti.
Questu hè fattu assai simplice. Override u paràmetru di Tiller è specificate chì u almacenamentu serà secretu. Allora per ogni implementazione ùn riceverete micca un ConfigMap, ma un sicretu.
Pudete argumentà chì i sicreti stessi sò un cuncettu stranu è micca assai sicuru. Tuttavia, vale a pena capisce chì i sviluppatori di Kubernetes stessi facenu questu. Partendu da a versione 1.10, i.e. Dapoi un bellu pezzu, hè statu pussibule, almenu in i nuvuli publichi, per cunnette l'almacenamiento currettu per almacenà i sicreti. A squadra travaglia avà nantu à modi per distribuisce megliu l'accessu à i sicreti, pods individuali o altre entità.
Hè megliu trasferisce Storage Helm à i sicreti, è elli, à u turnu, sò assicurati cintrali.
Di sicuru, ferma limitu di almacenamiento di dati di 1 MB. Helm quì usa etcd cum'è almacenamiento distribuitu per ConfigMaps. E quì anu cunsideratu chì questu era un pezzu di dati adattatu per a replicazione, etc. Ci hè una discussione interessante nantu à questu nantu à Reddit, ricumandemu di truvà sta lettura divertente per u weekend o leghje l'estrattu .
Chart Repos
I grafici sò i più vulnerabili suciali è ponu diventà una fonte di "Omu à mezu", soprattuttu s'è vo aduprate una solu suluzione. Prima di tuttu, parlemu di repositori chì sò esposti via HTTP.
Avete bisognu di espose Helm Repo nantu à HTTPS - questa hè a megliu opzione è ùn hè micca caru.
attenti à mecanismu di firma di carta. A tecnulugia hè simplice cum'è l'infernu. Questa hè a stessa cosa chì utilizate in GitHub, una macchina PGP regulare cù chjavi publichi è privati. Configurate è assicuratevi, avè i chjavi necessarii è firmà tuttu, chì questu hè veramente u vostru cartulare.
Inoltre, U cliente Helm supporta TLS (micca in u sensu HTTP di u servitore, ma TLS mutuale). Pudete utilizà chjavi di u servitore è di u cliente per cumunicà. Per esse onesto, ùn aghju micca aduprà un tali mecanismu perchè ùn mi piace micca i certificati mutuali. In fondu, - l'uttellu principale per a creazione di Helm Repo per Helm 2 - supporta ancu l'auth basica. Pudete aduprà l'autenticazione basica s'ellu hè più cunvene è più tranquillu.
Ci hè ancu un plugin , chì vi permette di accoglie Chart Repos in Google Cloud Storage. Questu hè abbastanza cunvene, funziona bè è hè abbastanza sicuru, perchè tutti i miccanismi descritti sò riciclati.
Se attivate HTTPS o TLS, utilizate mTLS, è attivate l'autenticazione basica per riduce ancu i risichi, uttene un canale di cumunicazione sicuru cù Helm CLI è Chart Repo.
API gRPC
U passu prossimu hè assai impurtante - per assicurà Tiller, chì si trova in u cluster è hè, da una banda, un servitore, da l'altra banda, ellu stessu accede à l'altri cumpunenti è prova di fà finta di esse qualchissia.
Cumu l'aghju digià dettu, Tiller hè un serviziu chì espone gRPC, u cliente Helm vene à ellu via gRPC. Per automaticamente, sicuru, TLS hè disattivatu. Perchè questu hè statu fattu hè una quistione discutibile, mi pari di simplificà a stallazione à u principiu.
Per a produzzione è ancu a messa in scena, ricumandemu di attivà TLS in gRPC.
In u mo parè, à u cuntrariu di mTLS per i grafici, questu hè adattatu quì è hè fattu assai simplice - generà una infrastruttura PQI, crea un certificatu, lanciate Tiller, trasfiriu u certificatu durante l'inizializazione. Dopu questu, pudete eseguisce tutti i cumandamenti Helm, presentendu u certificatu generatu è a chjave privata.
Questu modu vi prutegge da tutte e dumande à Tiller da fora di u cluster.
Allora, avemu assicuratu u canali di cunnessione à Tiller, avemu digià discututu RBAC è aghjustatu i diritti di l'apiserver Kubernetes, riducendu u duminiu cù quale pò interazzione.
Helmu prutettu
Fighjemu u schema finale. Hè a stessa architettura cù e stesse frecce.
Tutte e cunnessione ponu avà esse tracciate in modu sicuru in verde:
- per Chart Repo usemu TLS o mTLS è auth basic;
- mTLS per Tiller, è hè esposta cum'è un serviziu gRPC cù TLS, usemu certificati;
- u cluster usa un contu di serviziu speciale cù Role è RoleBinding.
Avemu assicuratu significativamente u cluster, ma qualchissia intelligente hà dettu:
"Ci pò esse solu una soluzione assolutamente sicura - un computer spento, chì si trova in una scatula di cimentu è hè guardatu da i suldati".
Ci hè parechje manere di manipulà e dati è truvà novi vettori di attaccu. Tuttavia, sò cunvinta chì queste raccomandazioni utteneranu un standard di l'industria di basa per a sicurità.
Bonus
Sta parte ùn hè micca direttamente ligata à a sicurità, ma serà ancu utile. Vi mustraraghju alcune cose interessanti chì poche persone cunnoscenu. Per esempiu, cumu cercà i charts - ufficiale è micca ufficiale.
In u repository Avà ci sò circa 300 charts è dui flussi: stabile è incubatore. Qualchese chì cuntribuisce sapi perfettamente quantu hè difficiule di passà da l'incubatore à a stalla, è quantu faciule hè di vola fora di stadda. Tuttavia, questu ùn hè micca u megliu strumentu per ricercà i grafici per Prometheus è tuttu ciò chì ti piace, per una raghjone simplice - ùn hè micca un portale induve pudete cercà facilmente pacchetti.
Ma ci hè un serviziu , chì rende assai più convenientu per truvà grafici. U più impurtante, ci sò assai più repositori esterni è quasi 800 charms dispunibili. In più, pudete cunnette u vostru repository se per una certa ragione ùn vulete micca mandà i vostri charts à stabile.
Pruvate hub.helm.sh è andemu à sviluppà inseme. Stu serviziu hè sottu u prughjettu Helm, è pudete ancu cuntribuisce à a so UI sè vo site un sviluppatore front-end è solu vulete migliurà l'apparenza.
Vogliu ancu attirà a vostra attenzione Integrazione di l'API Open Service Broker. Sembra ingombrante è pocu chjaru, ma risolve i prublemi chì ognunu face. Lasciami spiegà cun un esempiu simplice.
Ci hè un cluster Kubernetes in quale vulemu eseguisce una applicazione classica - WordPress. In generale, una basa di dati hè necessaria per a funziunalità cumpleta. Ci sò parechje suluzione diffirenti, per esempiu, pudete lancià u vostru propiu serviziu statefull. Questu hè micca assai còmuda, ma assai persone facenu.
L'altri, cum'è noi in Chainstack, utilizanu basa di dati gestionati cum'è MySQL o PostgreSQL per i so servitori. Hè per quessa chì e nostre basa di dati sò situate in un locu in u nuvulu.
Ma un prublema nasce: avemu bisognu di cunnette u nostru serviziu cù una basa di dati, creà un sapori di basa di dati, trasfiriu a credencial è in qualchì manera gestione. Tuttu chistu hè generalmente fattu manualmente da l'amministratore di u sistema o sviluppatore. È ùn ci hè micca prublema quandu ci sò pochi applicazioni. Quandu ci sò assai di elli, avete bisognu di una combinazione. Ci hè un tali cugliera - hè Service Broker. Permette d'utilizà un plugin speciale per un cluster di nuvola publica è cumanda risorse da u fornitore attraversu Broker, cum'è s'ellu era una API. Per fà questu, pudete aduprà strumenti nativi di Kubernetes.
Hè assai simplice. Pudete dumandà, per esempiu, Managed MySQL in Azure cù un livellu di basa (questu pò esse cunfiguratu). Utilizendu l'API Azure, a basa di dati serà creata è preparata per l'usu. Ùn avete bisognu di interferiscenu cù questu, u plugin hè rispunsevule per questu. Per esempiu, OSBA (Azure plugin) rinviarà a credenza à u serviziu è u passa à Helm. Puderete usà WordPress cù u cloud MySQL, micca trattatu di basa di dati gestite è ùn preoccupate micca di servizii statefull in l'internu.
Pudemu dì chì Helm agisce cum'è una cola chì, da una banda, permette di implementà servizii, è da l'altra banda, cunsuma e risorse di i fornituri di nuvola.
Pudete scrive u vostru propiu plugin è aduprà sta storia sana in premisa. Allora avete solu avè u vostru propiu plugin per u fornitore Cloud corporativu. Vi cunsigliu di pruvà stu approcciu, soprattuttu s'è vo avete una grande scala è vulete implementà rapidamente dev, staging, o tutta l'infrastruttura per una funzione. Questu farà a vita più faciule per e vostre operazioni o DevOps.
Un altru scupertu chì aghju digià citatu hè plugin helm-gcs, chì permette di utilizà Google-buckets (almacenamiento d'ughjettu) per almacenà e carte Helm.
Avete bisognu solu quattru cumandamenti per cumincià à aduprà:
- stallà u plugin;
- principià lu;
- stabilisce a strada à u bucket, chì si trova in gcp;
- publicà charts in u modu standard.
A bellezza hè chì u metudu gcp nativu serà utilizatu per l'autorizazione. Pudete aduprà un contu di serviziu, un contu di sviluppatore, ciò chì vulete. Hè assai còmuda è ùn custa nunda per operare. Se tu, cum'è mè, prumove a filusufìa opsless, allora questu serà assai còmuda, soprattuttu per i picculi squadre.
Alternattivi
Helm ùn hè micca l'unica soluzione di gestione di serviziu. Ci hè parechje dumande nantu à questu, chì hè probabilmente per quessa chì a terza versione apparsu cusì rapidamente. Di sicuru, ci sò alternative.
Quessi ponu esse suluzione specializate, per esempiu, Ksonnet o Metaparticle. Pudete aduprà i vostri strumenti di gestione di l'infrastruttura classica (Ansible, Terraform, Chef, etc.) per i stessi scopi chì aghju parlatu.
Finalmente ci hè una suluzione , chì a so popularità hè in crescita.
Operator Framework hè a prima alternativa Helm à cunsiderà.
Hè più nativu di CNCF è Kubernetes, ma a barriera à l'entrata hè assai più altu, avete bisognu di prugrammà più è discrive i manifesti menu.
Ci sò parechji addons, cum'è Draft, Scaffold. Facenu a vita assai più faciule, per esempiu, simplificà u ciculu di l'inviu è u lanciu di Helm per i sviluppatori per implementà un ambiente di prova. Li chjameraghju empowerers.
Eccu un graficu visuale di induve hè tuttu.
In l'assi x hè u livellu di u vostru cuntrollu persunale nantu à ciò chì succede, in l'assi y hè u livellu di nativu di Kubernetes. Helm versione 2 cade in un locu in u mezu. In a versione 3, micca enormamente, ma u cuntrollu è u livellu di nativeness sò stati migliurati. Soluzioni à u nivellu di Ksonnet sò sempre inferiori ancu à Helm 2. In ogni casu, valenu a pena per sapè ciò chì hè in questu mondu. Di sicuru, u vostru gestore di cunfigurazione serà sottu u vostru cuntrollu, ma ùn hè assolutamente micca nativu di Kubernetes.
L'Operatore Framework hè assolutamente nativu di Kubernetes è vi permette di gestisce assai più elegantemente è scrupulosamente (ma ricordate di u livellu di entrata). Piuttostu, questu hè adattatu per una applicazione specializata è a creazione di gestione per questu, piuttostu cà una cugliera di massa per imballà un gran numaru d'applicazioni cù Helm.
L'estensori simpricimenti migliurà un pocu u cuntrollu, cumplementanu u flussu di travagliu, o tagliate i cantoni nantu à i pipelines CI/CD.
U futuru di Helm
A bona nova hè chì vene Helm 3. A versione alfa di Helm 3.0.0-alpha.2 hè digià stata liberata, pudete pruvà. Hè abbastanza stabile, ma a funziunalità hè sempre limitata.
Perchè avete bisognu di Helm 3? Prima di tuttu, questu hè una storia sparizione di Tiller, cum'è un cumpunente. Questu, cum'è avete digià capitu, hè un grande passu avanti, perchè da u puntu di vista di a sicurità di l'architettura, tuttu hè simplificatu.
Quandu Helm 2 hè statu creatu, chì era intornu à u tempu di Kubernetes 1.8 o ancu prima, assai di i cuncetti eranu immaturi. Per esempiu, u cuncettu CRD hè avà attivamente implementatu, è Helm hà da esse aduprà CRDper almacenà strutture. Serà pussibule di utilizà solu u cliente è micca mantene a parte di u servitore. Per quessa, utilizate cumandamenti nativi di Kubernetes per travaglià cù strutture è risorse. Questu hè un grande passu avanti.
Apparirà supportu per i repositori OCI nativi (Initiative Open Container). Questa hè una iniziativa enormosa, è Helm hè interessatu principalmente per pubblicà i so charts. Hè ghjuntu à u puntu chì, per esempiu, Docker Hub sustene assai standard OCI. Ùn sò micca indovinatu, ma forse i fornitori di repository Docker classici cumincianu à dà l'uppurtunità di ospitarà i vostri charts Helm.
A storia cuntruversa per mè hè Lua sustegnu, cum'è un mutore di mudelli per scrive script. Ùn sò micca un grande fan di Lua, ma questu seria una funzione completamente facultativa. Aghju verificatu questu 3 volte - l'usu di Lua ùn serà micca necessariu. Per quessa, quelli chì volenu pudè usà Lua, quelli chì piace Go, unisce à u nostru campu enormu è aduprà go-tmpl per questu.
Infine, ciò chì mi mancava definitivamente era emergenza di schema è validazione di tipu di dati. Ùn ci sarà più prublemi cù int o string, ùn ci hè bisognu di imballà zero in virgulette doppie. Un schema JSONS appariscerà chì vi permetterà di descriverà esplicitamente questu per i valori.
Sarà assai riformulatu mudellu di evenimentu guidatu. Hè digià statu cuncepitu discritta. Fighjate à u ramu Helm 3, è vi vede quanti avvenimenti è ganci è altre cose sò stati aghjunti, chì simplificà assai è, da l'altra banda, aghjunghjenu u cuntrollu di i prucessi di implementazione è reazzione à elli.
Helm 3 serà più simplice, più sicura è più divertente, micca perchè ùn ci piace Helm 2, ma perchè Kubernetes hè diventatu più avanzatu. Per quessa, Helm pò aduprà i sviluppi di Kubernetes è creà eccellenti gestori per Kubernetes nantu à questu.
Un'altra bona nutizia hè chì Alexander Khayorov vi dicerà, Ricordemu chì a cunferenza nantu à l'integrazione di i prucessi di sviluppu, di prova è di operazione si terrà in Mosca. U 30 di sittembri è u 1 d'ottobre. Pudete ancu fà finu à u 20 d'aostu è diteci a vostra sperienza cù a suluzione compiti di l'approcciu DevOps.
Segui i punti di cuntrollu di cunferenza è e nutizie à и .
Source: www.habr.com