Problemet med stateful applikationer i Kubernetes
Konfiguration, lansering och ytterligare skalning av applikationer och tjänster är enkelt när det gäller fall som klassas som tillståndslösa, d.v.s. utan att spara data. Det är bekvämt att köra sådana tjänster i Kubernetes, med hjälp av dess standard-API:er, eftersom allt händer utanför lådan: enligt standardkonfigurationer, utan att involvera några detaljer eller magi.
Enkelt uttryckt, för att lansera ytterligare fem kopior av backend i PHP/Ruby/Python i ett kluster av behållare behöver du bara konfigurera en ny server 5 gånger och kopiera källorna. Eftersom både källkoden och init-skriptet finns i bilden, blir det helt elementärt att skala en tillståndslös applikation. Som fans av containrar och mikroservicearkitektur väl vet börjar svårigheten med statliga appar, dvs. med databeständighet som databaser och cachar (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Detta gäller både programvara som oberoende implementerar ett kvorumkluster (till exempel Percona XtraDB och Cassandra), och programvara som kräver separata hanteringsverktyg (som Redis, MySQL, PostgreSQL...).
Svårigheter uppstår eftersom källkoden och lanseringen av tjänsten inte längre räcker - du måste utföra några fler steg. Åtminstone kopiera data och/eller gå med i klustret. Mer exakt kräver dessa tjänster en förståelse för hur man korrekt skalar, uppdaterar och omkonfigurerar dem utan dataförlust eller tillfällig otillgänglighet. Att ta hänsyn till dessa behov kallas för "operativ kunskap".
CoreOS-operatörer
För att "programmera" operativ kunskap, i slutet av förra året CoreOS-projektet "en ny klass av programvara" för Kubernetes-plattformen - Operatörer (från engelska "operation", dvs. "operation").
Operatörer som använder och utökar kärnfunktionerna i Kubernetes (inkl. StatefulSets, se skillnaden nedan) tillåter DevOps-specialister att lägga till operativ kunskap till applikationskoden.
Operatörens syfte — förse användaren med ett API som låter dig hantera flera statistiska applikationsenheter i ett Kubernetes-kluster, utan att tänka på vad som finns under huven (vilka data och vad man ska göra med den, vilka kommandon som fortfarande behöver köras för att underhålla klustret ). Faktum är att Operatören är designad för att förenkla arbetet med applikationen inom klustret så mycket som möjligt, och automatisera utförandet av operativa uppgifter som tidigare behövt lösas manuellt.
Hur operatörer fungerar
ReplicaSets Kubernetes låter dig ange önskat antal aktiva pods, och kontroller ser till att deras antal bibehålls (genom att skapa och ta bort pods). En operatör fungerar på ett liknande sätt och lägger till en uppsättning operativ kunskap till en standard Kubernetes-resurs och styrenhet som låter dig utföra ytterligare åtgärder för att stödja det antal applikationsenheter som krävs.
Hur skiljer sig detta från StatefulSets, designad för applikationer som kräver att klustret förser dem med tillståndsfulla resurser som datalagring eller statiska IP-adresser? För sådana applikationer kan operatörer använda StatefulSets (istället för ReplicaSets) som grund, erbjuda ytterligare automatisering: utför nödvändiga åtgärder vid kraschar, gör säkerhetskopior, uppdatera konfigurationen etc.
Så, hur fungerar allt detta? Operatören är en managerdemon som:
- prenumererar på event API i Kubernetes;
- tar emot data från det om systemet (om dess ReplicaSets, Pods, Tjänster och så vidare.);
- får uppgifter om Tredje parts resurser (se exempel nedan);
- reagerar på utseende/förändring Tredje parts resurser (till exempel för att ändra storlek, ändra version och så vidare);
- reagerar på förändringar i systemets tillstånd (om dess ReplicaSets, Pods, Tjänster och så vidare.);
- det viktigaste:
- uppmanar Kubernetes API att skapa allt det behöver (igen, sitt eget ReplicaSets, Pods, Tjänster...),
- utför lite magi (för att förenkla kan du tro att operatören går in i själva poddarna och anropar kommandon, till exempel för att gå med i ett kluster eller för att uppgradera dataformatet vid uppdatering av en version).
I själva verket, som framgår av bilden, läggs en separat applikation helt enkelt till Kubernetes (en vanlig konfiguration с ReplicaSet), som kallas operatören. Den lever i en vanlig pod (vanligtvis bara en) och är i regel bara ansvarig för sin namespace. Denna operatörsapplikation implementerar sitt API - dock inte direkt, utan genom Tredje parts resurser i Kubernetes.
Alltså efter att vi har skapat in namespace Operatör, vi kan lägga till det Tredje parts resurser.
Exempel för etcd (se nedan för detaljer):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Exempel för 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
Krav på operatörer
CoreOS formulerade de huvudsakliga mönstren som ingenjörer fick när de arbetade med operatörer. Trots det faktum att alla operatörer är individuella (skapade för en specifik applikation med sina egna egenskaper och behov), måste deras skapande baseras på ett slags ramverk som ställer följande krav:
- Installation måste göras genom en enkel konfiguration: kubectl skapa -f SOME_OPERATOR_URL/deployment.yaml - och kräver inga ytterligare åtgärder.
- När du installerar en operatör i Kubernetes måste en ny tredjepartstyp skapas (ThirdPartyResource). För att starta applikationsinstanser (klusterinstanser) och ytterligare hantera dem (uppdatering av versioner, ändra storlek, etc.), kommer användaren att använda denna typ.
- När det är möjligt bör du använda de primitiver som är inbyggda i Kubernetes, som t.ex Tjänster и ReplicaSetsatt använda väl beprövad och begriplig kod.
- Kräver bakåtkompatibilitet av operatörer och stöd för äldre versioner av användarskapade resurser.
- Om operatören tas bort ska själva applikationen fortsätta att fungera utan ändringar.
- Användare bör kunna definiera den önskade applikationsversionen och organisera uppdateringar av applikationsversionen. Brist på mjukvaruuppdateringar är en vanlig källa till drifts- och säkerhetsproblem, så operatörer måste hjälpa användarna i denna fråga.
- Operatörer bör testas med ett verktyg som Chaos Monkey, som identifierar potentiella fel i pods, konfigurationer och nätverket.
etcd Operatör
Operatörsimplementeringsexempel - etcd Operatör, dagen för tillkännagivandet av detta koncept. Etcd-klusterkonfigurationen kan vara komplex på grund av behovet av att upprätthålla kvorum, behovet av att omkonfigurera klustermedlemskap, skapa säkerhetskopior, etc. Att manuellt skala ett etcd-kluster innebär till exempel att du måste skapa ett DNS-namn för en ny klustermedlem, starta en ny etcd-entitet och varna klustret om den nya medlemmen (etcdctl medlem add). När det gäller operatören behöver användaren bara ändra klusterstorleken - allt annat kommer att ske automatiskt.
Och eftersom etcd också skapades i CoreOS var det ganska logiskt att se dess operatör dyka upp först. Hur fungerar han? Operatörslogik etcd bestäms av tre komponenter:
- Observera. Operatören övervakar klustrets tillstånd med hjälp av Kubernetes API.
- Analys. Hittar skillnader mellan den aktuella statusen och den önskade (definierad av användarkonfigurationen).
- Handling. Löser upptäckta skillnader med hjälp av etcd och/eller Kubernetes tjänst API:er.
För att implementera denna logik har funktioner förberetts i Operatören Skapa/Förstör (skapa och ta bort etcd-klustermedlemmar) och Ändra storlek (ändring av antalet klustermedlemmar). Riktigheten av dess funktion verifierades med hjälp av ett verktyg skapat i likhet med Chaos Monkey från Netflix, dvs. döda etcd-skidor slumpmässigt.
För full drift av etcd tillhandahåller operatören ytterligare funktioner: säkerhetskopiering (automatiskt och osynligt för användarna att skapa säkerhetskopior - i konfigurationen räcker det för att bestämma hur ofta de ska göras och hur många som ska lagras - och efterföljande återställning av data från dem) och Uppgradera (uppdatering etcd installationer utan driftstopp).
Hur ser det ut att arbeta med en operatör?
$ 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
Den aktuella statusen för etcd Operator är en betaversion som kräver Kubernetes 1.5.3+ och etcd 3.0+ för att köras. Källkod och dokumentation (inklusive bruksanvisning) finns på .
Ett annat exempelimplementering från CoreOS har skapats - , men det är fortfarande i alfaversion (inte alla planerade funktioner har implementerats).
Status och framtidsutsikter
5 månader har gått sedan tillkännagivandet av Kubernetes Operators. Det finns fortfarande bara två implementeringar tillgängliga i det officiella CoreOS-förvaret (för etcd och Prometheus). Båda har ännu inte nått sina stabila versioner, men commits observeras dagligen.
Utvecklarna föreställer sig "en framtid där användare installerar Postgres Operators, Cassandra Operators eller Redis Operators på sina Kubernetes-kluster och arbetar med de skalbara enheterna i dessa applikationer lika enkelt som att distribuera repliker av tillståndslösa webbapplikationer är idag." Först Operatörer från tredjepartsutvecklare började verkligen dyka upp:
- från UPMC Enterprises;
- från Crunchy Data (tillkännagiven i slutet av mars 2017);
- från författarna till ett distribuerat datalagringssystem baserat på Ceph (Rook är i alfastatus);
- från SAP CCloud.
Vid den största europeiska friprogramvarukonferensen FOSDEM, som ägde rum i februari 2017 i Bryssel, tillkännagav Josh Wood från CoreOS Operatörer i (en video finns tillgänglig på länken!), vilket borde bidra till att detta koncept ökar i popularitet i den bredare öppen källkodsgemenskapen.
PS Tack för ditt intresse för artikeln! Prenumerera på vårt nav, för att inte missa nytt material och recept på DevOps och GNU/Linux systemadministration - vi kommer att publicera dem regelbundet!
Källa: will.com