Nota. transl.: U 16 di maghju di questu annu marca un passu impurtante in u sviluppu di u gestore di pacchetti per Kubernetes - Helm. In questu ghjornu, a prima versione alfa di a futura versione maiò di u prughjettu - 3.0 - hè stata presentata. A so liberazione portarà cambiamenti significativi è longu aspittati à Helm, per quale parechji in a cumunità Kubernetes anu grandi speranze. Noi stessi simu unu di questi, postu chì usemu attivamente Helm per l'implementazione di l'applicazioni: l'avemu integratu in u nostru strumentu per implementà CI/CD. è di tantu in tantu facemu a nostra cuntribuzione à u sviluppu di upstream. Questa traduzzione combina note 7 da u blog ufficiale Helm, chì sò dedicati à a prima liberazione alfa di Helm 3 è parlanu di a storia di u prugettu è e caratteristiche principali di Helm 3. U so autore hè Matt "bacongobbler" Fisher, un impiigatu Microsoft. è unu di i principali mantenitori di Helm.
U 15 d'ottobre di u 2015 hè natu u prughjettu chjamatu Helm. Solu un annu dopu a so fundazione, a cumunità Helm s'unì à Kubernetes, mentre travagliava attivamente in Helm 2. In u ghjugnu 2018, Helm cum'è un prughjettu di sviluppu (incubazione). Avanzate rapidamente à u presente, è a prima versione alfa di u novu Helm 3 hè in strada. (questa liberazione à a mità di maghju - circa. trad.).
In questu pezzu, parleraghju di induve tuttu hà cuminciatu, cumu avemu ghjuntu à induve simu oghje, intruduce alcune di e caratteristiche uniche dispunibili in a prima versione alfa di Helm 3, è spieghemu cumu avemu pensatu à avanzà.
Riassuntu:
- a storia di a creazione di Helm;
- un teneru addiu à Tiller;
- repositori di carta;
- gestione di liberazione;
- cambiamenti in a dependenza di u graficu;
- carte di biblioteca;
- chì hè dopu?
A storia di Helm
Nascita
Helm 1 hà iniziatu cum'è un prughjettu Open Source creatu da Deis. Eramu una piccula startup Microsoft in a primavera di u 2017. U nostru altru prughjettu Open Source, ancu chjamatu Deis, avia un strumentu deisctl, chì hè stata utilizata (frà altre cose) per installà è operate a piattaforma Deis in . À quellu tempu, Fleet era una di e prime piattaforme d'orchestrazione di container.
À a mità di 2015, avemu decisu di cambià u cursu è trasfirìu Deis (à quellu tempu rinominatu Deis Workflow) da Fleet à Kubernetes. Unu di i primi à esse riprogettatu era u strumentu di stallazione. deisctl. L'avemu utilizatu per installà è gestisce Deis Workflow in u cluster Fleet.
Helm 1 hè statu creatu in l'imaghjini di famosi gestori di pacchetti cum'è Homebrew, apt è yum. U so scopu principale era di simplificà i travaglii cum'è l'imballaggio è l'installazione di applicazioni in Kubernetes. Helm hè statu presentatu ufficialmente in 2015 à a cunferenza KubeCon in San Francisco.
U nostru primu tentativu cù Helm hà travagliatu, ma ùn era micca senza limitazioni serii. Pigliò un inseme di manifesti Kubernetes, aromatizzati cù generatori cum'è blocchi YAML introduttori. (materia prima)*, è hà caricatu i risultati in Kubernetes.
* Nota. transl.: Da a prima versione di Helm, a sintassi YAML hè stata scelta per descriverà e risorse di Kubernetes, è i mudelli Jinja è i script Python sò stati supportati per scrive cunfigurazioni. Avemu scrittu più nantu à questu è a struttura di a prima versione di Helm in generale in u capitulu "A Breve Storia di Helm" .
Per esempiu, per rimpiazzà un campu in un schedariu YAML, avete da aghjunghje a custruzzione seguente à u manifestu:
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlHè fantasticu chì i mutori di mudelli esistenu oghje, ùn hè micca?
Per parechje ragioni, stu primu installatore Kubernetes necessitava una lista codificata di fugliali manifesti è eseguiu solu una piccula sequenza fissa di avvenimenti. Era cusì difficiuli d'utilizà chì a squadra di R&D di Deis Workflow hà avutu un tempu duru quandu anu pruvatu à trasfirià u so pruduttu à sta piattaforma - in ogni modu, i graneddi di l'idea era digià seminatu. U nostru primu tentativu era una grande opportunità di apprendimentu: avemu capitu chì eramu veramente appassiunati di creà strumenti pragmatici chì risolvenu i prublemi di ogni ghjornu per i nostri utilizatori.
Basatu annantu à l'esperienza di i sbagli passati, avemu cuminciatu à sviluppà Helm 2.
Creazione di Helm 2
À a fine di u 2015, a squadra di Google ci hà cuntattatu. Stavanu travagliendu in un strumentu simili per Kubernetes. Deployment Manager per Kubernetes era un portu di una strumenta esistente chì hè stata utilizata per Google Cloud Platform. "Avemu vulutu", anu dumandatu, "passà uni pochi di ghjorni discutendu e similitudini è e differenze?"
In ghjennaghju 2016, i squadre di Helm and Deployment Manager si sò riuniti in Seattle per scambià idee. I negoziati finiscinu cù un pianu ambiziosu: cunghjuntà i dui prughjetti per creà Helm 2. Inseme cù Deis è Google, i ragazzi di (avà parte di Bitnami - circa trad.), è avemu cuminciatu à travaglià nantu à Helm 2.
Vulemu mantene a facilità d'utilizazione di Helm, ma aghjunghje i seguenti:
- mudelli di carta per persunalizazione;
- gestione intra-cluster per squadre;
- repository di carta di classe mundiale;
- formatu di pacchettu stabile cù l'opzione di firma;
- un forte impegnu à a versione semantica è mantene a cumpatibilità retroattiva trà e versioni.
Per ottene questi scopi, un secondu elementu hè statu aghjuntu à l'ecosistema Helm. Stu cumpunente intra-cluster era chjamatu Tiller è era rispunsevuli di installà e carte Helm è di gestisce.
Dapoi a liberazione di Helm 2 in 2016, Kubernetes hà aghjustatu parechje innovazioni maiò. Aggiuntu un cuntrollu di accessu basatu nantu à u rolu (), chì eventualmente rimpiazzatu u Controlu di Accessu Basatu in Attributi (ABAC). I novi tippi di risorse sò stati introdotti (Implementazioni era sempre in beta à u mumentu). Definizioni di Risorse Personalizzate (urigginariamente chjamate Risorse di Terzi o TPR) sò state inventate. È più importantemente, un inseme di e migliori pratiche hè apparsu.
À mezu à tutti questi cambiamenti, Helm hà cuntinuatu à serve l'utilizatori di Kubernetes fedelmente. Dopu trè anni è parechji aggiunte novi, era chjaru chì era ora di fà cambiamenti significativi à a basa di codice per assicurà Helm puderia cuntinuà à risponde à i bisogni crescente di un ecosistema in evoluzione.
Un teneru addiu à Tiller
Durante u sviluppu di Helm 2, avemu introduttu Tiller cum'è parte di a nostra integrazione cù u Deployment Manager di Google. Tiller hà ghjucatu un rolu impurtante per e squadre chì travaglianu in un cluster cumunu: hà permessu à diversi specialisti chì operanu l'infrastruttura per interagisce cù u stessu set di versioni.
Siccomu u cuntrollu di l'accessu basatu in u rolu (RBAC) hè statu attivatu per difettu in Kubernetes 1.6, travaglià cù Tiller in a produzzione hè diventatu più difficiule. A causa di u gran numaru di pussibuli pulitiche di sicurità, a nostra pusizioni hè stata di offre una cunfigurazione permissiva per automaticamente. Questu hà permessu à i principianti di sperimentà Helm è Kubernetes senza avè da immerse in i paràmetri di sicurezza prima. Sfurtunatamente, sta cunfigurazione di permessu puderia dotà l'utilizatore cù una gamma troppu larga di permessi chì ùn anu micca bisognu. L'ingegneri DevOps è SRE anu da amparà passi operativi supplementari quandu installanu Tiller in un cluster multi-tenant.
Dopu avè amparatu cumu a cumunità hà utilizatu Helm in situazioni specifiche, avemu capitu chì u sistema di gestione di liberazione di Tiller ùn hà micca bisognu di s'appoghjanu à un cumpunente intra-cluster per mantene u statu o funziunà cum'è un centru centrale per l'infurmazioni di liberazione. Invece, pudemu simpricimenti riceve infurmazioni da u servitore API Kubernetes, generà un graficu in u latu di u cliente, è almacenà un registru di a stallazione in Kubernetes.
U scopu principale di Tiller puderia esse rializatu senza Tiller, cusì una di e nostre prime decisioni riguardanti Helm 3 era di abbandunà completamente Tiller.
Cù Tiller andatu, u mudellu di sicurità di Helm hè statu simplificatu radicalmente. Helm 3 supporta avà tutti i metudi muderni di sicurità, identità è autorizazione di l'attuale Kubernetes. I permessi Helm sò determinati usendu . L'amministratori di cluster ponu restringe i diritti di l'utilizatori à qualsiasi livellu di granularità. E versioni sò sempre salvate in u cluster, è u restu di e funziunalità di Helm resta intactu.
Repositori di carta
À un altu livellu, un repository di carta hè un locu induve i charts ponu esse guardati è spartuti. U cliente Helm imballa è manda i charts à u repository. Simply put, a charts repository is a primitive HTTP server with an index.yaml file and some packaged charts.
Mentre chì ci sò parechji vantaghji per l'API Charts Repository chì risponde à i requisiti di almacenamentu più basi, ci sò ancu uni pochi svantaghji:
- I repositori di chart ùn sò micca cumpatibili cù a maiò parte di l'implementazioni di sicurezza richieste in un ambiente di produzzione. Avè una API standard per l'autentificazione è l'autorizazione hè estremamente impurtante in i scenarii di produzzione.
- L'arnesi di provenienza di u graficu di Helm, utilizati per firmà, verificate l'integrità è a provenienza di un graficu, sò una parte facultativa di u prucessu di publicazione di Chart.
- In scenarii multi-utilizatori, a stessa carta pò esse caricata da un altru utilizatore, radduppiendu a quantità di spaziu necessariu per almacenà u listessu cuntenutu. Repositori più intelligenti sò stati sviluppati per risolve stu prublema, ma ùn sò micca parti di l'specificazione formale.
- Utilizà un unicu file d'indici per a ricerca, l'almacenamiento di metadati è a ricuperazione di i grafici hà fattu difficiule di sviluppà implementazioni sicure multi-utilizatori.
U prugettu (cunnisciutu ancu cum'è Docker Registry v2) hè u successore di Docker Registry è essenzialmente agisce cum'è un inseme di strumenti per imballaggi, spedizioni, almacenà è furnisce l'imaghjini Docker. Parechje grandi servizii nuvola offre prudutti basatu a Distribuzione. Grazie à sta attenzione aumentata, u prughjettu di Distribuzione hà benefiziu di anni di migliuramentu, di e pratiche di sicurezza, è e teste di campu chì anu fattu unu di l'eroi più riesciuti di u mondu Open Source.
Ma sapete chì u Prughjettu di Distribuzione hè statu cuncepitu per distribuisce ogni forma di cuntenutu, micca solu l'imaghjini di u containeru?
Grazie à i sforzi (o OCI), i grafici Helm ponu esse piazzati in ogni istanza di Distribuzione. Per avà, stu prucessu hè sperimentale. U supportu di login è altre funzioni necessarie per un Helm 3 cumpletu sò un travagliu in prugressu, ma simu entusiasmati d'amparà da e scuperte chì i squadre OCI è Distribuzione anu fattu annantu à l'anni. È attraversu u so tutore è a guida, imparemu ciò chì hè cum'è per uperà un serviziu altamente dispunibule à scala.
Una descrizione più dettagliata di alcuni cambiamenti imminenti à i repositori di chart Helm hè dispunibule .
Gestione di liberazione
In Helm 3, u statu di l'applicazione hè tracciatu in u cluster da un paru di oggetti:
- ughjettu di liberazione - rapprisenta una istanza di l'applicazione;
- versione secreta di liberazione - rapprisenta u statu desideratu di l'applicazione in un puntu specificu in u tempu (per esempiu, a liberazione di una nova versione).
Challenge helm install crea un oggettu di liberazione è u secretu di versione di liberazione. Chjama helm upgrade richiede un oggettu di liberazione (chì pò cambià) è crea una nova versione di versione secreta chì cuntene i novi valori è un manifestu preparatu.
L'ughjettu di liberazione cuntene infurmazione nantu à a liberazione, induve a liberazione hè una stallazione specifica di un graficu chjamatu è valori. Questu ughjettu descrive i metadati di primu livellu nantu à a liberazione. L'ughjettu di liberazione persiste in tuttu u ciclu di vita di l'applicazione è hè u pruprietariu di tutti i secreti di a versione di liberazione, è ancu di tutti l'uggetti chì sò direttamente creati da u graficu Helm.
U secretu di a versione di liberazione associa una versione cù una seria di rivisioni (installazione, aghjurnamenti, rollbacks, eliminazione).
In Helm 2, e revisioni eranu estremamente coherenti. Chjama helm install creatu v1, l'aghjurnamentu dopu (upgrade) - v2, è cusì. U sicretu di a versione di liberazione è di liberazione sò stati colapsati in un oggettu unicu chjamatu rivisione. I rivisioni sò stati guardati in u stessu spaziu di nomi cum'è Tiller, chì significava chì ogni liberazione era "globale" in quantu à u spaziu di nomi; in u risultatu, solu una istanza di u nome puderia esse usata.
In Helm 3, ogni versione hè assuciata cù unu o più secreti di versione di versione. L'ughjettu di liberazione descrive sempre a versione attuale implementata in Kubernetes. Ogni sicretu di versione di liberazione descrive solu una versione di quella versione. Un aghjurnamentu, per esempiu, creà una nova versione di versione secreta è poi cambià l'ughjettu di liberazione per indicà quella nova versione. In u casu di un rollback, pudete aduprà i secreti di a versione precedente per rinvià a liberazione à un statu precedente.
Dopu chì Tiller hè abbandunatu, Helm 3 guarda i dati di liberazione in u stessu spaziu di nomi cum'è a liberazione. Stu cambiamentu permette di installà un graficu cù u listessu nome di liberazione in un spaziu di nome differente, è i dati sò salvati trà l'aghjurnamenti di cluster / reboots in etcd. Per esempiu, pudete installà WordPress in u spaziu di nome "foo" è dopu in u spaziu di nome "bar", è e duie versioni ponu esse chjamatu "wordpress".
Cambiamenti à e dipendenze di u graficu
Grafici imballati (usando helm package) per l'usu cù Helm 2 pò esse installatu cù Helm 3, in ogni modu, u flussu di travagliu di u sviluppu di carta hè stata rivisionata cumplettamente, perchè alcuni cambiamenti devenu esse fatte per cuntinuà u sviluppu di u graficu cù Helm 3. In particulare, u sistema di gestione di a dependenza di u graficu hà cambiatu.
U sistema di gestione di a dependenza di u graficu hè cambiatu requirements.yaml и requirements.lock nantu Chart.yaml и Chart.lock. Questu significa chì i charts chì anu utilizatu u cumandamentu helm dependency, richiede una certa configurazione per travaglià in Helm 3.
Fighjemu un esempiu. Aghjunghjemu una dependenza à u graficu in Helm 2 è vede ciò chì cambia quandu si move à Helm 3.
In Helm 2 requirements.yaml pareva cusì:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
In Helm 3, a stessa dipendenza serà riflessa in u vostru Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
I grafici sò sempre scaricati è posti in u cartulare charts/, cusì sottucarti (sottografici), stendu in u catalogu charts/, continuerà à travaglià senza cambiamenti.
Presentazione di i Charts Biblioteche
Helm 3 supporta una classa di carte chjamate carte di biblioteca (carte di biblioteca). Questa carta hè aduprata da altre carte, ma ùn crea micca artefatti di liberazione per sè stessu. I mudelli di carta di biblioteca ponu dichjarà solu elementi define. L'altru cuntenutu hè solu ignoratu. Questu permette à l'utilizatori di riutilizà è sparte snippets di codice chì ponu esse aduprati in parechje carte, evitendu cusì a duplicazione è aderiscenu à u principiu. .
I grafici di a biblioteca sò dichjarati in a sezione dependencies in u schedariu Chart.yaml. L'installazione è a gestione di elli ùn hè micca sfarente di l'altri charts.
dependencies:
- name: mylib
version: 1.x.x
repository: quay.ioSemu entusiasti di i casi d'usu chì stu cumpunente aprirà per i sviluppatori di carte, è ancu di e migliori pratiche chì ponu emerge da i grafici di a biblioteca.
Chi c'è vicinu?
Helm 3.0.0-alpha.1 hè u fundamentu nantu à quale avemu principiatu à custruisce una nova versione di Helm. In l'articulu aghju descrittu alcune caratteristiche interessanti di Helm 3. Parechji di elli sò sempre in i primi stadi di u sviluppu è questu hè normale; U puntu di una liberazione alfa hè di pruvà l'idea, raccoglie feedback da i primi utilizatori, è cunfirmà e nostre supposizioni.
Appena a versione alfa hè liberata (ricurdate chì questu hè - ca. trad.), Cuminceremu à accettà patches per Helm 3 da a cumunità. Avete bisognu di creà un fundamentu forte chì permette di sviluppà è aduttà una nova funziunalità, è chì l'utilizatori si sentenu implicati in u prucessu aprendu i biglietti è facenu correzioni.
Aghju pruvatu à mette in risaltu alcune di e migliure maiò chì venenu à Helm 3, ma sta lista ùn hè micca exhaustiva. A strada completa per Helm 3 include caratteristiche cum'è strategie di aghjurnamentu mejorate, integrazione più profonda cù i registri OCI, è l'usu di schemi JSON per cunvalidà i valori di carta. Avemu ancu pensatu di pulisce a basa di codice è aghjurnà e parte di questu chì sò stati trascurati per l'ultimi trè anni.
Se senti chì avemu mancatu qualcosa, ci piacerebbe sente i vostri pinsamenti !
Unisci à a discussione nantu à u nostru :
-
#helm-usersper dumande è cumunicazione simplice cù a cumunità; -
#helm-devper discutiri pull requests, codice è bugs.
Pudete ancu chatte in i nostri Calli di Sviluppatore Pubblicu settimanale u ghjovi à 19:30 MSK. E riunioni sò dedicate à discussione di prublemi chì i sviluppatori chjave è a cumunità travaglianu, è ancu i temi di discussione per a settimana. Qualchissia pò unisce è participà à a riunione. Link dispunibule in u canale Slack #helm-dev.
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «";
- «».
Source: www.habr.com