In seguito a presentiamo il suo fratello maggiore — . È un progetto Open Source utilizzato per l'installazione, in cluster Kubernetes, di componenti di sistema che possiamo chiamare genericamente — estensioni.
Perché abbiamo bisogno di estensioni?
Non è un segreto che Kubernetes non sia un prodotto completo tutto-in-uno e per costruire un cluster "maturo" siano necessarie varie estensioni. L'addon-operator aiuta a installare, configurare e mantenere queste estensioni aggiornate.
La necessità di componenti aggiuntivi nel cluster è spiegata in colleghi . In breve, la situazione attuale con Kubernetes è tale che per una semplice installazione "per divertirsi" si possono utilizzare i componenti di base, per sviluppatori e test si può aggiungere Ingress, ma per un'installazione completa, di cui si può dire "la vostra produzione è pronta", è necessario aggiungere una dozzina di vari estensioni: qualcosa per il monitoring, qualcosa per i log, non dimenticare ingress e cert-manager, dedicare gruppi di nodi, aggiungere politiche di rete, condire con impostazioni sysctl e un pod autoscaler...
Qual è la specificità del lavoro con loro?
Come dimostra la pratica, non basta una sola installazione. Per lavorare comodamente con il cluster, sarà necessario aggiornare i plugin, disabilitarli (rimuoverli dal cluster) e testare alcune funzionalità prima di installarle nel cluster di produzione.
Quindi, basterà qui anche Ansible? Forse. Ma i plugin completi generalmente non funzionano senza configurazioni. Queste configurazioni possono variare a seconda del tipo di cluster (aws, gce, azure, bare-metal, do, …). Alcune impostazioni non possono essere definite in anticipo — devono essere ottenute dal cluster. E il cluster non è statico: bisogna monitorare alcune configurazioni per eventuali cambiamenti. Qui Ansible non basta: occorre un programma che viva nel cluster, cioè un Kubernetes Operator.
Coloro che l'hanno provato in pratica , diranno che le attività di installazione e aggiornamento dei plugin e di monitoraggio delle impostazioni possono essere tranquillamente gestite con per shell-operator. È possibile scrivere uno script che faccia un condizionale kubectl apply e monitori, ad esempio, il ConfigMap dove saranno archiviate le configurazioni. Questo è più o meno ciò che è stato realizzato in addon-operator.
Come è organizzato in addon-operator?
Creando una nuova soluzione, ci siamo basati sui seguenti principi:
- Il gestore dei componenti deve supportare la templattizzazione e la configurazione dichiarativa. Non creiamo script magici che installano i componenti. L'addon-operator utilizza Helm per installare i componenti. Per l'installazione è necessario creare un chart e specificare i values che saranno utilizzati per la configurazione.
- Le impostazioni possono essere generate durante l'installazione, possono essere ottenute dal cluster, oppure ricevere aggiornamenti, monitorando le risorse del cluster. Queste operazioni possono essere implementate mediante hook.
- Le impostazioni possono conservare nel cluster. Per memorizzare le impostazioni nel cluster viene creato un ConfigMap/addon-operator e l'addon-operator monitora le modifiche a questo ConfigMap. L'addon-operator fornisce l'accesso alle impostazioni tramite semplici convenzioni.
- Il componente dipende dalle impostazioni. Se le impostazioni cambiano, l'addon-operator distribuisce il Helm-chart con i nuovi values. L'unione del Helm-chart, dei values per esso e degli hook è ciò che chiamiamo modulo (ulteriori dettagli di seguito).
- Staging. Non ci sono script di rilascio magici. Il meccanismo di aggiornamento è simile a un'applicazione normale: confezionare i componenti e l'addon-operator in un'immagine, etichettare e distribuire.
- Controllo dei risultati. L'addon-operator è in grado di fornire metriche per Prometheus.
Che cos'è un addon nell'addon-operator?
Si può considerare un addon qualsiasi cosa che aggiunge nuove funzionalità al cluster. Ad esempio, l'installazione di Ingress è un ottimo esempio di addon. Può trattarsi di qualsiasi operatore o controller con il proprio CRD: prometheus-operator, cert-manager, kube-controller-manager, e così via. Oppure qualcosa di piccolo, ma che semplifica l'operatività, come un secret copier che copia i segreti del registry in nuovi spazi dei nomi, o un sysctl tuner che regola i parametri sysctl sui nuovi nodi.
Per implementare gli addon, l'addon-operator fornisce diverse concezioni:
- Chart Helm utilizzato per installare vari software nel cluster, come Prometheus, Grafana, nginx-ingress. Se il componente desiderato ha un Helm chart, sarà molto semplice installarlo utilizzando l'addon-operator.
- Archiviazione dei valori. Gli Helm chart di solito hanno molte diverse impostazioni, che possono cambiare nel tempo. L'addon-operator supporta la memorizzazione di queste impostazioni e può monitorarne le modifiche, in modo da reinstallare l'Helm chart con nuovi valori.
- Hook — sono file eseguibili che l'addon-operator avvia in risposta a eventi e che accedono allo storage dei valori. Il hook può monitorare le modifiche nel cluster e aggiornare i valori nello storage. Ciò significa che con l'uso dei hook è possibile effettuare una discovery per raccogliere valori dal cluster all'avvio o su un programma, oppure effettuare una continuous discovery, raccogliendo valori dal cluster in base alle modifiche nel cluster.
- Modulo — è un'unione di Helm chart, storage dei valori e hook. I moduli possono essere attivati o disattivati. Disattivare un modulo significa rimuovere tutte le release dell'Helm chart. I moduli possono auto-inclusersi dinamicamente, ad esempio, se sono attivati tutti i moduli necessari o se la discovery negli hook ha trovato i parametri richiesti — questo avviene tramite uno script aggiuntivo abilitato.
- Hook globali. Sono hook "standalone", non inclusi nei moduli e hanno accesso allo storage globale dei valori, i cui valori sono disponibili per tutti gli hook nei moduli.
Come funzionano insieme queste parti? Consideriamo l'immagine della documentazione:
Ci sono due scenari di lavoro:
- Il gancio globale viene attivato da un evento, ad esempio, quando una risorsa nel cluster viene modificata. Questo gancio gestisce le modifiche e registra i nuovi valori nello storage globale values. L'addon-operator nota che lo storage globale è stato modificato e attiva tutti i moduli. Ogni modulo, attraverso i propri ganci, determina se deve essere attivato e aggiorna il proprio storage values. Se il modulo è attivo, l'addon-operator avvia l'installazione del chart Helm. Il chart Helm ha accesso ai valori dallo storage del modulo e dallo storage globale.
- Il secondo scenario è più semplice: il gancio del modulo si attiva su un evento, modifica i valori nello storage values del modulo. L'addon-operator se ne accorge e avvia il chart Helm con i valori aggiornati.
Un addon può essere implementato come un unico gancio o come un unico chart Helm, o anche come diversi moduli dipendenti -- questo dipende dalla complessità del componente installato nel cluster e dal livello di flessibilità delle impostazioni richieste. Ad esempio, nel repository () c'è un componente sysctl-tuner, che è implementato sia come un semplice modulo con hook e Helm chart, sia utilizzando un repository di valori, il che consente di aggiungere configurazioni tramite la modifica di ConfigMap.
Consegna degli aggiornamenti
Qualche parola sull'organizzazione degli aggiornamenti dei componenti installati dall'Addon-operator.
Per avviare l'Addon-operator nel cluster, è necessario costruire un'immagine con i componenti sotto forma di file hook e Helm chart, aggiungere il file binario addon-operator e tutto ciò che serve per gli hook: bash, kubectl, jq, python e così via. Successivamente, questa immagine può essere distribuita nel cluster come un'applicazione normale e probabilmente vorrete organizzare uno schema di tagging. Se i cluster sono pochi, potrebbe andar bene lo stesso approccio utilizzato per le applicazioni: nuova release, nuova versione, passare attraverso tutti i cluster e aggiornare l'immagine nei Pod. Tuttavia, nel caso di distribuzioni su un numero significativo di cluster, è più adatta la concettualizzazione dell'autoaggiornamento dal canale.
Noi abbiamo organizzato così:
- Il canale è essenzialmente un identificativo, che può essere impostato arbitrariamente (ad esempio, dev/stage/ea/stable).
- Il nome del canale è l'etichetta dell'immagine. Quando è necessario rilasciare aggiornamenti nel canale, viene creata una nuova immagine e etichettata con il nome del canale.
- Quando una nuova immagine appare nel registry, l'Addon-operator viene riavviato e avviato con la nuova immagine.
Questo non è una best practice, come indicato in . È sconsigliato farlo, ma si tratta di un'applicazione comune che vive in un unico cluster. Nel caso dell'Addon-operator, l'applicazione consiste in più Deployments distribuiti tra i cluster, e l'autoaggiornamento è molto utile e semplifica la vita.
I canali aiutano anche nei test: se c'è un cluster secondario, è possibile configurarlo su un canale stage e testare aggiornamenti su di esso prima di rilasciarli nei canali ea e stable. Se si verifica un errore con il cluster sul canale ea , può essere spostato su stable, mentre si indaga sul problema con questo cluster. Se il cluster esce dal supporto attivo, viene spostato sul suo canale "congelato" — ad esempio, freeze-2019-03-20.
. Oltre ad aggiornare hook e Helm chart potrebbe essere necessario aggiornare anche un componente di terze parti. Ad esempio, hai notato un errore nel node-exporter condizionale e hai anche trovato una soluzione per applicare una patch. Poi hai aperto una PR e stai aspettando il nuovo rilascio per aggiornare tutte le versioni del tuo contenitore. Per non dover attendere indefinitamente, puoi costruire il tuo node-exporter e passare a quello fino all'approvazione della PR.
In effetti, è possibile farlo anche senza un Addon-operator, ma con l'Addon-operator il modulo per installare il node-exporter sarà visibile in un unico repository, il Dockerfile per costruire la tua immagine può essere mantenuto lì stesso, rendendo più facile per tutti i membri del team comprendere cosa sta accadendo… E se ci sono più cluster, diventa più semplice sia testare la tua PR che applicare la nuova versione!
Questa organizzazione dell'aggiornamento dei componenti funziona bene per noi, ma è possibile implementare qualsiasi altro schema adatto — infatti, in questo caso, l'Addon-operator è un semplice file binario..
Conclusione
I principi implementati nell'Addon-operator consentono di costruire un processo trasparente per la creazione, il test, l'installazione e l'aggiornamento delle estensioni nel cluster, simile ai processi di sviluppo delle normali applicazioni.
Le estensioni per l'Addon-operator in formato moduli (Helm-chart + hook) possono essere rese disponibili pubblicamente. Noi, la compagnia Flant, abbiamo in programma di pubblicare durante l'estate i nostri sviluppi in forma di tali estensioni. Unisciti allo sviluppo su GitHub (, ), prova a creare la tua estensione basata su e , attendi notizie su Habr e sul nostro !
P.S.
Leggete anche nel nostro blog:
- «»;
- «».
Fonte: habr.com
