A seguito di presentiamo il suo "fratello maggiore" — . Questo è un progetto Open Source utilizzato per installare nel cluster Kubernetes componenti di sistema, che possiamo riassumere con una parola - addon.
Perché mai servono degli addon?
Non è un segreto che Kubernetes non sia un prodotto finito "tutto in uno", e per costruire un cluster "mature" sono necessari diversi addon. L'addon-operator aiuta a installare, configurare e mantenere questi addon sempre aggiornati.
La necessità di componenti aggiuntivi nel cluster è trattata nel colleghi . In breve, la situazione con Kubernetes al momento è tale che per una semplice installazione "per giocare" è possibile 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 decina di addon diversi: qualcosa per il monitoraggio, qualcosa per i log, non dimenticare ingress e cert-manager, riservare gruppi di nodi, aggiungere politiche di rete, accompagnare con impostazioni sysctl e pod autoscaler…
Qual è la specificità nel lavorarci?
Come dimostra la pratica, non si tratta solo di installazione. Per lavorare comodamente con il cluster, gli addon devono essere aggiornati, disattivati (rimossi dal cluster) e alcuni di essi vanno testati prima di essere installati nel cluster di produzione.
Allora, forse qui basta Ansible? Potrebbe essere. Ma addon completi in generale non funzionano senza configurazioni. Queste configurazioni possono variare a seconda della tipologia di cluster (aws, gce, azure, bare-metal, do, …). Alcune impostazioni non possono essere definite a priori — devono essere ottenute dal cluster. E il cluster non è statico: per alcune configurazioni sarà necessario monitorare i cambiamenti. E qui Ansible non basta: serve un programma che viva nel cluster, ovvero un Kubernetes Operator.
Coloro che hanno provato a lavorarci , dicono che le attività di installazione e aggiornamento degli addon e di monitoraggio delle configurazioni possono essere facilmente risolte con per shell-operator. Si può scrivere uno script che esegue una condizione kubectl apply e monitora, ad esempio, ConfigMap, dove saranno memorizzate le configurazioni. Questo è grosso modo ciò che è realizzato in addon-operator.
Come è organizzato in addon-operator?
Creando una nuova soluzione, ci siamo basati sui seguenti principi:
- Il gestore degli addon deve supportare la templating e la configurazione dichiarativa. Non facciamo script magici che installano addon. L'addon-operator utilizza Helm per installare gli addon. Per l'installazione è necessario creare un chart e specificare i valori 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 tramite hook.
- Le impostazioni possono memorizzare 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 accesso alle impostazioni tramite semplici convenzioni.
- L'addon dipende dalle impostazioni. Se le impostazioni cambiano, l'addon-operator distribuisce un chart Helm con nuovi valori. L'aggregazione del chart Helm, dei valori per esso e degli hook la chiamiamo modulo (vedere sotto per ulteriori dettagli).
- Il deploy. Nessuno script di rilascio magico. Il meccanismo di aggiornamento è simile a quello di un'applicazione normale: costruire gli addon e l'addon-operator in un'immagine, etichettare e distribuire.
- Il controllo del risultato. L'addon-operator è in grado di fornire metriche per Prometheus.
Cos'è un addon in addon-operator?
Un addon può essere considerato tutto ciò che aggiunge nuove funzionalità al cluster. Ad esempio, l'installazione di Ingress è un ottimo esempio di addon. Può essere qualsiasi operatore o controller con il proprio CRD: prometheus-operator, cert-manager, kube-controller-manager, ecc. Oppure qualcosa di più piccolo, ma che semplifica l'operatività: ad esempio, un copier di secret che copia i segreti del registry in nuovi spazi dei nomi, o un tuner di sysctl che configura le impostazioni di sysctl sui nuovi nodi.
Per implementare gli addon, l'addon-operator fornisce diverse concettualizzazioni:
- Helm-chart viene utilizzato per installare vari software nel cluster, ad esempio Prometheus, Grafana, nginx-ingress. Se il componente desiderato ha un Helm-chart, sarà molto semplice installarlo tramite l'addon-operator.
- Storage dei valori. Gli Helm-chart di solito hanno molte impostazioni diverse che possono cambiare nel tempo. L'addon-operator supporta la memorizzazione di queste impostazioni e può monitorare le loro modifiche, in modo da reinstallare l'Helm-chart con i nuovi valori.
- Hook — sono file eseguibili che l'Addon-operator avvia in base agli eventi e che accedono allo storage dei valori. Un hook può monitorare le modifiche nel cluster e aggiornare i valori nello storage dei valori. Cioè, con l'uso degli hook, è possibile effettuare il discovery per raccogliere i valori dal cluster all'avvio o su base programmata, oppure è possibile avere un discovery continuo, raccogliendo i valori dal cluster in base alle modifiche nel cluster.
- Modulo — è una combinazione di un Helm chart, dello storage dei valori e degli hook. I moduli possono essere attivati o disattivati. Disattivare un modulo significa rimuovere tutti i rilasci dell'Helm chart. I moduli possono attivare se stessi dinamicamente, ad esempio se sono attivati tutti i moduli necessari o se il discovery negli hook ha trovato i parametri desiderati; questo avviene tramite uno script ausiliario abilitato.
- Hook globali. Sono hook "autonomi", non inclusi nei moduli e hanno accesso allo storage globale dei valori, i cui valori sono disponibili a tutti gli hook nei moduli.
Come funzionano insieme queste parti? Consideriamo l'immagine della documentazione:
Ci sono due scenari di lavoro:
- L'hook globale si attiva in seguito a un evento, ad esempio quando c'è una modifica delle risorse nel cluster. Questo hook gestisce le modifiche e registra i nuovi valori nello storage globale dei valori. L'Addon-operator nota che lo storage globale è cambiato e avvia tutti i moduli. Ogni modulo, attraverso i suoi hook, determina se deve attivarsi e aggiorna il proprio storage dei valori. Se il modulo è attivato, l'Addon-operator avvia l'installazione dell'Helm chart. L'Helm chart ha accesso ai valori dallo storage del modulo e dallo storage globale.
- Il secondo scenario è più semplice: l'hook modulare si attiva in seguito a un evento e modifica i valori nello storage dei valori del modulo. L'Addon-operator lo nota e avvia l'Helm chart con i valori aggiornati.
Un componente può essere implementato come un unico hook autonomo o come un Helm chart, oppure anche come più moduli dipendenti — dipende dalla complessità del componente da installare nel cluster e dal livello di flessibilità delle impostazioni richiesto. Ad esempio, nel repository () c'è un componente sysctl-tuner, implementato sia come un semplice modulo con un hook e l'Helm chart, sia utilizzando lo storage dei valori, il che consente di aggiungere impostazioni tramite la modifica di ConfigMap.
Consegna degli aggiornamenti
Alcune parole sull'organizzazione degli aggiornamenti dei componenti installati da Addon-operator.
Per avviare Addon-operator nel cluster, è necessario creare un'immagine con le estensioni 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, quest'immagine può essere distribuita nel cluster come un'applicazione normale e probabilmente si vorrà organizzare un certo schema di tagging. Se ci sono pochi cluster, può andare bene lo stesso approccio usato con le applicazioni: nuova release, nuova versione, passare a tutti i cluster e aggiornare l'immagine nei Pod. Tuttavia, nel caso di distribuzione su un numero significativo di cluster, ci si aspetta di trovare più appropriata la concezione di auto-aggiornamento dal canale.
Noi lo organizziamo in questo modo:
- Il canale è sostanzialmente un identificatore che può essere impostato a piacere (ad esempio, dev/stage/ea/stable).
- Il nome del canale è il tag dell'immagine. Quando è necessario distribuire gli aggiornamenti nel canale, si crea una nuova immagine e si etichetta con il nome del canale.
- Quando nel registry appare una nuova immagine, Addon-operator viene riavviato e avviato con la nuova immagine.
Non è una best practice, di cui si parla in . Non è consigliabile farlo, ma si tratta di un'applicazione normale, che vive in un singolo cluster. Nel caso di Addon-operator, l'applicazione è un insieme di Deployment distribuiti nei cluster, e l'auto-aggiornamento è di grande aiuto e semplifica molto le cose.
I canali aiutano anche con il testing: se c'è un cluster ausiliario, è possibile configurarlo su un canale stage e provare gli aggiornamenti su di esso prima della distribuzione nei canali ea e stable. Se si verifica un errore con il cluster sul canale ea , è possibile commutarlo su stable, mentre si svolge l'indagine sul problema di questo cluster. Se il cluster viene dismesso dal supporto attivo, viene commutato sul suo canale "congelato" — ad esempio, freeze-2019-03-20.
Oltre agli aggiornamenti degli hook e degli Helm chart, potrebbe essere necessario aggiornare anche un componente di terze parti. Ad esempio, si è notata un'errore nel node-exporter e si è persino pensato a come modificarlo. Successivamente, è stato aperto un PR e si attende una nuova release, per passare a tutti i cluster e aumentare la versione dell'immagine. Per non attendere un tempo indefinito, è possibile creare il proprio node-exporter e passare a quello fino all'accettazione del PR.
In generale, si può fare anche senza l'Addon-operator, ma con l'Addon-operator il modulo per l'installazione di node-exporter sarà in evidenza in un unico repository, il Dockerfile per la creazione della propria immagine può essere tenuto qui, e diventa più semplice per tutti i partecipanti al processo capire cosa sta succedendo... E se ci sono più cluster, diventa più facile sia testare il proprio PR che implementare una nuova versione!
Questa organizzazione dell'aggiornamento dei componenti funziona con successo per noi, ma è possibile implementare qualsiasi altro schema adatto — dopo tutto in questo caso l'Addon-operator è un semplice file binario.
Conclusione
I principi implementati nell'Addon-operator consentono di costruire un processo trasparente di creazione, test, installazione e 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 società Flant, prevediamo di pubblicare durante l'estate i nostri sviluppi sotto forma di tali estensioni. Unisciti allo sviluppo su GitHub (, ), prova a creare la tua estensione basata sui e , aspetta aggiornamenti su Habr e sul nostro !
P.S.
Leggi anche nel nostro blog:
- «»;
- «».
Fonte: habr.com
