L'essenza della storia del gestore di pacchetti più popolare per Kubernetes potrebbe essere rappresentata utilizzando un emoji:
- la scatola è Helm (che è la cosa più vicina all'ultima versione di Emoji);
- serratura: sicurezza;
- l'omino è la soluzione al problema.
In effetti, tutto sarà un po' più complicato, e la storia è piena di dettagli tecnici a riguardo Come rendere Helm sicuro.
- Brevemente cos'è Helm nel caso non lo sapessi o lo avessi dimenticato. Quali problemi risolve e dove si trova nell'ecosistema.
- Diamo un'occhiata all'architettura Helm. Nessuna conversazione sulla sicurezza e su come rendere più sicuro uno strumento o una soluzione è completa senza comprendere l'architettura del componente.
- Parliamo dei componenti di Helm.
- La domanda più scottante è il futuro: la nuova versione di Helm 3.
Tutto quanto contenuto in questo articolo si applica a Helm 2. Questa versione è attualmente in produzione ed è molto probabilmente quella che stai attualmente utilizzando ed è la versione che contiene i rischi per la sicurezza.
Informazioni sull'oratore: Aleksandr Khaërov () si sviluppa da 10 anni, contribuendo a migliorare i contenuti e si unì al comitato . Ora lavora presso Chainstack come responsabile dello sviluppo: è un ibrido tra un responsabile dello sviluppo e una persona responsabile della consegna delle versioni finali. Cioè si trova sul campo di battaglia, dove tutto avviene dalla creazione di un prodotto al suo funzionamento.
Chainstack è una piccola startup in rapida crescita la cui missione è consentire ai clienti di dimenticare l'infrastruttura e le complessità delle applicazioni decentralizzate; il team di sviluppo ha sede a Singapore. Non chiedere a Chainstack di vendere o acquistare criptovaluta, ma offriti di parlare di strutture blockchain aziendali e ti risponderanno volentieri.
Casco
Questo è un gestore di pacchetti (grafici) per Kubernetes. Il modo più intuitivo e universale per portare le applicazioni in un cluster Kubernetes.
Stiamo ovviamente parlando di un approccio più strutturale e industriale rispetto alla creazione dei propri manifest YAML e alla scrittura di piccole utilità.
Helm è il migliore attualmente disponibile e popolare.
Perchè Helm? Innanzitutto perché è sostenuto dal CNCF. Cloud Native è una grande organizzazione ed è la società madre dei progetti Kubernetes, etcd, Fluentd e altri.
Un altro fatto importante è che Helm è un progetto molto popolare. Quando ho iniziato a parlare di come rendere sicuro Helm nel gennaio 2019, il progetto aveva mille stelle su GitHub. A maggio erano 12mila.
Molte persone sono interessate a Helm, quindi anche se non lo usi ancora, trarrai vantaggio dalla conoscenza della sua sicurezza. La sicurezza è importante.
Il team principale di Helm è supportato da Microsoft Azure ed è quindi un progetto abbastanza stabile, a differenza di molti altri. Il rilascio di Helm 3 Alpha 2 a metà luglio indica che ci sono molte persone che lavorano al progetto e hanno il desiderio e l'energia per sviluppare e migliorare Helm.
Helm risolve diversi problemi alla radice della gestione delle applicazioni in Kubernetes.
- Confezione dell'applicazione. Anche un'applicazione come "Hello, World" su WordPress è già composta da diversi servizi e vorresti raggrupparli insieme.
- Gestire la complessità che deriva dalla gestione di queste applicazioni.
- Un ciclo di vita che non termina dopo l'installazione o la distribuzione dell'applicazione. Continua a vivere, ha bisogno di essere aggiornato e Helm aiuta in questo e cerca di portare le giuste misure e politiche per questo.
Insaccamento è organizzato in modo chiaro: ci sono metadati in pieno accordo con il lavoro di un normale gestore di pacchetti per Linux, Windows o MacOS. Cioè un repository, dipendenze da vari pacchetti, metainformazioni per applicazioni, impostazioni, funzionalità di configurazione, indicizzazione delle informazioni, ecc. Helm ti consente di ottenere e utilizzare tutto questo per le applicazioni.
Gestione della complessità. Se si hanno molte applicazioni dello stesso tipo è necessaria la parametrizzazione. I modelli derivano da questo, ma per evitare di dover inventare il proprio modo di creare modelli, è possibile utilizzare ciò che Helm offre immediatamente.
Gestione del ciclo di vita delle applicazioni - secondo me questa è la domanda più interessante e irrisolta. Questo è il motivo per cui sono venuto a Helm in passato. Avevamo bisogno di tenere d'occhio il ciclo di vita dell'applicazione e volevamo spostare i nostri cicli CI/CD e applicativi su questo paradigma.
Il timone ti consente di:
- gestire le distribuzioni, introduce il concetto di configurazione e revisione;
- eseguire con successo il rollback;
- utilizzare gli hook per eventi diversi;
- aggiungere ulteriori controlli dell'applicazione e rispondere ai relativi risultati.
Inoltre Il timone ha "batterie" - un numero enorme di cose gustose che possono essere incluse sotto forma di plugin, semplificandoti la vita. I plugin possono essere scritti in modo indipendente, sono abbastanza isolati e non richiedono un'architettura armoniosa. Se vuoi implementare qualcosa, ti consiglio di farlo come plugin, e poi eventualmente includerlo nell'upstream.
Helm si basa su tre concetti principali:
- Raccolta grafici — descrizione e serie di parametrizzazioni possibili per il tuo manifest.
- Config —ovvero, i valori che verranno applicati (testo, valori numerici, ecc.).
- Rilasciare raccoglie le due componenti superiori, e insieme si trasformano in Release. È possibile modificare la versione delle versioni, ottenendo così un ciclo di vita organizzato: piccolo al momento dell'installazione e grande al momento dell'aggiornamento, downgrade o rollback.
Architettura del timone
Il diagramma descrive concettualmente l'architettura di alto livello di Helm.
Lascia che ti ricordi che Helm è qualcosa legato a Kubernetes. Pertanto non possiamo fare a meno di un cluster Kubernetes (rettangolo). Il componente kube-apiserver risiede sul master. Senza Helm abbiamo Kubeconfig. Helm porta un piccolo binario, se così si può chiamare, l'utilità Helm CLI, che viene installata su un 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, proprio come qualsiasi altra.
Il componente successivo di Chart Repo è un repository con grafici. Esiste un archivio ufficiale e potrebbe esserci un archivio privato di un'azienda o di un progetto.
Interazione
Diamo un'occhiata a come interagiscono i componenti dell'architettura quando vogliamo installare un'applicazione utilizzando Helm.
- Noi parliamo
Helm install, accedi al repository (Chart Repo) e ottieni un grafico Helm.
- L'utilità Helm (Helm CLI) interagisce con Kubeconfig per capire quale cluster contattare.
- Dopo aver ricevuto queste informazioni, l'utilità si riferisce a Tiller, che si trova nel nostro cluster, come applicazione.
- Tiller chiama Kube-apiserver per eseguire azioni in Kubernetes, creare alcuni oggetti (servizi, pod, repliche, segreti, ecc.).
Successivamente, complicheremo il diagramma per vedere il vettore di attacco a cui può essere esposta l'intera architettura Helm. E poi proveremo a proteggerla.
Vettore di attacco
Il primo potenziale punto debole è API privilegiata-utente. Nell'ambito dello schema, si tratta di un hacker che ha ottenuto l'accesso amministrativo alla CLI di Helm.
Utente API non privilegiato può anche rappresentare un pericolo se si trova da qualche parte nelle vicinanze. Un utente di questo tipo avrà un contesto diverso, ad esempio potrà essere fissato in uno spazio dei nomi del cluster nelle impostazioni Kubeconfig.
Il vettore di attacco più interessante potrebbe essere un processo che risiede all’interno di un cluster da qualche parte vicino a Tiller e può accedervi. Può trattarsi di un server Web o di un microservizio che vede l'ambiente di rete del cluster.
Una variante di attacco esotica, ma sempre più popolare, coinvolge Chart Repo. Un grafico creato da un autore senza scrupoli può contenere risorse non sicure e lo completerai credendolo per fede. Oppure può sostituire il grafico scaricato dal repository ufficiale e, ad esempio, creare una risorsa sotto forma di policy e aumentarne l'accesso.
Proviamo a respingere gli attacchi da tutti questi quattro lati e a capire dove ci sono problemi nell'architettura Helm e dove, forse, non ce ne sono.
Ingrandiamo il diagramma, aggiungiamo più elementi, ma manteniamo tutti i componenti di base.
La CLI Helm comunica con Chart Repo, interagisce con Kubeconfig e il lavoro viene trasferito dal cluster al componente Tiller.
Tiller è rappresentato da due oggetti:
- Tiller-deploy svc, che espone un determinato servizio;
- Pod con distribuzione Tiller (nel diagramma in una singola copia in una replica), su cui viene eseguito l'intero carico, che accede al cluster.
Per l'interazione vengono utilizzati diversi protocolli e schemi. Dal punto di vista della sicurezza, ci interessano soprattutto:
- Il meccanismo attraverso il quale la CLI Helm accede al repository dei grafici: quale protocollo, esiste l'autenticazione e cosa si può fare con esso.
- Il protocollo mediante il quale la CLI di Helm, utilizzando kubectl, comunica con Tiller. Si tratta di un server RPC installato all'interno del cluster.
- Tiller stesso è accessibile ai microservizi che risiedono nel cluster e interagisce con Kube-apiserver.
Discutiamo tutte queste aree in ordine.
RBAC
Non ha senso parlare di sicurezza per Helm o qualsiasi altro servizio all'interno del cluster a meno che RBAC non sia abilitato.
Sembra che questa non sia l'ultima raccomandazione, ma sono sicuro che molte persone non hanno ancora abilitato RBAC nemmeno in produzione, perché è un sacco di confusione e molte cose devono essere configurate. Tuttavia, ti incoraggio a farlo.
- avvocato del sito web per RBAC. Contiene un'enorme quantità di materiali interessanti che ti aiuteranno a configurare RBAC, a mostrare perché è utile e come conviverci sostanzialmente nella produzione.
Proverò a spiegare come funzionano Tiller e RBAC. Tiller funziona all'interno del cluster con un determinato account di servizio. In genere, se RBAC non è configurato, questo sarà il superutente. Nella configurazione di base, Tiller sarà un amministratore. Questo è il motivo per cui si dice spesso che Tiller è un tunnel SSH verso il tuo cluster. In effetti, questo è vero, quindi puoi utilizzare un account di servizio dedicato separato invece dell'account di servizio predefinito nel diagramma sopra.
Quando inizializzi Helm e lo installi sul server per la prima volta, puoi impostare l'account del servizio utilizzando --service-account. Ciò ti consentirà di utilizzare un utente con il set minimo di diritti richiesto. È vero, dovrai creare una tale "ghirlanda": Role e RoleBinding.
Sfortunatamente, Helm non lo farà per te. Tu o il tuo amministratore del cluster Kubernetes dovete preparare in anticipo un set di ruoli e associazioni di ruolo per l'account di servizio per poter passare Helm.
Sorge la domanda: qual è la differenza tra Role e ClusterRole? La differenza è che ClusterRole funziona per tutti gli spazi dei nomi, a differenza dei normali ruoli e RoleBinding, che funzionano solo per uno spazio dei nomi specializzato. Puoi configurare policy per l'intero cluster e tutti gli spazi dei nomi oppure personalizzate per ogni spazio dei nomi individualmente.
Vale la pena ricordare che RBAC risolve un altro grosso problema. Molte persone si lamentano del fatto che Helm, sfortunatamente, non è multitenancy (non supporta la multitenancy). Se più team utilizzano un cluster e utilizzano Helm, è praticamente impossibile impostare policy e limitare il loro accesso all'interno di questo cluster, perché esiste un determinato account di servizio con cui viene eseguito Helm e da esso crea tutte le risorse nel cluster , che a volte è molto scomodo. Questo è vero, come il file binario stesso, come il processo, Helm Tiller non ha il concetto di multitenancy.
Tuttavia, esiste un ottimo modo che ti consente di eseguire Tiller più volte in un cluster. Non c'è problema con questo, Tiller può essere lanciato in ogni spazio dei nomi. Pertanto, puoi utilizzare RBAC, Kubeconfig come contesto e limitare l'accesso a un Helm speciale.
Sembrerà così.
Ad esempio, esistono due Kubeconfig con contesto per team diversi (due spazi dei nomi): X Team per il team di sviluppo e il cluster di amministrazione. Il cluster di amministrazione ha un proprio ampio Tiller, che si trova nello spazio dei nomi del sistema Kube, un account di servizio corrispondentemente avanzato. E uno spazio dei nomi separato per il team di sviluppo, che potrà distribuire i propri servizi in uno spazio dei nomi speciale.
Questo è un approccio praticabile, Tiller non è così assetato di potere da influenzare notevolmente il tuo budget. Questa è una delle soluzioni rapide.
Sentiti libero di configurare Tiller separatamente e fornire a Kubeconfig il contesto per il team, per uno sviluppatore specifico o per l'ambiente: sviluppo, staging, produzione (è dubbio che tutto sarà sullo stesso cluster, tuttavia è possibile farlo).
Continuando la nostra storia, passiamo da RBAC e parliamo di ConfigMap.
ConfigMap
Helm utilizza ConfigMaps come archivio dati. Quando parlavamo di architettura, non esisteva alcun database da nessuna parte che memorizzasse informazioni su rilasci, configurazioni, rollback, ecc. Per questo viene utilizzato ConfigMaps.
Il problema principale con i ConfigMap è noto: in linea di principio non sono sicuri; è impossibile memorizzare dati sensibili. Stiamo parlando di tutto ciò che non dovrebbe andare oltre il servizio, ad esempio le password. Il modo più nativo per Helm in questo momento è passare dall'uso di ConfigMap ai segreti.
Questo viene fatto in modo molto semplice. Sostituisci l'impostazione di Tiller e specifica che l'archiviazione sarà segreta. Quindi per ogni distribuzione riceverai non una ConfigMap, ma un segreto.
Si potrebbe sostenere che i segreti stessi siano un concetto strano e non molto sicuro. Tuttavia, vale la pena capire che gli stessi sviluppatori Kubernetes lo stanno facendo. A partire dalla versione 1.10, cioè Già da tempo è possibile, almeno nei cloud pubblici, connettere lo storage corretto per archiviare i segreti. Il team sta ora lavorando su come distribuire meglio l'accesso a segreti, singoli pod o altre entità.
È meglio trasferire Storage Helm sui segreti e questi, a loro volta, saranno protetti a livello centrale.
Naturalmente rimarrà limite di archiviazione dati di 1 MB. Helm qui utilizza etcd come spazio di archiviazione distribuito per ConfigMap. E lì hanno ritenuto che si trattasse di un blocco di dati adatto per la replica, ecc. C'è una discussione interessante a riguardo su Reddit, consiglio di trovare questa lettura divertente per il fine settimana o di leggerne l'estratto .
Repository grafici
I grafici sono i più vulnerabili socialmente e possono diventare fonte di “uomo di mezzo”, soprattutto se si utilizza una soluzione azionaria. Innanzitutto parliamo di repository esposti tramite HTTP.
Devi assolutamente esporre Helm Repo su HTTPS: questa è l'opzione migliore ed è poco costosa.
Notare la meccanismo di firma della carta. La tecnologia è semplicissima. Questa è la stessa cosa che usi su GitHub, una normale macchina PGP con chiavi pubbliche e private. Configuralo e assicurati, avendo le chiavi necessarie e firmando tutto, che questo sia davvero il tuo grafico.
Inoltre, Il client Helm supporta TLS (non nel senso HTTP lato server, ma TLS reciproco). È possibile utilizzare le chiavi server e client per comunicare. Ad essere sincero, non utilizzo questo meccanismo perché non mi piacciono i certificati reciproci. Fondamentalmente, - lo strumento principale per configurare Helm Repo per Helm 2 - supporta anche l'autenticazione di base. Puoi utilizzare l'autenticazione di base se è più conveniente e silenzioso.
C'è anche un plugin , che ti consente di ospitare Chart Repos su Google Cloud Storage. Questo è abbastanza conveniente, funziona benissimo ed è abbastanza sicuro, perché tutti i meccanismi descritti vengono riciclati.
Se abiliti HTTPS o TLS, utilizzi mTLS e abiliti l'autenticazione di base per ridurre ulteriormente i rischi, otterrai un canale di comunicazione sicuro con Helm CLI e Chart Repo.
API gRPC
Il passo successivo è molto importante: proteggere Tiller, che si trova nel cluster ed è, da un lato, un server, dall'altro accede esso stesso ad altri componenti e cerca di fingere di essere qualcuno.
Come ho già detto, Tiller è un servizio che espone gRPC, il client Helm vi arriva tramite gRPC. Per impostazione predefinita, ovviamente, TLS è disabilitato. Perché ciò sia stato fatto è una questione discutibile, mi sembra che semplifichi la configurazione all'inizio.
Per la produzione e anche per la gestione temporanea, consiglio di abilitare TLS su gRPC.
A mio parere, a differenza di mTLS per i grafici, questo è appropriato qui e viene fatto in modo molto semplice: generare un'infrastruttura PQI, creare un certificato, avviare Tiller, trasferire il certificato durante l'inizializzazione. Successivamente potrai eseguire tutti i comandi Helm, presentandoti con il certificato generato e la chiave privata.
In questo modo ti proteggerai da tutte le richieste a Tiller provenienti dall'esterno del cluster.
Abbiamo quindi messo in sicurezza il canale di connessione a Tiller, abbiamo già parlato di RBAC e adeguato i diritti dell'apiserver Kubernetes, riducendo il dominio con cui può interagire.
Elmo protetto
Diamo un'occhiata al diagramma finale. È la stessa architettura con le stesse frecce.
Tutte le connessioni possono ora essere tranquillamente disegnate in verde:
- per Chart Repo utilizziamo TLS o mTLS e autenticazione di base;
- mTLS per Tiller, ed è esposto come servizio gRPC con TLS, utilizziamo i certificati;
- il cluster utilizza un account di servizio speciale con Role e RoleBinding.
Abbiamo messo in sicurezza il cluster in modo significativo, ma qualcuno intelligente ha detto:
"Può esserci solo una soluzione assolutamente sicura: un computer spento, che si trova in una scatola di cemento ed è sorvegliato dai soldati."
Esistono diversi modi per manipolare i dati e trovare nuovi vettori di attacco. Tuttavia, sono fiducioso che queste raccomandazioni raggiungeranno uno standard industriale fondamentale per la sicurezza.
premio
Questa parte non è direttamente correlata alla sicurezza, ma sarà comunque utile. Ti mostrerò alcune cose interessanti che poche persone conoscono. Ad esempio, come cercare le classifiche: ufficiali e non ufficiali.
Nel deposito Ora ci sono circa 300 grafici e due flussi: stabile e incubatore. Chi contribuisce sa perfettamente quanto sia difficile passare dall'incubatrice alla stalla, e quanto sia facile volare via dalla stalla. Tuttavia, questo non è lo strumento migliore per cercare carte per Prometheus e qualsiasi altra cosa tu voglia, per una semplice ragione: non è un portale dove puoi cercare comodamente i pacchetti.
Ma c'è un servizio , il che rende molto più comodo trovare i grafici. Ancora più importante, sono disponibili molti più repository esterni e quasi 800 accessi. Inoltre, puoi connettere il tuo repository se per qualche motivo non desideri inviare i tuoi grafici a stable.
Prova hub.helm.sh e sviluppiamolo insieme. Questo servizio fa parte del progetto Helm e puoi anche contribuire alla sua interfaccia utente se sei uno sviluppatore front-end e desideri solo migliorare l'aspetto.
Vorrei anche attirare la vostra attenzione Integrazione dell'API Open Service Broker. Sembra complicato e poco chiaro, ma risolve i problemi che tutti devono affrontare. Lasciatemi spiegare con un semplice esempio.
Esiste un cluster Kubernetes in cui vogliamo eseguire un'applicazione classica: WordPress. In genere, per la piena funzionalità è necessario un database. Esistono molte soluzioni diverse, ad esempio puoi avviare il tuo servizio statefull. Questo non è molto conveniente, ma molte persone lo fanno.
Altri, come noi di Chainstack, utilizzano database gestiti come MySQL o PostgreSQL per i loro server. Ecco perché i nostri database si trovano da qualche parte nel cloud.
Ma sorge un problema: dobbiamo connettere il nostro servizio con un database, creare un sapore di database, trasferire le credenziali e gestirle in qualche modo. Tutto ciò viene solitamente eseguito manualmente dall'amministratore di sistema o dallo sviluppatore. E non c'è problema quando ci sono poche applicazioni. Quando ce ne sono molti, hai bisogno di una mietitrebbia. Esiste una tale mietitrice: è Service Broker. Ti consente di utilizzare un plug-in speciale per un cluster di cloud pubblico e ordinare risorse dal provider tramite Broker, come se fosse un'API. Per fare ciò, puoi utilizzare gli strumenti nativi di Kubernetes.
È molto semplice. È possibile eseguire query, ad esempio, su Managed MySQL in Azure con un livello base (questo può essere configurato). Utilizzando l'API di Azure, il database verrà creato e preparato per l'uso. Non è necessario che tu interferisca con questo, il plugin ne è responsabile. Ad esempio, OSBA (plug-in di Azure) restituirà le credenziali al servizio e le passerà a Helm. Potrai utilizzare WordPress con il cloud MySQL, non occuparti affatto dei database gestiti e non preoccuparti dei servizi stateful all'interno.
Possiamo dire che Helm funge da collante che, da un lato, consente di distribuire servizi e, dall'altro, consumare le risorse dei fornitori di servizi cloud.
Puoi scrivere il tuo plugin e utilizzare l'intera storia in sede. Quindi avrai semplicemente il tuo plug-in per il provider cloud aziendale. Ti consiglio di provare questo approccio, soprattutto se disponi di un progetto su larga scala e desideri distribuire rapidamente lo sviluppo, la gestione temporanea o l'intera infrastruttura per una funzionalità. Ciò semplificherà la vita alle tue operazioni o a DevOps.
Un'altra scoperta che ho già menzionato è plugin helm-gcs, che ti consente di utilizzare i bucket Google (archiviazione di oggetti) per archiviare i grafici Helm.
Hai solo bisogno di quattro comandi per iniziare a usarlo:
- installare il plug-in;
- avviarlo;
- imposta il percorso del bucket, che si trova in gcp;
- pubblicare grafici nel modo standard.
Il bello è che per l'autorizzazione verrà utilizzato il metodo gcp nativo. Puoi utilizzare un account di servizio, un account sviluppatore, qualunque cosa tu voglia. È molto conveniente e non costa nulla da usare. Se tu, come me, promuovi la filosofia opsless, allora questo sarà molto conveniente, soprattutto per i piccoli team.
alternative
Helm non è l'unica soluzione di gestione dei servizi. Ci sono molte domande al riguardo, motivo per cui la terza versione è apparsa così rapidamente. Naturalmente ci sono delle alternative.
Queste possono essere soluzioni specializzate, ad esempio Ksonnet o Metaparticle. Puoi utilizzare i tuoi classici strumenti di gestione dell'infrastruttura (Ansible, Terraform, Chef, ecc.) per gli stessi scopi di cui ho parlato.
Finalmente c'è una soluzione , la cui popolarità è in crescita.
Operator Framework è la principale alternativa a Helm da considerare.
È più nativo di CNCF e Kubernetes, ma la barriera all’ingresso è molto più alta, è necessario programmare di più e descrivere meno i manifest.
Esistono vari componenti aggiuntivi, come Draft, Scaffold. Rendono la vita molto più semplice, ad esempio semplificano il ciclo di invio e avvio di Helm affinché gli sviluppatori possano distribuire un ambiente di test. Li definirei empowerer.
Ecco una tabella visiva di dove si trova tutto.
Sull'asse x c'è il livello del tuo controllo personale su ciò che sta accadendo, sull'asse y c'è il livello di natività di Kubernetes. La versione 2 di Helm si colloca da qualche parte nel mezzo. Nella versione 3, non enormemente, ma sia il controllo che il livello di natività sono stati migliorati. Le soluzioni a livello Ksonnet sono ancora inferiori anche a Helm 2. Tuttavia, vale la pena guardarle per sapere cos'altro c'è in questo mondo. Naturalmente, il tuo gestore di configurazione sarà sotto il tuo controllo, ma non è assolutamente nativo di Kubernetes.
L'Operator Framework è assolutamente nativo di Kubernetes e permette di gestirlo in modo molto più elegante e scrupoloso (ma ricordatevi dell'entry level). Piuttosto, questo è adatto per un'applicazione specializzata e per la creazione di una relativa gestione, piuttosto che per una raccolta di massa per il confezionamento di un numero enorme di applicazioni utilizzando Helm.
Gli extender migliorano semplicemente un po' il controllo, integrano il flusso di lavoro o riducono gli angoli sulle pipeline CI/CD.
Il futuro di Helm
La buona notizia è che sta arrivando Helm 3. La versione alpha di Helm 3.0.0-alpha.2 è già stata rilasciata, puoi provarla. È abbastanza stabile, ma la funzionalità è ancora limitata.
Perché hai bisogno di Helm 3? Prima di tutto, questa è una storia scomparsa di Tiller, come componente. Questo, come già capite, è un enorme passo avanti, perché dal punto di vista della sicurezza dell'architettura tutto è semplificato.
Quando fu creato Helm 2, più o meno all'epoca di Kubernetes 1.8 o anche prima, molti dei concetti erano immaturi. Ad esempio, il concetto CRD viene ora implementato attivamente e Helm lo farà utilizzare il CRDper immagazzinare strutture. Sarà possibile utilizzare solo la parte client e non mantenere la parte server. Di conseguenza, utilizza i comandi Kubernetes nativi per lavorare con strutture e risorse. Questo è un enorme passo avanti.
Apparirà supporto per repository OCI nativi (Iniziativa Open Container). Si tratta di un'iniziativa enorme e Helm è interessata principalmente a pubblicare le sue classifiche. Si arriva al punto che, ad esempio, Docker Hub supporta molti standard OCI. Non sto indovinando, ma forse i classici provider di repository Docker inizieranno a darti l'opportunità di ospitare i tuoi grafici Helm.
La storia controversa per me è Supporto Lua, come motore di modelli per la scrittura di script. Non sono un grande fan di Lua, ma questa sarebbe una funzionalità completamente opzionale. L'ho controllato 3 volte: l'uso di Lua non sarà necessario. Pertanto, coloro che vogliono poter utilizzare Lua, coloro a cui piace Go, si uniscono al nostro enorme campo e utilizzano go-tmpl per questo.
Infine, quello che sicuramente mi mancava era Emergenza dello schema e validazione del tipo di dati. Non ci saranno più problemi con int o string, non sarà necessario racchiudere lo zero tra virgolette doppie. Apparirà uno schema JSONS che ti consentirà di descriverlo esplicitamente per i valori.
Verrà pesantemente rielaborato modello guidato dagli eventi. È già stato concettualmente descritto. Guarda il ramo Helm 3 e vedrai quanti eventi, hook e altre cose sono stati aggiunti, il che semplificherà notevolmente e, d'altra parte, aggiungerà controllo sui processi di distribuzione e sulle reazioni ad essi.
Helm 3 sarà più semplice, più sicuro e più divertente, non perché non ci piaccia Helm 2, ma perché Kubernetes sta diventando più avanzato. Di conseguenza, Helm può utilizzare gli sviluppi di Kubernetes e creare su di esso eccellenti manager per Kubernetes.
Un'altra buona notizia è questa Alexander Khayorov te lo dirà, Ricordiamo che a Mosca si terrà la conferenza sull'integrazione dei processi di sviluppo, test e funzionamento 30 settembre e 1 ottobre. Puoi farlo ancora fino al 20 agosto e raccontaci la tua esperienza con la soluzione compiti dell’approccio DevOps.
Segui i checkpoint e le notizie della conferenza su и .
Fonte: habr.com
