Il problema con le applicazioni stateful in Kubernetes
La configurazione, il lancio e l'ulteriore dimensionamento di applicazioni e servizi sono semplici quando si tratta di casi classificati come stateless, ovvero senza stato. senza salvare i dati. È conveniente eseguire tali servizi in Kubernetes, utilizzando le sue API standard, perché tutto avviene “out of the box”: secondo configurazioni standard, senza coinvolgere alcuna specificità o magia.
In poche parole, per lanciare altre cinque copie del backend in PHP/Ruby/Python in un cluster di contenitori, è sufficiente configurare un nuovo server 5 volte e copiare i sorgenti. Poiché sia il codice sorgente che lo script init sono nell'immagine, il ridimensionamento di un'applicazione stateless diventa del tutto elementare. Come sanno bene gli appassionati di contenitori e architettura di microservizi, le difficoltà iniziano con app con stato, cioè. con persistenza dei dati come database e cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ciò vale sia per i software che implementano in modo indipendente un quorum cluster (ad esempio, Percona XtraDB e Cassandra), sia per i software che richiedono utilità di gestione separate (come Redis, MySQL, PostgreSQL...).
Le difficoltà sorgono perché il codice sorgente e l'avvio del servizio non sono più sufficienti: è necessario eseguire alcuni passaggi aggiuntivi. Come minimo, copia i dati e/o unisciti al cluster. Più precisamente, questi servizi richiedono la comprensione di come ridimensionarli, aggiornarli e riconfigurarli correttamente senza perdita di dati o indisponibilità temporanea. Tenere conto di queste esigenze si chiama “conoscenza operativa”.
Operatori CoreOS
Per "programmare" la conoscenza operativa, alla fine dello scorso anno è nato il progetto CoreOS “una nuova classe di software” per la piattaforma Kubernetes - Operatori (dall'inglese “operazione”, cioè “operazione”).
Gli operatori che utilizzano ed estendono le funzionalità principali di Kubernetes (incl. StatefulSet, vedere la differenza di seguito) consentono agli specialisti DevOps di aggiungere conoscenze operative al codice dell'applicazione.
Scopo dell'operatore — fornire all'utente un'API che consenta di gestire più entità applicative con stato in un cluster Kubernetes, senza pensare a cosa c'è dietro (quali dati e cosa farne, quali comandi devono ancora essere eseguiti per mantenere il cluster ). Infatti, l'Operatore è progettato per semplificare il più possibile il lavoro con l'applicazione all'interno del cluster, automatizzando l'esecuzione di compiti operativi che prima dovevano essere risolti manualmente.
Come lavorano gli operatori
ReplicaSets Kubernetes ti consente di specificare il numero desiderato di pod in esecuzione e i controller assicurano che il loro numero venga mantenuto (creando ed eliminando pod). Un operatore funziona in modo simile, aggiungendo una serie di conoscenze operative a una risorsa e a un controller Kubernetes standard che consente di eseguire azioni aggiuntive per supportare il numero richiesto di entità applicative.
In cosa differisce da StatefulSet, progettato per applicazioni che richiedono che il cluster fornisca loro risorse con stato come archiviazione dati o IP statici? Per tali applicazioni, gli operatori possono utilizzare StatefulSet (invece di ReplicaSets) come base, offerta ulteriore automazione: eseguire le azioni necessarie in caso di crash, effettuare backup, aggiornare la configurazione, ecc.
Così, come funziona tutto questo? L'operatore è un demone gestore che:
- si abbona all'API dell'evento in Kubernetes;
- riceve da esso i dati sul sistema (sul suo ReplicaSets, baccelli, Servizi e così via.);
- riceve dati su Risorse di terze parti (vedi esempi sotto);
- reagisce all'apparenza/cambiamento Risorse di terze parti (ad esempio per cambiare la dimensione, cambiare la versione, e così via);
- reagisce ai cambiamenti nello stato del sistema (sul suo ReplicaSets, baccelli, Servizi e così via.);
- il più importante:
- richiede all'API Kubernetes di creare tutto ciò di cui ha bisogno (di nuovo, il proprio ReplicaSets, baccelli, Servizi...),
- esegue qualche magia (per semplificare, puoi pensare che l'Operatore entri nei pod stessi e chiami comandi, ad esempio, per unirsi a un cluster o per aggiornare il formato dei dati durante l'aggiornamento di una versione).
Infatti, come si può vedere dall'immagine, a Kubernetes viene semplicemente aggiunta un'applicazione separata (un normale Distribuzione с Set di repliche), che si chiama Operatore. Vive in un normale baccello (di solito solo uno) e, di regola, è responsabile solo del suo Spazio dei nomi. Questa applicazione operatore implementa la sua API, anche se non direttamente, ma tramite Risorse di terze parti in Kubernetes.
Quindi, dopo aver creato in Spazio dei nomi Operatore, possiamo aggiungerlo Risorse di terze parti.
Esempio per ecc (vedi sotto per i dettagli):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Esempio per Elasticsearch:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Requisiti per gli operatori
CoreOS ha formulato i principali pattern ottenuti dagli ingegneri durante il lavoro sugli Operatori. Nonostante tutti gli Operatori siano individuali (creati per un'applicazione specifica con le proprie caratteristiche ed esigenze), la loro creazione deve essere basata su un tipo di quadro che impone i seguenti requisiti:
- L'installazione deve essere eseguita tramite un unico Distribuzione: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - e non richiedono azioni aggiuntive.
- Quando si installa un operatore in Kubernetes, è necessario creare un nuovo tipo di terze parti (Risorsa di terze parti). Per avviare le istanze dell'applicazione (istanze cluster) e gestirle ulteriormente (aggiornamento delle versioni, ridimensionamento, ecc.), l'utente utilizzerà questa tipologia.
- Quando possibile, dovresti utilizzare le primitive integrate in Kubernetes, come Servizi и ReplicaSetsutilizzare un codice ben testato e comprensibile.
- Richiede la compatibilità con le versioni precedenti degli operatori e il supporto per le versioni precedenti delle risorse create dall'utente.
- Se l'Operatore viene rimosso, l'applicazione stessa dovrebbe continuare a funzionare senza modifiche.
- Gli utenti dovrebbero essere in grado di definire la versione dell'applicazione desiderata e orchestrare gli aggiornamenti della versione dell'applicazione. La mancanza di aggiornamenti software è una fonte comune di problemi operativi e di sicurezza, pertanto gli operatori devono assistere gli utenti in questa materia.
- Gli operatori dovrebbero essere testati con uno strumento come Chaos Monkey, che identifica potenziali guasti nei pod, nelle configurazioni e nella rete.
operatore etcd
Esempio di implementazione dell'operatore - Operatore etcd, il giorno dell'annuncio di questo concetto. La configurazione del cluster etcd può essere complessa a causa della necessità di mantenere il quorum, di riconfigurare l'appartenenza al cluster, creare backup, ecc. Ad esempio, ridimensionare manualmente un cluster etcd significa che è necessario creare un nome DNS per un nuovo membro del cluster, avviare una nuova entità etcd e avvisare il cluster del nuovo membro (Aggiunta del membro etcdctl). Nel caso dell'Operatore, l'utente dovrà solo modificare la dimensione del cluster: tutto il resto avverrà automaticamente.
E poiché anche etcd è stato creato in CoreOS, era abbastanza logico vedere prima il suo Operatore. Come lavora? Logica dell'operatore ecc è determinato da tre componenti:
- Osservare. L'operatore monitora lo stato del cluster utilizzando l'API Kubernetes.
- Analisi. Trova le differenze tra lo stato corrente e quello desiderato (definito dalla configurazione utente).
- Azione. Risolve le differenze rilevate utilizzando le API del servizio etcd e/o Kubernetes.
Per implementare questa logica sono state predisposte delle funzioni nell'Operatore Crea/Distruggi (creazione ed eliminazione dei membri del cluster etcd) e Ridimensiona (modifica del numero dei membri del cluster). La correttezza del suo funzionamento è stata verificata utilizzando un'utilità creata a somiglianza di Chaos Monkey di Netflix, ad es. uccidendo i pod etcd in modo casuale.
Per il pieno funzionamento di etcd, l'Operatore fornisce funzionalità aggiuntive: di riserva (creazione automatica e invisibile agli utenti di copie di backup - nella configurazione è sufficiente determinare quanto spesso crearle e quante archiviare - e successivo ripristino dei dati da esse) e Upgrade (aggiornamento delle installazioni etcd senza tempi di inattività).
Come è lavorare con un Operatore?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
Lo stato attuale di etcd Operator è una versione beta, che richiede Kubernetes 1.5.3+ e etcd 3.0+ per essere eseguito. Il codice sorgente e la documentazione (comprese le istruzioni per l'uso) sono disponibili all'indirizzo .
È stata creata un'altra implementazione di esempio da CoreOS: , ma è ancora in versione alpha (non tutte le funzionalità previste sono state implementate).
Stato e prospettive
Sono trascorsi 5 mesi dall'annuncio degli operatori Kubernetes. Ci sono ancora solo due implementazioni disponibili nel repository ufficiale CoreOS (per etcd e Prometheus). Entrambi non hanno ancora raggiunto la versione stabile, ma i commit vengono rispettati quotidianamente.
Gli sviluppatori immaginano “un futuro in cui gli utenti installeranno Postgres Operator, Cassandra Operator o Redis Operator sui loro cluster Kubernetes e lavoreranno con le entità scalabili di queste applicazioni con la stessa facilità con cui oggi distribuisce repliche di applicazioni web stateless”. Primo Operatori di sviluppatori di terze parti ha davvero iniziato ad apparire:
- da UPMC Enterprises;
- da Crunchy Data (annunciato a fine marzo 2017);
- dagli autori di un sistema di archiviazione dati distribuito basato su Ceph (Rook è in stato alpha);
- da SAP CCloud.
Alla più grande conferenza europea sul software libero FOSDEM, che ha avuto luogo a febbraio 2017 a Bruxelles, Josh Wood di CoreOS ha annunciato gli operatori in (un video è disponibile al link!), che dovrebbe contribuire alla crescita della popolarità di questo concetto nella più ampia comunità Open Source.
PS Grazie per il tuo interesse per l'articolo! Iscriviti al nostro hub, per non perdere nuovi materiali e ricette su DevOps e amministrazione di sistemi GNU/Linux: li pubblicheremo regolarmente!
Fonte: habr.com