L'essenza della storia del gestore di pacchetti più popolare per Kubernetes potrebbe essere rappresentata attraverso emoji:
- una scatola — è Helm (questo è il termine più adatto nell'ultima versione di Emoji);
- una serratura — sicurezza;
- un omino — soluzione al problema.
In realtà, tutto sarà un po' più complesso, e la narrazione è piena di dettagli tecnici su come rendere Helm sicuro.
- In breve, che cos'è Helm, se non lo sapevi o lo hai dimenticato. Quali problemi risolve e quale posizione occupa nell'ecosistema.
- Esaminiamo l'architettura di Helm. Nessuna discussione sulla sicurezza e su come rendere uno strumento o una soluzione più sicura può prescindere dalla comprensione dell'architettura del componente.
- Discutiamo dei componenti di Helm.
- La domanda più scottante — il futuro — la nuova versione di Helm 3.
Tutto ciò di cui si parla in questo articolo riguarda Helm 2. Questa versione è attualmente in produzione e, molto probabilmente, è quella che stai utilizzando ora e in essa ci sono minacce alla sicurezza.
Informazioni sul relatore: Alexandr Khayorov () lavora nello sviluppo da 10 anni, aiuta a migliorare i contenuti ed è entrato a far parte del comitato . Attualmente lavora in Chainstack come development lead — un ibrido tra un responsabile dello sviluppo e una persona che si occupa della delivery delle versioni finali. Cioè è presente sul campo, dove accade tutto, dalla creazione del prodotto alla sua operatività.
Chainstack è una piccola startup in rapida crescita, il cui obiettivo è fornire ai clienti la possibilità di dimenticare l'infrastruttura e le complessità dell'operatività delle applicazioni decentralizzate, il team di sviluppo si trova a Singapore. Non chiedere a Chainstack di vendere o comprare criptovalute, ma proponi di parlare di framework blockchain per le aziende e ti risponderanno con piacere.
Helm
È un gestore di pacchetti (chart) per Kubernetes. Il modo più chiaro e universale di portare applicazioni in un cluster Kubernetes.
Si parla, ovviamente, di un approccio più strutturato e industriale, piuttosto che della creazione dei propri manifesti YAML e scrittura di piccole utilità.
Helm è il meglio che c'è attualmente tra le soluzioni disponibili e popolari.
Perché Helm? Innanzitutto perché è supportato da CNCF. Cloud Native è una grande organizzazione, madre di progetti come Kubernetes, etcd, Fluentd e altri.
Un altro fatto importante, Helm è un progetto molto popolare. Quando a gennaio 2019 ho iniziato a pensare di raccontare come rendere Helm sicuro, il progetto aveva mille stelle su GitHub. A maggio, erano diventate 12.000.
Molti sono interessati a Helm, quindi, anche se non lo stai ancora utilizzando, le conoscenze riguardo alla sua sicurezza ti saranno utili. La sicurezza è importante.
Il team principale di Helm è supportato da Microsoft Azure, quindi è un progetto piuttosto stabile rispetto a molti altri. Il rilascio di Helm 3 Alpha 2 a metà luglio dimostra che ci sono molte persone che lavorano al progetto, e hanno voglia e capacità di sviluppare e migliorare Helm.
Helm affronta diversi problemi radice nella gestione delle applicazioni su Kubernetes.
- Imballaggio dell'applicazione. Anche un'applicazione semplice come "Hello, World" su WordPress rappresenta già diversi servizi che si desidera impacchettare insieme.
- Gestione della complessità che emerge nella gestione di queste applicazioni.
- Ciclo di vita che non termina dopo l'installazione o il rilascio dell'applicazione. Continua a vivere, deve essere aggiornata, e Helm aiuta a farlo portando le giuste misure e politiche.
Imballaggio è strutturato in modo chiaro: ci sono metadati in piena conformità con il funzionamento di un comune gestore di pacchetti per Linux, Windows o MacOS. Ovvero, repository, dipendenze da vari pacchetti, metainformazioni per le applicazioni, configurazioni, peculiarità di configurazione, indicizzazione delle informazioni, ecc. Tutto questo Helm consente di ottenere e utilizzare per le applicazioni.
Gestione della complessità. Se hai molte applicazioni simili, è necessaria la parametrizzazione. Da ciò derivano i modelli, ma per non dover inventare il tuo modo di creare modelli, puoi utilizzare ciò che Helm offre di default.
Gestione del ciclo di vita dell'applicazione – a mio parere, questa è la questione più interessante e irrisolta. È il motivo per cui sono approdato a Helm in un primo momento. Dovevamo monitorare il ciclo di vita dell'applicazione, volevamo trasferire il nostro CI/CD e i cicli delle applicazioni in questa nuova forma.
Helm consente di:
- gestire i rilasci, introduce il concetto di configurazione e revisione;
- effettuare rollback con successo;
- utilizzare hook per vari eventi;
- aggiungere controlli aggiuntivi per le applicazioni e rispondere ai loro risultati.
Inoltre Helm ha "batterie" — un'enorme quantità di cose deliziose che puoi includere sotto forma di plugin, semplificando la tua vita. I plugin possono essere scritti autonomamente, sono abbastanza isolati e non richiedono un'architettura complessa. Se vuoi realizzare qualcosa, ti consiglio di farlo sotto forma di plugin e poi, eventualmente, includerlo nell'upstream.
Helm si basa su tre concetti principali:
- Chart Repo — descrizione e array di parametri disponibili per il tuo manifesto.
- Configurazione — cioè valori che verranno applicati (testo, valori numerici, ecc.).
- Release racchiude due componenti principali, e insieme si trasformano in un Release. I Release possono essere versionati, ottenendo così una gestione del ciclo di vita: piccolo al momento dell'installazione e sostanziale al momento di un upgrade, downgrade o rollback.
Architettura di Helm
Nello schema è riflessa concettualmente l'architettura di alto livello di Helm.
Ricordo che Helm è qualcosa legato a Kubernetes. Pertanto, non possiamo fare a meno di un cluster Kubernetes (rettangolo). Il componente kube-apiserver si trova nel master. Senza Helm abbiamo Kubeconfig. Helm porta una piccola utility binaria, se così vogliamo chiamarla, l'utility Helm CLI, che può essere installata su computer, laptop, mainframe — su qualsiasi cosa.
Ma non è sufficiente. Helm ha un componente server Tiller. Esso rappresenta gli interessi di Helm all'interno del cluster, è un'applicazione all'interno del cluster Kubernetes proprio come qualsiasi altra.
Il prossimo componente Chart Repo — un repository di chart. Esiste un repository ufficiale e può esserci un repository privato dell'azienda o del progetto.
Interazione
Vediamo come interagiscono i componenti dell'architettura quando vogliamo installare un'applicazione usando Helm.
- Diciamo
Helm install, ci rivolgiamo al repository (Chart Repo) e otteniamo il chart Helm.
- L'utility Helm (Helm CLI) interagisce con Kubeconfig per capire a quale cluster rivolgersi.
- Ricevute queste informazioni, l'utility si rivolge a Tiller, che si trova nel nostro cluster, già come un'applicazione.
- Tiller si rivolge a Kube-apiserver per eseguire azioni in Kubernetes, creando alcuni oggetti (servizi, pod, repliche, segreti, ecc.).
A questo punto complicheremo lo schema per vedere i vettori di attacco a cui potrebbe essere esposta l'intera architettura di Helm. E poi cercheremo di proteggerla.
Vettore di attacco
Il primo potenziale punto debole — API privilegiato—utente. Nell'ambito dello schema, si tratta di un hacker che ha ottenuto accesso amministrativo a Helm CLI.
Utente API non privilegiato può anche rappresentare un pericolo, se si trova nelle vicinanze. Un tale utente avrà un contesto diverso; ad esempio, potrebbe essere bloccato in un namespace del cluster nelle impostazioni di Kubeconfig.
Il vettore di attacco più interessante potrebbe essere un processo che si trova all'interno del cluster nelle vicinanze di Tiller e può interagirvi. Potrebbe trattarsi di un server web o di un microservizio che vede l'ambiente di rete del cluster.
Un'opzione esotica, ma in crescita, di attacco è legata al Chart Repo. Un chart creato da un autore disonesto potrebbe contenere risorse non sicure, e lo eseguirete, fidandovi. Oppure, potrebbe sostituire il chart che state scaricando dal repository ufficiale, e ad esempio, creare delle risorse sotto forma di policy ed eseguire un'escalation dei permessi.
Cerchiamo di difenderci dagli attacchi su questi quattro fronti e di capire dove ci siano problemi nell'architettura di Helm, e dove, forse, non ce ne siano.
Ingrandiamo lo schema, aggiungiamo più elementi, ma manteniamo tutte le basi fondamentali.
Helm CLI comunica con il Chart Repo, interagisce con Kubeconfig, e il lavoro viene trasferito nel cluster al componente Tiller.
Tiller è rappresentato da due oggetti:
- Tiller-deploy svc, che espone un certo servizio;
- Tiller-deploy pod (nella schematizzazione in un'unica istanza in una replica), su cui gira tutto il carico, e che interagisce con il cluster.
Per l'interazione vengono utilizzati diversi protocolli e schemi. In termini di sicurezza, ci interessano in particolare:
- Il meccanismo tramite il quale Helm CLI si rivolge al chart repo: quale protocollo, c'è autenticazione e cosa si può fare con questo.
- Il protocollo tramite il quale Helm CLI, utilizzando kubectl, comunica con Tiller. Si tratta di un server RPC installato all'interno del cluster.
- Lo stesso Tiller è accessibile ai microservizi che si trovano nel cluster e interagisce con Kube-apiserver.
Discutiamo di tutte queste direzioni in ordine.
RBAC
È inutile parlare di alcuna sicurezza di Helm o di un altro servizio all'interno del cluster, se RBAC non è attivato.
Sembrerebbe che non sia la raccomandazione più recente, ma sono sicuro che molti non hanno ancora attivato RBAC nemmeno in produzione, perché è un grande impiccio e richiede molte configurazioni. Tuttavia, esorto a farlo.
— avvocato online per RBAC. Qui si trova un'enorme quantità di materiali interessanti che aiuteranno a configurare RBAC, mostreranno perché è utile e come viverci in produzione.
Cercherò di spiegare come funziona Tiller e RBAC. Tiller opera all'interno del cluster sotto un certo account di servizio. Di solito, se RBAC non è configurato, questo sarà un super-utente. Nella configurazione di base, Tiller sarà amministratore. Per questo motivo si dice spesso che Tiller è un tunnel SSH verso il tuo cluster. In realtà è così, quindi puoi utilizzare un account di servizio specializzato invece del Default Service Account nello schema sopra.
Quando inizializzi Helm, installandolo per la prima volta sul server, puoi specificare l'account di servizio usando --service-account. Questo permetterà di utilizzare un utente con il set minimo di diritti. Tuttavia, dovrai creare una sorta di "ghirlanda": Role e RoleBinding.
Sfortunatamente, Helm non lo farà per te. Tu o il tuo amministratore del cluster Kubernetes dovrete preparare in anticipo un insieme di Role e RoleBinding per l'account di servizio da fornire ad Helm.
Sorge la domanda: qual è la differenza tra Role e ClusterRole? La differenza è che ClusterRole si applica a tutti i namespace, a differenza delle normali Role e RoleBinding che funzionano solo per un namespace specifico. Puoi configurare le politiche sia per l'intero cluster e tutti i namespace, sia in modo personalizzato per ciascun namespace separatamente.
Vale la pena menzionare che RBAC consente di risolvere un altro grande problema. Molti lamentano che Helm, sfortunatamente, non supporta il multitenancy. Se più team consumano il cluster e utilizzano Helm, è impossibile configurare politiche e limitare il loro accesso all'interno di questo cluster, perché c'è un certo account di servizio da cui opera Helm, creando sotto di lui tutte le risorse nel cluster, il che a volte è molto scomodo. È davvero così: sia il file binario che il processo, Helm Tiller non ha nozione di multitenancy..
Tuttavia, c'è un ottimo modo che consente di eseguire Tiller nel cluster più volte. Non ci sono problemi a riguardo, Tiller può essere eseguito in ogni namespace. In questo modo puoi sfruttare RBAC, usando Kubeconfig come contesto, e limitare l'accesso a un Helm specifico.
Questo apparirà nel seguente modo.
Ad esempio, ci sono due Kubeconfig con contesti per diversi team (due namespace): X Team per il team di sviluppo e il cluster dell'amministratore. Il cluster dell'amministratore ha il suo ampio Tiller, situato nello spazio Kube-system namespace, con un avanzato service-account. E c'è un namespace separato per il team di sviluppo, che potrà implementare i propri servizi in uno spazio dedicato.
Questo è un approccio pratico, Tiller non è così esigente da poter influire significativamente sul tuo budget. È una delle soluzioni rapide.
Non esitare a configurare Tiller separatamente e fornire un Kubeconfig con contesto per il team, per un sviluppatore specifico o per l'ambiente: Dev, Staging, Production (è poco probabile che tutto sia su un unico cluster, ma è possibile farlo).
Continuando la nostra storia, passiamo da RBAC a ConfigMaps.
ConfigMaps
Helm utilizza ConfigMaps come repository di dati. Quando abbiamo parlato di architettura, non c'era un database che conservasse informazioni sui rilasci, configurazioni, rollback, ecc. A questo scopo si utilizzano ConfigMaps.
Il problema principale con le ConfigMaps è noto: non sono sicure in linea di principio, in esse non è possibile archiviare dati sensibili. Si tratta di tutto ciò che non deve oltrepassare il servizio, come le password. Il modo più nativo per Helm attualmente è passare dall'uso delle ConfigMaps ai segreti.
È molto semplice. Devi sovrascrivere la configurazione di Tiller e specificare che il repository saranno i segreti. Allora ad ogni distribuzione riceverai non una ConfigMap, ma un segreto.
Puoi obiettare che i segreti stessi sono una concezione strana e non molto sicura. Tuttavia, è importante capire che questo è gestito dagli stessi sviluppatori di Kubernetes. A partire dalla versione 1.10, cioè da un po' di tempo, è possibile, almeno nei cloud pubblici, connettersi a uno storage adeguato per l'archiviazione dei segreti. Attualmente, il team sta lavorando per migliorare ulteriormente l'accesso ai segreti per singoli pod o altre entità.
È meglio trasferire lo storage di Helm ai segreti e, a sua volta, proteggerli in modo centralizzato.
Certo, rimarrà un limite per l'archiviazione dei dati di 1 MB. Helm qui utilizza etcd come archiviazione distribuita per ConfigMaps. Lì hanno calcolato che si tratta di un chunk di dati adatto per le repliche e simili. A questo proposito c'è una discussione interessante su Reddit, consiglio di trovare questa lettura divertente per il fine settimana o di leggere un riassunto. .
Chart Repos
I chart sono particolarmente vulnerabili dal punto di vista sociale e possono diventare una fonte di attacco «Man in the middle», soprattutto se si utilizza una soluzione di default. Si tratta principalmente di repository esposti tramite HTTP.
Certamente, è necessario esporre l'Helm Repo su HTTPS: questa è l'opzione migliore e non costa molto.
Prestare attenzione a meccanismo di firma dei chart. La tecnologia è ridicolmente semplice. È la stessa che utilizzi su GitHub, una normale macchina PGP con chiavi pubbliche e private. Configura tutto e sarai certo, possedendo le chiavi necessarie e firmando tutto, che questo è davvero il tuo chart.
Inoltre, Il client Helm supporta TLS (non in senso HTTP dal lato server, ma TLS mutuo). Puoi utilizzare chiavi server e client per comunicare. Devo ammettere che non uso questo meccanismo per il mio disprezzo verso i certificati reciproci. In generale, è lo strumento principale per esporre Helm Repo per Helm 2 e supporta anche l'autenticazione di base. Puoi utilizzare l'autenticazione di base se ti è più comoda e rassicurante.
C'è anche un plugin , che consente di ospitare Chart Repos in Google Cloud Storage. È molto comodo, funziona splendidamente ed è abbastanza sicuro, perché vengono utilizzati tutti i meccanismi descritti.
Se attivi HTTPS o TLS, usi mTLS, e attivi l'autenticazione di base per ridurre ulteriormente i rischi, otterrai un canale di comunicazione sicuro tra Helm CLI e Chart Repo.
gRPC API
Il passo successivo è molto critico: mettere al sicuro Tiller, che si trova nel cluster e che è, da un lato, un server, dall'altro lato si rivolge ad altri componenti e cerca di presentarsi come qualcuno altro.
Come ho già detto, Tiller è un servizio che espone gRPC; il client Helm si connette a lui tramite gRPC. Per impostazione predefinita, naturalmente, TLS è disattivato. Perché sia stato fatto questo, è una questione discutibile; mi sembra che sia per semplificare la configurazione all'inizio.
Per la produzione e anche per lo staging, consiglio di attivare TLS su gRPC.
A mio avviso, contrariamente a mTLS per i chart, qui è appropriato e molto semplice: si genera l'infrastruttura PQI, si crea un certificato, si avvia Tiller e si passa il certificato durante l'inizializzazione. Dopo questo, è possibile eseguire tutti i comandi Helm, presentandosi con il certificato generato e la chiave privata.
In questo modo ti proteggerai da tutte le richieste a Tiller dall'esterno del cluster.
Quindi, abbiamo protetto il canale di connessione a Tiller, abbiamo già discusso di RBAC e regolato i diritti dell'apiserver di Kubernetes, ridotto il dominio con cui può interagire.
Helm protetto
Diamo un'occhiata allo schema finale. Questa è la stessa architettura con le stesse frecce.
Tutte le connessioni ora possono essere tracciate in verde:
- per Chart Repo utilizziamo TLS o mTLS e autenticazione di base;
- mTLS per Tiller, e viene esposto come servizio gRPC con TLS, utilizziamo certificati;
- nel cluster viene utilizzato un account di servizio speciale con Ruolo e RoleBinding.
Abbiamo notevolmente protetto il cluster, ma qualcuno di intelligente ha detto:
"La soluzione assolutamente sicura può essere solo una: un computer spento, rinchiuso in un box di cemento e sorvegliato da soldati."
Ci sono diversi modi per manipolare i dati e trovare nuovi vettori di attacco. Tuttavia, sono sicuro che queste raccomandazioni permetteranno di implementare un standard di sicurezza industriale di base.
Bonus
Questa parte non riguarda direttamente la sicurezza, ma sarà comunque utile. Mostrerò alcune cose interessanti di cui pochi sono a conoscenza. Per esempio, come cercare i chart: ufficiali e non ufficiali.
Nel repository Attualmente ci sono circa 300 chart e due stream: stable e incubator. Chi contribuisce sa bene quanto sia difficile passare da incubator a stable e quanto sia facile uscire da stable. Tuttavia, questo non è il miglior strumento per cercare i chart per Prometheus e per tutto ciò che ti piace, per una semplice ragione: non è un portale dove cercare i pacchetti comodamente.
Ma c'è un servizio , grazie al quale è molto più facile trovare i chart. La cosa più importante è che ci sono molti più repository esterni e sono disponibili quasi 800 chart. Inoltre, puoi collegare il tuo repository se per qualche motivo non vuoi inviare i tuoi chart a stable.
Prova hub.helm.sh e sviluppiamolo insieme. Questo servizio è sotto il progetto Helm, e puoi contribuire anche alla sua interfaccia utente, se sei un frontend e vuoi semplicemente migliorare l'aspetto.
Vorrei anche attirare la vostra attenzione su integrazione dell'API Open Service Broker. Sembra complicato e poco chiaro, ma risolve problemi con cui tutti si trovano a confronto. Spiegherò con un semplice esempio.
C'è un cluster Kubernetes in cui vogliamo eseguire un'applicazione classica — WordPress. Di solito, per il pieno funzionamento è necessario un database. Ci sono molte soluzioni diverse, per esempio, si può avviare il proprio servizio stateful. Non è molto comodo, ma molti fanno così.
Altri, come noi di Chainstack, utilizzano database gestiti, come MySQL o PostgreSQL, per i server. Quindi i nostri database si trovano da qualche parte nel cloud.
Ma sorge un problema: bisogna collegare il nostro servizio al database, creare un flavor del database, passare le credenziali e gestirle in qualche modo. Tutto questo viene normalmente fatto manualmente da un amministratore di sistema o da uno sviluppatore. E non ci sono problemi quando ci sono poche applicazioni. Quando ce ne sono molte, serve un raccoglitore. Questo raccoglitore esiste: è il Service Broker. Permette di utilizzare un plugin speciale per il cluster del cloud pubblico e richiedere risorse al fornitore tramite il Broker, come se fosse un'API. Per questo si possono utilizzare gli strumenti nativi di Kubernetes.
È molto semplice. Si può richiedere, ad esempio, Managed MySQL in Azure con tier base (questo è configurabile). Utilizzando l'API Azure, il database verrà creato e preparato per l'uso. Non sarà necessario intervenire, se ne occupa il plugin. Ad esempio, OSBA (plugin Azure) restituirà le credenziali al servizio, trasferendole a Helm. Potrete utilizzare WordPress con MySQL cloud, senza dovervi occupare di database gestiti e senza preoccuparvi dei servizi stateful interni.
Si può dire che Helm funge da collante, che da un lato consente di distribuire i servizi e dall'altro di consumare le risorse dei fornitori di cloud.
Si può scrivere il proprio plugin e utilizzare tutta questa storia on-premise. Allora avrete semplicemente il vostro plugin per il fornitore di cloud aziendale. Consiglio di provare questo approccio, soprattutto se avete una grande scala e volete distribuire rapidamente dev, staging o l'intera infrastruttura per una nuova funzionalità. Questo semplificherà la vita per le vostre operazioni o il DevOps.
Un'altra scoperta che ho già menzionato è il plugin helm-gcs, che consente di utilizzare i Google-buckets (archiviazione oggetti) per memorizzare i chart di Helm.
Servono solo quattro comandi per iniziare a utilizzarlo:
- installare il plugin;
- inizializzarlo;
- impostare il percorso per il bucket che si trova in gcp;
- pubblicare i chart in modo standard.
Il bello è che verrà utilizzato il metodo nativo di gcp per l'autenticazione. Puoi utilizzare un account di servizio, un account di sviluppatore - qualsiasi cosa. È molto conveniente e non ha costi operativi. Se, come me, sostieni la filosofia opsless, questo sarà molto utile, specialmente per piccoli team.
Alternative
Helm non è l'unica soluzione per la gestione dei servizi. Ci sono molte domande al riguardo, probabilmente è per questo che è stata rilasciata così rapidamente la terza versione. Certo, ci sono alternative.
Possono essere soluzioni specializzate, come Ksonnet o Metaparticle. Puoi utilizzare anche i tuoi strumenti classici di gestione dell'infrastruttura (Ansible, Terraform, Chef, ecc.) per gli stessi scopi di cui ho parlato.
Infine, c'è una soluzione , la cui popolarità sta crescendo.
L'Operator Framework è l'alternativa principale a Helm a cui prestare attenzione.
È più nativo per CNCF e Kubernetes, ma la barriera all'ingresso è molto più alta, richiede più programmazione e meno descrizione dei manifesti.
Ci sono vari addon, come Draft, Scaffold. Questi semplificano notevolmente la vita, ad esempio facilitano il ciclo di invio e avvio di Helm per il deployment dell'ambiente di test. Li definirei potenziatori.
Ecco un grafico esplicativo su dove si trovi ciascuna cosa.
Sull'asse delle ascisse c'è il livello di controllo personale su quanto accade, sull'asse delle ordinate - il livello di natività di Kubernetes. Helm versione 2 si colloca circa a metà strada. Nella versione 3 non ci sono enormi cambiamenti, ma sia il controllo che il livello di natività sono stati migliorati. Le soluzioni a livello Ksonnet sono comunque inferiori anche a Helm 2. Tuttavia, meritano di essere considerate per sapere cosa c'è ancora in questo mondo. Certo, il tuo gestore di configurazioni sarà sotto controllo, ma non è affatto nativo per Kubernetes.
L'Operator Framework è assolutamente nativo per Kubernetes e consente una gestione molto più elegante e meticolosa (ma ricordiamo la barriera all'ingresso). Piuttosto, si adatta a un'applicazione specializzata e alla creazione della sua gestione, piuttosto che a un grande raccoglitore che imballa un gran numero di applicazioni tramite Helm.
I potenziatori semplicemente migliorano leggermente il controllo, completano il workflow o semplificano le fasi dei pipeline CI/CD.
Il futuro di Helm
La buona notizia è che sta arrivando Helm 3. È stata rilasciata la versione alpha 3.0.0-alpha.2 di Helm, che puoi provare. È abbastanza stabile, ma la funzionalità è ancora limitata.
A cosa serve Helm 3? In primo luogo, si tratta di scomparsa di Tiller, come componente. Come già potete capire, è un enorme passo avanti, perché dal punto di vista della sicurezza dell'architettura tutto diventa più semplice.
Quando è stato creato Helm 2, eravamo ai tempi di Kubernetes 1.8 o anche prima, molte delle concezioni erano immature. Ad esempio, la concezione dei CRD è attualmente in fase di attuazione, e Helm utilizzerà i CRD, per memorizzare le strutture. Sarà possibile utilizzare solo il client senza dover mantenere un server. Di conseguenza, si potranno utilizzare i comandi nativi di Kubernetes per lavorare con le strutture e le risorse. Questo è un enorme passo avanti.
Ci sarà supporto per i repository OCI nativi (Open Container Initiative). È un'iniziativa enorme, e a Helm interessa principalmente per ospitare i propri chart. Si arriva al punto che, ad esempio, Docker Hub supporta molti standard OCI. Non lo dico con certezza, ma potrebbe darsi che i tradizionali fornitori di repository Docker inizino a consentire di ospitare i propri chart Helm.
Una questione controversa per me è il supporto di Lua, come motore di templating per la scrittura di script. Non sono un grande fan di Lua, ma sarà un'opzione completamente facoltativa. L'ho verificato tre volte: l'uso di Lua non sarà obbligatorio. Quindi, chi lo desidera potrà usare Lua, mentre chi preferisce Go — unisciti al nostro grande gruppo e utilizza go-tmpl per questo.
Finalmente qualcosa che mi mancava davvero è l'introduzione degli schemi e la validazione dei tipi di dati. Non ci saranno più problemi con int o string, non sarà più necessario racchiudere zero tra virgolette. Ci sarà uno schema JSONS che permetterà di descriverlo esplicitamente per i valori.
L'intero modello basato su eventisarà completamente rielaborato. È già descritto concettualmente. Dai un'occhiata al ramo di Helm 3 e vedrai quanti eventi, hook e altre cose sono stati aggiunti, il che semplificherà molto e, dall'altro lato, offrirà un maggiore controllo sui processi di deploy e le reazioni a essi.
Helm 3 sarà più semplice, più sicuro e più interessante non perché non ci piaccia Helm 2, ma perché Kubernetes sta diventando più avanzato. Pertanto, Helm può utilizzare i progressi di Kubernetes e creare ottimi gestori per Kubernetes.
Un'altra buona notizia è che su Alexander Khayerov parlerà di Ricordiamo che la conferenza sull'integrazione dei processi di sviluppo, testing e operazioni si svolgerà a Mosca il 30 settembre e 1 ottobre. Fino al 20 agosto è ancora possibile e condividere la propria esperienza nella risoluzione di problemi dell'approccio DevOps.
Segui i checkpoint della conferenza e le notizie sul e .
Fonte: habr.com
