Het probleem met stateful applicaties in Kubernetes
Configuratie, lancering en verdere schaalvergroting van applicaties en diensten is eenvoudig als het gaat om gevallen die als staatloos zijn geclassificeerd, d.w.z. zonder gegevens op te slaan. Het is handig om dergelijke diensten in Kubernetes uit te voeren, met behulp van de standaard API’s, omdat alles “out of the box” gebeurt: volgens standaardconfiguraties, zonder dat er bijzonderheden of magie bij betrokken zijn.
Simpel gezegd: om nog vijf exemplaren van de backend in PHP/Ruby/Python in een cluster van containers te starten, hoeft u slechts vijf keer een nieuwe server in te stellen en de bronnen te kopiëren. Omdat zowel de broncode als het init-script in de afbeelding staan, wordt het schalen van een staatloze applicatie volledig elementair. Zoals fans van containers en microservice-architectuur goed weten, begint de moeilijkheid al met stateful apps, d.w.z. met gegevenspersistentie zoals databases en caches (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Dit geldt voor zowel software die zelfstandig een quorumcluster implementeert (bijvoorbeeld Percona XtraDB en Cassandra), als software waarvoor aparte beheerhulpprogramma's nodig zijn (zoals Redis, MySQL, PostgreSQL...).
Er ontstaan moeilijkheden omdat de broncode en het starten van de service niet langer voldoende zijn - u moet nog een aantal stappen uitvoeren. Kopieer minimaal de gegevens en/of sluit u aan bij het cluster. Om preciezer te zijn: deze services vereisen inzicht in de manier waarop ze op de juiste manier kunnen worden geschaald, bijgewerkt en opnieuw geconfigureerd zonder gegevensverlies of tijdelijke onbeschikbaarheid. Het rekening houden met deze behoeften wordt ‘operationele kennis’ genoemd.
CoreOS-operators
Om operationele kennis te ‘programmeren’ startte eind vorig jaar het CoreOS-project “een nieuwe klasse software” voor het Kubernetes-platform - Operators (van het Engelse “operation”, d.w.z. “operation”).
Operators die de kernmogelijkheden van Kubernetes gebruiken en uitbreiden (incl. StatefulSets(zie het verschil hieronder) stellen DevOps-specialisten in staat operationele kennis aan applicatiecode toe te voegen.
Doel van de exploitant — de gebruiker voorzien van een API waarmee je meerdere stateful applicatie-entiteiten in een Kubernetes-cluster kunt beheren, zonder na te denken over wat er onder de motorkap zit (welke gegevens en wat ermee te doen, welke opdrachten er nog moeten worden uitgevoerd om het cluster te onderhouden ). Sterker nog, de Operator is ontworpen om het werk met de applicatie binnen het cluster zoveel mogelijk te vereenvoudigen, waardoor de uitvoering van operationele taken die voorheen handmatig moesten worden opgelost, wordt geautomatiseerd.
Hoe operators werken
ReplicaSets Met Kubernetes kunt u het gewenste aantal actieve pods opgeven, en controllers zorgen ervoor dat hun aantal behouden blijft (door pods te maken en te verwijderen). Een Operator werkt op een vergelijkbare manier en voegt een set operationele kennis toe aan een standaard Kubernetes-resource en -controller waarmee u aanvullende acties kunt uitvoeren om het vereiste aantal applicatie-entiteiten te ondersteunen.
Hoe verschilt dit van StatefulSets, ontworpen voor toepassingen waarbij het cluster stateful bronnen moet leveren, zoals gegevensopslag of statische IP's? Voor dergelijke toepassingen kunnen operators gebruik maken van StatefulSets (in plaats van ReplicaSets) als basis, aanbieden extra automatisering: voer de nodige acties uit bij crashes, maak back-ups, update de configuratie, enz.
aldus hoe werkt dit allemaal? De operator is een managerdaemon die:
- abonneert zich op de gebeurtenis-API in Kubernetes;
- ontvangt van hem gegevens over het systeem (over zijn ReplicaSets, Pods, Diensten enzovoort.);
- ontvangt gegevens over Bronnen van derden (zie voorbeelden hieronder);
- reageert op uiterlijk/verandering Bronnen van derden (bijvoorbeeld om de grootte te wijzigen, de versie te wijzigen, enzovoort);
- reageert op veranderingen in de toestand van het systeem (over zijn ReplicaSets, Pods, Diensten enzovoort.);
- het belangrijkste:
- doet een beroep op de Kubernetes API om alles te creëren wat het nodig heeft (opnieuw zijn eigen API). ReplicaSets, Pods, Diensten...),
- voert wat magie uit (ter vereenvoudiging kun je bedenken dat de Operator zelf naar de pods gaat en opdrachten oproept, bijvoorbeeld om lid te worden van een cluster of om het gegevensformaat te upgraden bij het updaten van een versie).
In feite wordt, zoals op de afbeelding te zien is, eenvoudigweg een aparte applicatie aan Kubernetes toegevoegd (een reguliere Deployment с ReplicaSet), die de Operator wordt genoemd. Hij leeft in een gewone groep (meestal slechts één) en is in de regel alleen verantwoordelijk voor zijn omgeving namespace. Deze operatorapplicatie implementeert zijn API - hoewel niet rechtstreeks, maar via Bronnen van derden in Kubernetes.
Dus nadat we het hebben gecreëerd namespace Operator, we kunnen er iets aan toevoegen Bronnen van derden.
Voorbeeld voor enz (zie hieronder voor details):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Voorbeeld voor 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
Vereisten voor operators
CoreOS formuleerde de belangrijkste patronen die ingenieurs verkregen tijdens het werken aan Operators. Ondanks het feit dat alle operators individueel zijn (gemaakt voor een specifieke toepassing met zijn eigen kenmerken en behoeften), moet hun creatie gebaseerd zijn op een soort raamwerk dat de volgende vereisten oplegt:
- De installatie moet via een enkele worden uitgevoerd Deployment: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - en vereisen geen aanvullende acties.
- Bij het installeren van een Operator in Kubernetes moet er een nieuw type van derden worden aangemaakt (Bron van derden). Om applicatie-instanties (clusterinstanties) te starten en verder te beheren (versies bijwerken, grootte wijzigen, enz.), zal de gebruiker dit type gebruiken.
- Waar mogelijk moet u de primitieven gebruiken die in Kubernetes zijn ingebouwd, zoals Diensten и ReplicaSetsom goed geteste en begrijpelijke code te gebruiken.
- Vereist achterwaartse compatibiliteit van operators en ondersteuning voor oudere versies van door de gebruiker gemaakte bronnen.
- Als de Operator wordt verwijderd, zou de applicatie zelf zonder wijzigingen moeten blijven functioneren.
- Gebruikers moeten de gewenste applicatieversie kunnen definiëren en updates van applicatieversies kunnen organiseren. Het ontbreken van software-updates is een veel voorkomende bron van operationele en beveiligingsproblemen, dus operators moeten gebruikers hierbij helpen.
- Operators moeten worden getest met een tool als Chaos Monkey, die potentiële fouten in pods, configuraties en het netwerk identificeert.
etcd-operator
Operator-implementatievoorbeeld - etcd-operator, op de dag van de aankondiging van dit concept. De etcd-clusterconfiguratie kan complex zijn vanwege de noodzaak om het quorum te behouden, de noodzaak om het clusterlidmaatschap opnieuw te configureren, back-ups te maken, enz. Het handmatig schalen van een etcd-cluster betekent bijvoorbeeld dat u een DNS-naam moet maken voor een nieuw clusterlid, een nieuwe etcd-entiteit moet starten en het cluster moet waarschuwen voor het nieuwe lid (etcdctl lid toevoegen). In het geval van de Operator hoeft de gebruiker alleen de clustergrootte te wijzigen; al het andere gebeurt automatisch.
En aangezien etcd ook in CoreOS werd gemaakt, was het heel logisch dat de Operator als eerste verscheen. Hoe werkt hij? Operatorlogica enz wordt bepaald door drie componenten:
- Observeer. De operator bewaakt de status van het cluster met behulp van de Kubernetes API.
- Analyse. Vindt verschillen tussen de huidige status en de gewenste status (gedefinieerd door de gebruikersconfiguratie).
- Actie. Lost gedetecteerde verschillen op met behulp van de etcd- en/of Kubernetes-service-API's.
Om deze logica te implementeren zijn er functies voorbereid in de Operator Creëren/vernietigen (etcd-clusterleden maken en verwijderen) en resize (verandering in het aantal clusterleden). De juistheid van de werking ervan werd gecontroleerd met behulp van een hulpprogramma dat is gemaakt naar de gelijkenis van Chaos Monkey van Netflix, d.w.z. etcd-pods willekeurig doden.
Voor volledige werking van etcd biedt de Operator extra functies: backup (automatisch en onzichtbaar voor gebruikers, het maken van back-upkopieën - in de configuratie is het voldoende om te bepalen hoe vaak ze moeten worden gemaakt en hoeveel ze moeten worden opgeslagen - en vervolgens de gegevens ervan te herstellen) en Upgrade (etcd-installaties updaten zonder downtime).
Hoe ziet het werken met een Operator eruit?
$ 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
De huidige status van etcd Operator is een bètaversie, waarvoor Kubernetes 1.5.3+ en etcd 3.0+ nodig zijn. Broncode en documentatie (inclusief gebruiksaanwijzingen) zijn beschikbaar op .
Er is nog een voorbeeldimplementatie van CoreOS gemaakt - , maar het bevindt zich nog steeds in de alfaversie (niet alle geplande functies zijn geïmplementeerd).
Status en vooruitzichten
Er zijn vijf maanden verstreken sinds de aankondiging van Kubernetes Operators. Er zijn nog steeds slechts twee implementaties beschikbaar in de officiële CoreOS-repository (voor etcd en Prometheus). Beide hebben hun stabiele versie nog niet bereikt, maar commits worden dagelijks waargenomen.
De ontwikkelaars voorzien “een toekomst waarin gebruikers Postgres Operators, Cassandra Operators of Redis Operators op hun Kubernetes-clusters installeren en net zo gemakkelijk met de schaalbare entiteiten van deze applicaties werken als het implementeren van replica’s van staatloze webapplicaties vandaag de dag.” Eerst Operators van externe ontwikkelaars begon echt te verschijnen:
- van UPMC Enterprises;
- van Crunchy Data (aangekondigd eind maart 2017);
- van de auteurs van een gedistribueerd gegevensopslagsysteem gebaseerd op Ceph (Rook bevindt zich in alpha-status);
- van SAP CCloud.
Op de grootste Europese vrije softwareconferentie FOSDEM, die in februari 2017 in Brussel plaatsvond, kondigde Josh Wood van CoreOS Operators aan in (een video is beschikbaar via de link!), wat zou moeten bijdragen aan de groei van de populariteit van dit concept in de bredere Open Source-gemeenschap.
PS Bedankt voor je interesse in het artikel! Abonneer u op onze hub, om geen nieuwe materialen en recepten over DevOps en GNU/Linux systeembeheer te missen - we zullen ze regelmatig publiceren!
Bron: www.habr.com