Seguito presentiamo suo fratello maggiore - . Questo è un progetto Open Source che viene utilizzato per installare componenti di sistema in un cluster Kubernetes, che possono essere chiamati componenti aggiuntivi.
Perché qualche aggiunta?
Non è un segreto che Kubernetes non sia un prodotto all-in-one già pronto e per creare un cluster "adulto" avrai bisogno di varie aggiunte. Addon-operator ti aiuterà a installare, configurare e mantenere aggiornati questi componenti aggiuntivi.
La necessità di componenti aggiuntivi nel cluster è descritta in colleghi . In breve, la situazione con Kubernetes al momento è tale che per una semplice installazione "giocare" puoi cavartela con i componenti pronti all'uso, per sviluppatori e test puoi aggiungere Ingress, ma per un'installazione completa, di cui puoi dire "la tua produzione è pronta", devi aggiungerla con una dozzina di componenti aggiuntivi diversi: qualcosa per il monitoraggio, qualcosa per la registrazione, non dimenticare ingresso e certificato-manager, seleziona gruppi di nodi, aggiungi politiche di rete, stagione con le impostazioni di sysctl e pod autoscaler...
Quali sono le specificità del lavorare con loro?
Come dimostra la pratica, la questione non si limita a un'installazione. Per lavorare comodamente con il cluster, i componenti aggiuntivi dovranno essere aggiornati, disabilitati (rimossi dal cluster) e sarà necessario testarne alcuni prima di installarli nel cluster di produzione.
Quindi forse Ansible sarà sufficiente qui? Forse. Ma In generale, i componenti aggiuntivi completi non vivono senza impostazioni. Queste impostazioni possono differire a seconda della variante del cluster (aws, gce, azure, bare-metal, do, ...). Alcune impostazioni non possono essere specificate in anticipo; devono essere ottenute dal cluster. E il cluster non è statico: per alcune impostazioni dovrai monitorare i cambiamenti. E qui manca già Ansible: serve un programma che viva in un cluster, ad es. Operatore Kubernetes.
Quelli che l'hanno provato sul lavoro , diranno che le attività di installazione e aggiornamento dei componenti aggiuntivi e delle impostazioni di monitoraggio possono essere completamente risolte utilizzando per operatore shell. Puoi scrivere uno script che esegua un condizionale kubectl apply e monitorare, ad esempio, ConfigMap, dove verranno archiviate le impostazioni. Questo è approssimativamente ciò che è implementato in addon-operator.
Come è organizzato in Addon-Operator?
Durante la creazione di una nuova soluzione, abbiamo proceduto dai seguenti principi:
- Il programma di installazione del componente aggiuntivo deve supportare configurazione di template e dichiarativa. Non creiamo script magici che installano componenti aggiuntivi. L'operatore del componente aggiuntivo utilizza Helm per installare i componenti aggiuntivi. Per l'installazione è necessario creare un grafico e selezionare i valori che verranno utilizzati per la configurazione.
- Le impostazioni possono essere generare durante l'installazione, loro possono ottenere dal clusterO ricevere aggiornamenti, monitorando le risorse del cluster. Queste operazioni possono essere implementate utilizzando gli hook.
- Le impostazioni possono essere memorizzare in un cluster. Per memorizzare le impostazioni nel cluster, viene creato un ConfigMap/operatore aggiuntivo e l'operatore aggiuntivo monitora le modifiche a questo ConfigMap. L'operatore aggiuntivo fornisce agli hook l'accesso alle impostazioni utilizzando semplici convenzioni.
- L'aggiunta dipende dalle impostazioni. Se le impostazioni sono cambiate, l'operatore del componente aggiuntivo distribuisce il grafico Helm con nuovi valori. Abbiamo chiamato la combinazione del grafico Helm, i valori per esso e gli hook di un modulo (vedi sotto per maggiori dettagli).
- Messa in scena. Non esistono script di rilascio magici. Il meccanismo di aggiornamento è simile a una normale applicazione: raccogli componenti aggiuntivi e operatori aggiuntivi in un'immagine, taggali e distribuiscili.
- Controllo dei risultati. L'operatore aggiuntivo può fornire metriche per Prometheus.
Cos'è il riempimento nell'operatore aggiuntivo?
Un'aggiunta può essere considerata qualsiasi cosa che aggiunga nuove funzioni al cluster. Ad esempio, l'installazione di Ingress è un ottimo esempio di componente aggiuntivo. Può trattarsi di qualsiasi operatore o controller con il proprio CRD: prometheus-operator, cert-manager, kube-controller-manager, ecc. Oppure qualcosa di piccolo, ma più facile da usare, ad esempio secret copier, che copia i segreti del registro in nuovi spazi dei nomi, o sysctl tuner, che configura i parametri sysctl sui nuovi nodi.
Per implementare i componenti aggiuntivi, Addon-operator fornisce diversi concetti:
- Grafico del timone utilizzato per installare vari software nel cluster, ad esempio Prometheus, Grafana, nginx-ingress. Se il componente richiesto ha un grafico Helm, installarlo utilizzando l'operatore aggiuntivo sarà molto semplice.
- Conservazione dei valori. I grafici timone in genere hanno molte impostazioni diverse che possono cambiare nel tempo. L'operatore aggiuntivo supporta la memorizzazione di queste impostazioni e può monitorare le relative modifiche per reinstallare il grafico Helm con nuovi valori.
- Ganci sono file eseguibili che l'operatore Addon esegue sugli eventi e che accedono all'archivio dei valori. L'hook può monitorare le modifiche nel cluster e aggiornare i valori nell'archivio valori. Quelli. Utilizzando gli hook, puoi effettuare il rilevamento per raccogliere valori dal cluster all'avvio o in base a una pianificazione, oppure puoi eseguire il rilevamento continuo, raccogliendo valori dal cluster in base alle modifiche nel cluster.
- modulo è una combinazione di un grafico Helm, un archivio di valori e hook. I moduli possono essere abilitati o disabilitati. Disabilitare un modulo significa eliminare tutte le versioni del grafico Helm. I moduli possono abilitarsi dinamicamente, ad esempio, se tutti i moduli di cui ha bisogno sono abilitati o se il rilevamento ha trovato i parametri necessari negli hook - questo viene fatto utilizzando uno script abilitato ausiliario.
- Ganci globali. Questi sono hook “autonomi”, non sono inclusi nei moduli e hanno accesso a un archivio di valori globali, i cui valori sono disponibili per tutti gli hook nei moduli.
Come funzionano queste parti insieme? Diamo un'occhiata all'immagine dalla documentazione:
Esistono due scenari lavorativi:
- L'hook globale viene attivato da un evento, ad esempio quando una risorsa nel cluster cambia. Questo hook elabora le modifiche e scrive i nuovi valori nell'archivio valori globali. L'operatore del componente aggiuntivo nota che la memoria globale è cambiata e avvia tutti i moduli. Ogni modulo, utilizzando i suoi hook, determina se deve essere abilitato e aggiorna il proprio archivio valori. Se il modulo è abilitato, l'operatore Addon avvia l'installazione del grafico Helm. In questo caso il grafico Helm ha accesso ai valori dalla memoria del modulo e dalla memoria globale.
- Il secondo scenario è più semplice: un hook del modulo viene attivato da un evento e modifica i valori nell'archivio valori del modulo. L'operatore del componente aggiuntivo se ne accorge e avvia il grafico Helm con i valori aggiornati.
L'aggiunta può essere implementata come un singolo hook, o come un grafico Helm, oppure anche come diversi moduli dipendenti - ciò dipende dalla complessità del componente da installare nel cluster e dal livello di flessibilità di configurazione desiderato. Ad esempio, nel repository () esiste un componente aggiuntivo sysctl-tuner, che viene implementato sia come semplice modulo con un hook e un grafico Helm, sia utilizzando l'archivio valori, che consente di aggiungere impostazioni modificando ConfigMap.
Consegna degli aggiornamenti
Qualche parola sull'organizzazione degli aggiornamenti dei componenti installati dall'operatore aggiuntivo.
Per eseguire Addon-operator in un cluster, è necessario costruire un'immagine con aggiunte sotto forma di file di grafici hook e Helm, aggiungi un file binario addon-operator e tutto l'occorrente per i ganci: bash, kubectl, jq, python eccetera. Quindi questa immagine può essere distribuita al cluster come un'applicazione normale e molto probabilmente vorrai organizzare l'uno o l'altro schema di tagging. Se i cluster sono pochi, potrebbe essere adatto lo stesso approccio utilizzato per le applicazioni: nuova release, nuova versione, andare su tutti i cluster e correggere l'immagine dei pod. Tuttavia, nel caso di un'implementazione su un numero significativo di cluster, il concetto di aggiornamento automatico da un canale era più adatto a noi.
Ecco come lo facciamo:
- Un canale è essenzialmente un identificatore che può essere impostato su qualsiasi cosa (ad esempio, dev/stage/ea/stable).
- Il nome del canale è il tag dell'immagine. Quando è necessario implementare aggiornamenti su un canale, una nuova immagine viene assemblata e contrassegnata con il nome del canale.
- Quando viene visualizzata una nuova immagine nel registro, l'operatore aggiuntivo viene riavviato e avviato con la nuova immagine.
Questa non è la migliore pratica, come scritto in . Non è consigliabile farlo, ma stiamo parlando un'applicazione regolare che risiede nello stesso cluster. Nel caso dell'operatore aggiuntivo, un'applicazione è composta da numerose distribuzioni sparse nei cluster e l'aggiornamento automatico aiuta molto e semplifica la vita.
I canali aiutano e nei test: se è presente un cluster ausiliario, è possibile configurarlo sul canale stage e inserire gli aggiornamenti prima di distribuirlo ai canali ea и stable. Se con un cluster sul canale ea si è verificato un errore, è possibile passare a stable, mentre si esamina il problema con questo cluster. Se il cluster viene tolto dal supporto attivo, passa al canale "congelato", ad esempio: freeze-2019-03-20.
Oltre ad aggiornare gli hook e i grafici Helm, potresti aver bisogno aggiornamento e componente di terze parti. Ad esempio, hai notato un bug nell'esportatore di nodi condizionali e hai anche capito come risolverlo. Successivamente, hai aperto il PR e stai aspettando che la nuova versione attraversi tutti i cluster e aumenti la versione dell'immagine. Per non aspettare indefinitamente, puoi creare il tuo esportatore di nodi e passare ad esso prima di accettare il PR.
In generale, questo può essere fatto senza Addon-operator, ma con Addon-operator il modulo per l'installazione di node-exporter sarà visibile in un repository, il Dockerfile per creare la tua immagine può essere conservato proprio lì, diventa più facile per tutti i partecipanti il processo per capire cosa succede... E se ci sono diversi cluster, diventa più semplice testare il tuo PR e lanciare una nuova versione!
Questa organizzazione dell'aggiornamento dei componenti funziona con successo per noi, ma qualsiasi altro schema adatto può essere implementato, dopotutto in questo caso Addon-operator è un semplice file binario.
conclusione
I principi implementati in Addon-operator consentono di creare un processo trasparente per creare, testare, installare e aggiornare i componenti aggiuntivi in un cluster, simile ai processi di sviluppo delle normali applicazioni.
I componenti aggiuntivi per l'operatore aggiuntivo in formato modulo (diagramma Helm + hook) possono essere resi disponibili pubblicamente. Noi, la società Flant, prevediamo di pubblicare i nostri sviluppi sotto forma di tali aggiunte durante l'estate. Partecipa allo sviluppo su GitHub (, ), prova a creare la tua aggiunta basata su и , aspettate notizie su Habré e sul ns !
PS
Leggi anche sul nostro blog:
- «";
- «'.
Fonte: habr.com