La questione centrale del racconto sul gestore di pacchetti più popolare per Kubernetes potrebbe essere riassunta con delle emoji:
- una scatola — è Helm (è la rappresentazione più adatta nella recente versione Emoji);
- un lucchetto — sicurezza;
- una figura umana — soluzione dei problemi.
In realtà, la situazione sarà un po' più complessa e la narrazione è piena di dettagli tecnici su come rendere Helm sicuro..
- In breve, che cos'è Helm, se non lo sapevate o l'avete dimenticato. Quali problemi risolve e dove si colloca 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 i componenti di Helm.
- La questione più scottante — il futuro — la nuova versione di Helm 3.
Tutto ciò che è trattato in questo articolo riguarda Helm 2. Questa versione è attualmente in produzione e probabilmente è quella che state utilizzando, ed è qui che risiedono le minacce alla sicurezza.
Sul relatore: Alexander Khayorov () lavora nello sviluppo da 10 anni, aiuta a migliorare il contenuto e si è unito al comitato . Attualmente lavora in Chainstack come development lead — una posizione ibrida tra responsabile dello sviluppo e persona incaricata della delivery delle versioni finali. Si trova, quindi, nel bel mezzo dell'azione, dove si passa dalla creazione del prodotto alla sua operatività.
Chainstack è una piccola startup in crescita, il cui obiettivo è offrire ai clienti la possibilità di dimenticare l'infrastruttura e le complessità della gestione di applicazioni decentralizzate, con un team di sviluppo situato a Singapore. Non chiedere a Chainstack di vendere o comprare criptovalute, ma proponi di parlare di framework blockchain per le imprese e riceverai con piacere una risposta.
Helm
Questo è un gestore di pacchetti (chart) per Kubernetes. Il modo più chiaro e universale per portare applicazioni in un cluster Kubernetes.
Si parla, ovviamente, di un approccio più strutturato e industriale, piuttosto che della creazione dei propri manifest YAML e della scrittura di piccole utility.
Helm è il migliore attualmente disponibile e popolare.
Perché Helm? Prima di tutto perché è supportato da CNCF. Cloud Native è una grande organizzazione che è la società madre dei progetti Kubernetes, etcd, Fluentd e altri.
Un altro fatto importante è che Helm è un progetto molto popolare. Quando a gennaio 2019 ho iniziato a pensare di parlare di come rendere Helm sicuro, il progetto aveva mille stelle su GitHub. A maggio, sono diventate 12 mila.
Molti sono interessati a Helm, quindi, anche se ancora non lo usate, le conoscenze sulla sua sicurezza saranno utili. La sicurezza è importante.
Il team principale di Helm è supportato da Microsoft Azure, e quindi è un progetto abbastanza stabile rispetto a molti altri. L'uscita di Helm 3 Alpha 2 a metà luglio dimostra che ci sono molte persone che lavorano al progetto, e che hanno la volontà e le forze per sviluppare e migliorare Helm.
Helm affronta diverse problematiche fondamentali nella gestione delle applicazioni in Kubernetes.
- Imballaggio di un'applicazione. Anche un'app come 'Hello, World' su WordPress rappresenta già diversi servizi, e si desidera imballarli insieme.
- Gestire la complessità che sorge nella gestione di queste applicazioni.
- Un ciclo di vita che non termina dopo l'installazione o il deployment dell'applicazione. Essa continua a vivere, deve essere aggiornata, e in questo Helm offre il giusto supporto con misure e politiche adeguate.
Imballaggio è strutturato in modo chiaro: ci sono metadati che si conformano perfettamente al funzionamento di un normale gestore di pacchetti per Linux, Windows o MacOS. In altre parole, gestisce repository, dipendenze da vari pacchetti, metainformazioni per le applicazioni, configurazioni, peculiarità di configurazione, indicizzazione delle informazioni, ecc. Tutto ciò Helm permette di ottenere e utilizzare per le applicazioni.
Gestione della complessità. Se hai molte applicazioni simili, è necessaria la parametrizzazione. Da questo derivano i modelli, ma per non dover inventare un proprio metodo di creazione di modelli, puoi utilizzare ciò che Helm offre di default.
Gestione del ciclo di vita dell'applicazione — a mio avviso, questa è la questione più interessante e irrisolta. È il motivo per cui in passato sono approdato a Helm. Dovevamo tenere d'occhio il ciclo di vita dell'applicazione e volevamo trasferire il nostro CI/CD e i cicli delle applicazioni in questa nuova paradigmaticità.
Helm consente:
- gestire i deployment, introducendo il concetto di configurazione e revisione;
- eseguire rollback con successo;
- utilizzare hook per eventi diversi;
- aggiungere controlli aggiuntivi alle applicazioni e reagire ai loro risultati.
Inoltre, Helm ha "batterie" — una vasta gamma di funzionalità deliziose che possono essere integrate come plugin, semplificando la propria vita. I plugin possono essere scritti autonomamente, sono abbastanza isolati e non richiedono un'architettura complessa. Se vuoi realizzare qualcosa, ti consiglio di farlo come un plugin e poi, eventualmente, integrarlo nell'upstream.
Helm si basa su tre concetti fondamentali:
- Chart Repo — una descrizione e un insieme di parametri possibili per il tuo manifesto.
- Configurazione cioè i valori che saranno applicati (testo, valori numerici, ecc.).
- Release riunisce i due componenti superiori, che insieme diventano un Release. Le release possono essere versionate, consentendo di gestire il ciclo di vita: piccolo al momento dell'installazione e grande al momento di upgrade, downgrade o rollback.
Architettura di Helm
Il diagramma riflette concettualmente l'architettura ad alto livello di Helm.
Ricordo che Helm è qualcosa che riguarda Kubernetes. Pertanto, abbiamo bisogno di un cluster Kubernetes (rettangolo). Il componente kube-apiserver si trova sul master. Senza Helm abbiamo Kubeconfig. Helm porta un piccolo binario, se così si può chiamare, l'utility Helm CLI, che si installa su computer, laptop, mainframe – su qualsiasi cosa.
Ma questo non basta. Helm ha un componente server chiamato Tiller. Rappresenta gli interessi di Helm all'interno del cluster, è un'applicazione all'interno del cluster Kubernetes come qualsiasi altra.
Il prossimo componente è il Chart Repo – un repository di chart. C'è un repository ufficiale e può esserci un repository privato dell'azienda o del progetto.
Interazione
Consideriamo come interagiscono i componenti dell'architettura quando vogliamo installare un'applicazione utilizzando Helm.
- Diciamo
Helm install, ci rivolgiamo al repository (Chart Repo) e otteniamo il chart di Helm.
- L'utility Helm (Helm CLI) interagisce con Kubeconfig per determinare a quale cluster rivolgersi.
- Ricevute queste informazioni, l'utility si rivolge a Tiller, che si trova nel nostro cluster, già come un'applicazione.
- Tiller interagisce con il Kube-apiserver per eseguire azioni in Kubernetes e creare oggetti come servizi, pod, repliche, segreti, ecc.
Successivamente compliceremo lo schema per identificare i vettori di attacco che possono compromettere l'intera architettura di Helm e poi cercheremo di difenderla.
Vettore di attacco
Il primo potenziale punto debole è API privilegiata—utente. All'interno dello schema, questo è un hacker che ha ottenuto accesso amministrativo al Helm CLI.
Un utente API non privilegiato può anche rappresentare un pericolo se si trova nelle vicinanze. Questo utente avrà un contesto diverso, ad esempio, potrebbe essere fissato in un namespace del cluster nelle impostazioni di Kubeconfig.
Un interessante vettore d'attacco potrebbe essere rappresentato da un processo situato all'interno del cluster, nelle vicinanze di Tiller, e in grado di interagire con esso. Questo potrebbe essere un server web o un microservizio che percepisce l'ambiente di rete del cluster.
Un'alternativa esotica ma in crescita, l'attacco è legato al Chart Repo. Un chart creato da un autore malintenzionato può contenere risorse non sicure e tu lo eseguirai, accettandolo per buono. Oppure può sostituire il chart che scarichi dal repository ufficiale, creando ad esempio risorse in forma di politiche ed escalare i propri privilegi.
Cerchiamo di difenderci dagli attacchi provenienti da tutte e quattro le direzioni e di comprendere dove ci siano problematiche nell'architettura di Helm e dove, eventualmente, non ci siano.
Amplifichiamo lo schema, aggiungendo più elementi, ma mantenendo tutte le componenti di base.
L'interfaccia a riga di comando di Helm comunica con il Chart Repo, interagisce con Kubeconfig e il lavoro viene trasferito nel cluster al componente Tiller.
Tiller è rappresentato da due oggetti:
- Servizio Tiller-deploy, che espone un certo servizio;
- Pod Tiller-deploy (nello schema in un'unica copia in una replica), sul quale lavora tutto il carico, che si rivolge al cluster.
Per l'interazione vengono utilizzati diversi protocolli e schemi. Dal punto di vista della sicurezza, ci interessano maggiormente:
- Il meccanismo tramite il quale l'interfaccia a riga di comando di Helm si rivolge al chart repo: quale protocollo, se c'è autenticazione e cosa si può fare a riguardo.
- Il protocollo tramite il quale Helm CLI, utilizzando kubectl, comunica con Tiller. Si tratta di un server RPC installato all'interno del cluster.
- Tiller è accessibile ai microservizi che si trovano nel cluster e interagisce con Kube-apiserver.
Affronteremo tutti questi argomenti in ordine.
RBAC
È inutile parlare di qualsiasi sicurezza di Helm o di un altro servizio all'interno del cluster se RBAC non è abilitato.
Sembra che non sia la raccomandazione più recente, ma sono sicuro che ancora molti non hanno abilitato RBAC nemmeno in produzione, poiché è un bel po' di lavoro e richiede molte configurazioni. Tuttavia, invito a farlo.
— sito di riferimento per RBAC. Qui è raccolto un enorme numero di materiali interessanti che aiuteranno a configurare RBAC, mostreranno perché è vantaggioso e come viverci in produzione.
Cercherò di spiegare come funziona Tiller e RBAC. Tiller opera all'interno del cluster con un determinato account di servizio. Di solito, se RBAC non è configurato, sarà un superutente. Nella configurazione di base, Tiller avrà privilegi di amministratore. È per questo che spesso si dice che Tiller è un tunnel SSH per il tuo cluster. In effetti, è 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 utilizzando --service-account. Questo permetterà di utilizzare un utente con il set di diritti minimi necessari. Tuttavia, dovrai creare una "ghirlanda" di Role e RoleBinding.
Sfortunatamente, Helm non lo farà per te. Tu o il tuo amministratore del cluster Kubernetes dovrete prepararvi in anticipo un insieme di Role e RoleBinding per l'account di servizio da passare a Helm.
Sorge la domanda: qual è la differenza tra Role e ClusterRole? La differenza è che ClusterRole agisce per tutti i namespace, diversamente da Role e RoleBinding, che funzionano solo per un singolo namespace specifico. Puoi impostare le politiche sia per l'intero cluster e tutti i namespace, sia in modo personalizzato per ciascun namespace singolarmente.
Vale la pena notare che RBAC affronta un altro grande problema. Molti si lamentano del fatto che Helm, purtroppo, non supporta il multitenancy. Se più team utilizzano il cluster e Helm, non è possibile impostare politiche e delimitare i loro accessi all'interno di questo cluster, poiché esiste un certo account di servizio sotto il quale opera Helm e che crea tutte le risorse nel cluster, il che è spesso molto scomodo. È realmente così — sia per il file binario stesso che per il processo. Helm Tiller non ha conoscenza del multitenancy.
Tuttavia, c'è un ottimo modo per eseguire Tiller nel cluster più volte. Non ci sono problemi: Tiller può essere avviato in ogni namespace. In questo modo, puoi sfruttare RBAC, Kubeconfig come contesto e limitare l'accesso a Helm specifico.
Ecco come apparirà.
Ad esempio, ci sono due Kubeconfig con contesto per team diversi (due namespace): il team X per il team di sviluppo e il cluster admin. Il cluster admin ha un Tiller ampio, che si trova nel namespace Kube-system, con un service-account avanzato. Esiste anche un namespace separato per il team di sviluppo, che potrà distribuire i propri servizi in questo namespace specifico.
Questo è un approccio funzionante; Tiller non è così esigente da influenzare molto il tuo budget. È una delle soluzioni rapide.
Sentiti libero di configurare Tiller separatamente e fornire Kubeconfig con il contesto per il team, per sviluppatori specifici o per l'ambiente: Dev, Staging, Production (è improbabile che tutto sia nello stesso cluster, ma è possibile farlo).
Continuando la nostra storia, ci allontaniamo da RBAC e parliamo di ConfigMaps.
ConfigMaps
Helm utilizza ConfigMaps come archivio dati. Quando abbiamo parlato dell'architettura, non c'era alcun database in cui venissero memorizzate le informazioni riguardanti rilasci, configurazioni, rollback, ecc. A questo scopo vengono utilizzati i ConfigMaps.
Il principale problema con i ConfigMaps è noto: non sono sicuri per definizione, al loro interno non è possibile memorizzare dati sensibili. Si tratta di tutto ciò che non dovrebbe superare il servizio, come le password. Ora il modo più nativo per Helm è passare dall'utilizzo dei ConfigMaps ai segreti.
Questo è molto semplice. Devi ridefinire la configurazione di Tiller e specificare che l'archivio saranno i segreti. Così, per ogni deployment, riceverai un segreto invece di un ConfigMap.
Potresti obiettare che i segreti stessi sono un concetto strano e non sono molto sicuri. Tuttavia, è importante comprendere che ciò è gestito dagli stessi sviluppatori di Kubernetes. A partire dalla versione 1.10, quindi già da un po', esiste la possibilità, almeno nei cloud pubblici, di collegare uno storage appropriato per la memorizzazione dei segreti. Attualmente, il team sta lavorando per migliorare ulteriormente l'accesso ai segreti, a singoli pod o ad altre entità.
Storage Helm è meglio tradurlo in segreti, e a loro volta è necessario proteggerli in modo centralizzato.
Certo, rimarrà un limite per l'archiviazione dei dati di 1 MB. Helm utilizza etcd come archivio distribuito per ConfigMap. Lì hanno calcolato che è un blocco di dati adatto per le replica e simili. Ci sono discussioni interessanti su questo su Reddit, consiglio di trovare questa lettura divertente per il fine settimana o di leggere un riassunto. .
Chart Repos
I chart sono particolarmente vulnerabili e possono diventare una fonte di "Man in the middle", specialmente se si utilizza una soluzione standard. Si parla principalmente di repository esposti tramite HTTP.
Sicuramente, è necessario esporre il Helm Repo tramite HTTPS: è la soluzione migliore e costata poco.
Fai attenzione a meccanismo di firma dei chart. La tecnologia è incredibilmente semplice. È la stessa che usi su GitHub, una normale macchina PGP con chiavi pubbliche e private. Configura e sarai sicuro, avendo le chiavi giuste e firmando tutto quello che è veramente il tuo chart.
Inoltre, Il client Helm supporta TLS (non nel senso HTTP lato server, ma TLS reciproco). Puoi utilizzare le chiavi server e client per comunicare. Per essere onesto, non utilizzo questo meccanismo per una certa avversione verso i certificati reciproci. Fondamentalmente, — il principale strumento per la registrazione di Helm Repo per Helm 2 — supporta anche l’autenticazione di base. Puoi utilizzare l'autenticazione di base se è più comodo e rassicurante.
C'è anche un plugin , che consente di ospitare Chart Repos in Google Cloud Storage. È molto comodo, funziona bene ed è abbastanza sicuro, poiché tutte le meccaniche descritte vengono utilizzate.
Se abiliti HTTPS o TLS, utilizzi mTLS e colleghi 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 importante — proteggere Tiller, che si trova nel cluster e che, da un lato, è un server, dall'altro, si rivolge ad altri componenti cercando di presentarsi come qualcuno.
Come ho già detto, Tiller è un servizio che espone gRPC, il client Helm si connette tramite gRPC. Di default, naturalmente, TLS è disattivato. Perché è stato fatto questo è una questione dibattuta; mi sembra che sia per semplificare la configurazione iniziale.
Per l'ambiente di produzione e persino per lo staging, consiglio di attivare TLS su gRPC.
A mio avviso, a differenza dell'mTLS per i chart, qui è opportuno e si fa molto facilmente: generate l'infrastruttura PQI, create un certificato, avviate Tiller e fornite il certificato durante l'inizializzazione. Da quel momento in poi, potrete eseguire tutti i comandi Helm presentando il certificato generato e la chiave privata.
In questo modo vi proteggerete da tutte le richieste a Tiller provenienti dall'esterno del cluster.
Quindi abbiamo protetto il canale di connessione a Tiller, discusso di RBAC e regolato i diritti del Kubernetes apiserver, 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 possono ora essere tracciate in verde:
- per il Chart Repo utilizziamo TLS o mTLS e autenticazione di base;
- mTLS per Tiller, che è esposto come servizio gRPC con TLS, utilizziamo certificati;
- nel cluster viene utilizzato un account di servizio speciale con Role e RoleBinding.
Abbiamo notevolmente messo in sicurezza il cluster, ma qualcuno di intelligente ha detto:
«L'unica soluzione assolutamente sicura può essere solo un computer spento, che si trova in una scatola di cemento e protetto 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 uno standard di sicurezza industriale di base.
Bonus
Questa parte non è direttamente correlata alla sicurezza, ma sarà comunque utile. Mostrerò alcune cose interessanti di cui pochi sono a conoscenza. Ad esempio, come cercare chart — ufficiali e non ufficiali.
Nel repository attualmente ci sono circa 300 chart e due stream: stable e incubator. Chi contribuisce sa benissimo quanto sia difficile passare da incubator a stable e quanto sia facile uscire da stable. Tuttavia, non è il miglior strumento per cercare chart per Prometheus e tutto ciò che ti piace, per una semplice ragione: non è un portale dove cercare pacchetti comodamente.
Ma c'è un servizio , grazie al quale trovare chart è molto più semplice. 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 fa parte del progetto Helm, e puoi contribuire anche alla sua interfaccia utente, se sei un frontend developer e vuoi semplicemente migliorare l'aspetto.
Voglio anche richiamare la tua attenzione su integrazione Open Service Broker API. Sembra complesso e poco chiaro, ma risolve problematiche con cui tutti si trovano a fare i conti. Spiego con un esempio semplice.
C'è un cluster Kubernetes in cui vogliamo avviare un'applicazione classica — WordPress. Di solito, per il pieno funzionamento è necessaria un database. Ci sono molte soluzioni diverse, ad esempio, si può avviare il proprio servizio stateful. Non è molto comodo, ma molti lo fanno.
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 a un database, creare un flavor del database, fornire le credenziali e gestirle in qualche modo. Tutto questo viene di solito fatto manualmente da un amministratore di sistema o da uno sviluppatore. E non ci sono problemi quando le applicazioni sono poche. Quando sono molte, serve un aggregatore. Esiste un aggregatore del genere: è il Service Broker. Permette di utilizzare un plugin speciale per il cluster del cloud pubblico e ordinare risorse dal fornitore attraverso il Broker, come se fosse un'API. A tal fine, si possono utilizzare gli strumenti nativi di Kubernetes.
È molto semplice. Si può richiedere, ad esempio, un Managed MySQL in Azure con un tier di base (questo è configurabile). Utilizzando l'API di Azure, il database verrà creato e preparato per l'uso. Non dovrà intervenire, poiché ciò è gestito dal plugin. Ad esempio, OSBA (il plugin di Azure) restituirà le credenziali al servizio e le passerà a Helm. Potrà utilizzare WordPress con MySQL cloud, senza doversi occupare delle basi dati gestite e senza preoccuparsi dei servizi stateful all'interno.
Si può dire che Helm funge da collante, che da un lato permette di deployare i servizi, mentre dall'altro consente di consumare risorse dai fornitori di cloud.
È possibile creare un proprio plugin e utilizzare tutta questa storia in locale. In tal modo, si avrà semplicemente il proprio plugin per un fornitore di Cloud aziendale. Consiglio di provare questo approccio, specialmente se si opera su larga scala e si desidera implementare rapidamente lo sviluppo, il testing o l'intera infrastruttura per una funzionalità. Questo semplificherà la vita ai vostri team operations o DevOps.
Un'altra scoperta che ho già menzionato è il plugin helm-gcs, che consente di utilizzare Google-buckets (archiviazione a oggetti) per memorizzare i chart di Helm.
Bastano solo quattro comandi per iniziare a utilizzarlo:
- installare il plugin;
- inizializzarlo;
- definire il percorso del bucket, che si trova in gcp;
- pubblicare i chart nel modo standard.
La bellezza è che verrà utilizzato il modo nativo di gcp per l'autenticazione. È possibile utilizzare un account di servizio, un account sviluppatore — qualsiasi cosa. È molto conveniente e non comporta costi operativi. Se, come me, promuovete la filosofia opsless, questo sarà molto utile, soprattutto per i team più piccoli.
Alternative
Helm non è l'unica soluzione per la gestione dei servizi. Ci sono molte domande a riguardo, probabilmente è per questo che è stata rilasciata così rapidamente la terza versione. Certo, esistono alternative.
Queste possono includere soluzioni specializzate come Ksonnet o Metaparticle. Puoi usare i tuoi strumenti tradizionali di gestione dell'infrastruttura (Ansible, Terraform, Chef, ecc.) per gli stessi obiettivi di cui ho parlato.
Infine, c'è una soluzione , la cui popolarità sta crescendo.
Operator Framework è l'alternativa principale a Helm, a cui prestare attenzione.
È più nativa 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 e Scaffold. Questi semplificano notevolmente la vita, ad esempio, facilitano il ciclo di invio e avvio di Helm per il deploy di ambienti di test. Li definirei ampliatori di funzionalità.
Ecco un grafico chiaro su dove si trova ciascuna cosa.
Sull'asse delle ascisse si trova il livello di controllo personale sugli eventi, mentre sull'asse delle ordinate si evidenzia il livello di natività di Kubernetes. La versione 2 di Helm è situata a metà strada. La versione 3 non apporta un cambiamento radicale, ma ci sono miglioramenti sia nel controllo sia nel livello di natività. Le soluzioni di Ksonnet sono comunque inferiori rispetto a Helm 2. Tuttavia, vale la pena darle un'occhiata per conoscere le altre opzioni disponibili in questo mondo. Certo, il vostro gestore di configurazione sarà sotto il vostro controllo, ma non è affatto nativo per Kubernetes.
L'Operator Framework è totalmente nativo per Kubernetes e consente una gestione molto più elegante e meticolosa (ma ricordiamo il livello di ingresso). È più adatto per applicazioni specializzate e per creare la loro gestione, piuttosto che per un'organizzazione di massa che impacchetta un gran numero di applicazioni tramite Helm.
Gli extender migliorano leggermente il controllo, integrano il workflow o affinano gli angoli nei pipeline CI/CD.
Il futuro di Helm
La buona notizia è che Helm 3 sta arrivando. È già stata rilasciata la versione alpha di Helm 3.0.0-alpha.2, da provare. È abbastanza stabile, ma la funzionalità è ancora limitata.
Perché è necessario Helm 3? In primo luogo, si tratta di una storia riguardante l'uscita di Tiller, come componente. Questo, come già sapete, è un enorme passo avanti, perché dal punto di vista della sicurezza architettonica tutto diventa più semplice.
Quando è stato creato Helm 2, ai tempi di Kubernetes 1.8 o anche prima, molte idee erano immature. Ad esempio, il concetto di CRD è ora attivamente implementato, e Helm utilizzerà CRD, per memorizzare strutture. Sarà possibile utilizzare solo il client e non gestire la parte server. Di conseguenza, sarà possibile 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). Questa è una grande iniziativa, e Helm è particolarmente interessato a essa per pubblicare i propri chart. Si arriva al punto che, ad esempio, Docker Hub supporta molti standard OCI. Non voglio sbilanciarmi, ma è possibile che i tradizionali provider di repository Docker inizino a offrire la possibilità di ospitare i propri chart Helm.
Una storia controversa per me è il supporto per Lua, come motore di templating per la scrittura di script. Non sono un grande fan di Lua, ma questa sarà un'opzione completamente facoltativa. L'ho verificato tre volte: l'uso di Lua non sarà obbligatorio. Pertanto, chi desidera utilizzare Lua, è libero di farlo, mentre chi preferisce Go può unirsi al nostro grande gruppo e utilizzare go-tmpl per questo.
Finalmente, ciò che mi mancava sicuramente era l'apparizione di uno schema e la validazione dei tipi di dati. Non ci saranno più problemi con int o string, non sarà necessario racchiudere zero tra virgolette. Comparirà uno schema JSON che permetterà di descrivere esplicitamente questo per i valori.
Sarà profondamente ristrutturato il modello event-driven. È già concettualmente descritto. Dai un'occhiata al ramo Helm 3 e vedrai quante più eventi, hook e altro sono stati aggiunti, il che semplificherà notevolmente e, dall'altra parte, aggiungerà controllo sui processi di deployment e reazioni ad essi.
Helm 3 sarà più semplice, sicuro e interessante non perché non ci piaccia Helm 2, ma perché Kubernetes sta diventando più avanzato. Di conseguenza, Helm può sfruttare i miglioramenti di Kubernetes e creare ottimi gestori per Kubernetes.
Un'altra buona notizia è che nella Alessandro Khaiyrov parlerà di Ricordiamo che la conferenza sull'integrazione dei processi di sviluppo, testing e operation si svolgerà a Mosca il 30 settembre e 1 ottobre. Fino al 20 agosto è possibile ancora e condividere la propria esperienza nella risoluzione problemi dell'approccio DevOps.
Segui gli aggiornamenti sulla conferenza e le novità sul e .
Fonte: habr.com
