De Problem mat stateful Uwendungen an Kubernetes
Konfiguratioun, Start a weider Skaléieren vun Uwendungen a Servicer ass einfach wann et ëm Fäll geet, déi als stateless klasséiert sinn, d.h. ouni Daten ze späicheren. Et ass bequem fir sou Servicer a Kubernetes ze lafen, mat senge Standard APIen, well alles geschitt "aus der Këscht": no Standardkonfiguratiounen, ouni Spezifizitéiten oder Magie involvéiert.
Einfach gesot, fir fënnef méi Exemplare vum Backend am PHP / Ruby / Python an engem Cluster vu Container ze lancéieren, musst Dir nëmmen en neie Server 5 Mol opsetzen an d'Quellen kopéieren. Well souwuel de Quellcode wéi och den Init Skript am Bild sinn, gëtt d'Skaléierung vun enger stateless Applikatioun komplett elementar. Wéi d'Fans vu Container a Mikroservicearchitektur gutt wëssen, fänkt d'Schwieregkeet un stateful Apps, d.h. mat Donnéeën Persistenz wéi Datenbanken a Cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra ...). Dëst gëllt souwuel fir Software déi onofhängeg e Quorumcluster implementéiert (zum Beispill Percona XtraDB a Cassandra), a Software déi getrennte Management Utilities erfuerdert (wéi Redis, MySQL, PostgreSQL ...).
Schwieregkeeten entstinn well de Quellcode an de Start vum Service net méi genuch sinn - Dir musst e puer méi Schrëtt maachen. Op d'mannst, kopéiert d'Donnéeën an / oder gitt an de Cluster. Méi präzis erfuerderen dës Servicer e Verständnis wéi een se richteg skaléieren, aktualiséieren an nei konfiguréieren ouni Datenverloscht oder temporär Onverfügbarkeet. Dës Bedierfnesser berücksichtegen gëtt "operationell Wëssen" genannt.
CoreOS Opérateuren
Fir operationell Wëssen ze "programméieren", Enn d'lescht Joer de CoreOS Projet "eng nei Klass vu Software" fir d'Kubernetes Plattform - Bedreiwer (vum englesche "Operatioun", dh "Operatioun").
Operateuren déi d'Kärfäegkeete vu Kubernetes benotzen an ausdehnen (inkl. StatefulSets, kuckt den Ënnerscheed hei drënner) erlaben DevOps Spezialisten operationell Wëssen un d'Applikatiounscode ze addéieren.
Bedreiwer Zweck - liwwert de Benotzer eng API déi Iech erlaabt verschidde statesch Applikatiounsentitéiten an engem Kubernetes Cluster ze verwalten, ouni ze denken wat ënner der Hood ass (wat fir Donnéeën a wat mat deem ze maachen, wéi eng Befehle mussen nach ausgefouert ginn fir de Cluster z'erhalen ). Tatsächlech ass de Bedreiwer entwéckelt fir d'Aarbecht mat der Applikatioun am Cluster sou vill wéi méiglech ze vereinfachen, d'Ausféierung vun operationellen Aufgaben ze automatiséieren, déi virdru manuell geléist goufen.
Wéi Opérateuren Aarbecht
ReplicaSets Kubernetes erlaabt Iech déi gewënscht Zuel vu Lafen Pods ze spezifizéieren, a Controller suergen datt hir Zuel erhale bleift (duerch Schafung a Läsch Pods). En Operator funktionnéiert op eng ähnlech Manéier, bäidréit eng Rei vun operationell Wëssen un eng Standard Kubernetes Ressource a Controller, déi Iech erlaabt zousätzlech Aktiounen auszeféieren fir déi erfuerderlech Unzuel vun Applikatiounsentitéiten z'ënnerstëtzen.
Wéi ass dat anescht wéi StatefulSets, entworf fir Applikatiounen, déi de Cluster erfuerderen fir se mat statesch Ressourcen wéi Datelagerung oder statesch IPs ze bidden? Fir esou Uwendungen kënnen d'Operateuren benotzen StatefulSets (amplaz ReplicaSets) als Basis, Offer zousätzlech Automatisatioun: Maacht déi néideg Aktiounen am Fall vun Crashen, maacht Backups, aktualiséieren d'Konfiguratioun, asw.
An dofir, wéi funktionéiert dat alles? De Bedreiwer ass e Manager Daemon deen:
- abonnéiert op den Event API zu Kubernetes;
- kritt dovunner Daten iwwer de System (iwwer seng ReplicaSets, pods, Servicer a sou weider.);
- kritt Donnéeën iwwer Drëtt Partei Ressourcen (kuckt Beispiller hei ënnen);
- reagéiert op Erscheinung / Ännerung Drëtt Partei Ressourcen (zum Beispill, fir d'Gréisst z'änneren, d'Versioun z'änneren, a sou weider);
- reagéiert op Ännerungen am Zoustand vum System (iwwer seng ReplicaSets, pods, Servicer a sou weider.);
- déi wichtegst:
- rifft d'Kubernetes API op fir alles ze kreéieren wat se brauch (erëm seng eegen ReplicaSets, pods, Servicer...),
- mécht e puer Magie (fir ze vereinfachen, Dir kënnt denken datt de Bedreiwer an d'Pods selwer geet an d'Befehle rifft, zum Beispill fir e Stärekoup matzemaachen oder d'Dateformat ze upgrade wann Dir eng Versioun aktualiséiert).
Tatsächlech, wéi aus der Foto gesi ka ginn, gëtt eng separat Applikatioun einfach op Kubernetes (e regelméisseg Détachement с ReplicaSet), deen den Operateur genannt gëtt. Et lieft an engem gewéinleche Pod (normalerweis nëmmen een) an ass normalerweis nëmme verantwortlech fir seng Nummraum. Dës Bedreiwer Applikatioun implementéiert seng API - obwuel net direkt, awer duerch Drëtt Partei Ressourcen zu Kubernetes.
Also, nodeems mir erstallt hunn Nummraum Bedreiwer, mir kënnen derbäi Drëtt Partei Ressourcen.
Beispill fir etcd (kuckt hei ënnen fir Detailer):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Beispill fir 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
Ufuerderunge fir Opérateuren
CoreOS formuléiert d'Haaptmuster, déi vun Ingenieuren kritt goufen, während se un Operatoren geschafft hunn. Trotz der Tatsaach, datt all Opérateuren individuell sinn (geschaf fir eng spezifesch Applikatioun mat hiren eegene Charakteristiken a Besoinen), hir Kreatioun muss op eng Zort Kader baséiert ginn, datt déi folgend Ufuerderunge setzt:
- Installatioun muss duerch eng eenzeg gemaach ginn Détachement: kubectl schafen -f SOME_OPERATOR_URL/deployment.yaml - a verlaangen keng zousätzlech Aktiounen.
- Wann Dir en Operator a Kubernetes installéiert, muss en neien Drëtt-Partei-Typ erstallt ginn (ThirdPartyResource). Fir Applikatiounsinstanzen (Clusterinstanzen) ze starten an se weider ze verwalten (Versiounen aktualiséieren, d'Gréisst änneren, asw.), benotzt de Benotzer dës Zort.
- Wann ëmmer méiglech, sollt Dir d'Primitiven benotzen, déi a Kubernetes agebaut sinn, wéi z Servicer и ReplicaSetsgutt getest a verständlech Code ze benotzen.
- Erfuerdert Réckkompatibilitéit vun den Opérateuren an Ënnerstëtzung fir eeler Versioune vu Benotzer erstallt Ressourcen.
- Wann de Bedreiwer geläscht gëtt, soll d'Applikatioun selwer weider ouni Ännerungen funktionnéieren.
- D'Benotzer solle fäeg sinn déi gewënschte Applikatiounsversioun ze definéieren an d'Applikatiounsversionupdates z'orchestréieren. Mangel u Softwareupdates ass eng gemeinsam Quell vun Operatiouns- a Sécherheetsproblemer, sou datt d'Bedreiwer d'Benotzer an dëser Matière mussen hëllefen.
- D'Operateure solle mat engem Tool wéi Chaos Monkey getest ginn, wat potenziell Feeler an Pods, Konfiguratiounen an dem Netz identifizéiert.
etcd Bedreiwer
Bedreiwer Ëmsetzung Beispill - etcd Bedreiwer, um Dag vun der Ukënnegung vun dësem Konzept. D'etcd Clusterkonfiguratioun kann komplex sinn wéinst der Bedierfnes fir de Quorum z'erhalen, d'Bedierfnes fir Cluster Memberschaft nei ze konfiguréieren, Backups erstellen, etc. Zum Beispill, manuell Skala vun engem etcd Cluster bedeit datt Dir en DNS Numm fir en neie Cluster Member erstellen musst, eng nei etcd Entitéit starten an de Cluster iwwer den neie Member alarméieren (etcdctl Member addéieren). Am Fall vum Operator brauch de Benotzer nëmmen d'Clustergréisst z'änneren - alles anescht geschitt automatesch.
A well etcd och am CoreOS erstallt gouf, war et ganz logesch fir säin Operator als éischt ze gesinn. Wéi funktionéiert hien? Operator Logik etc ass vun dräi Komponente bestëmmt:
- Observéieren. De Bedreiwer iwwerwaacht den Zoustand vum Cluster mat der Kubernetes API.
- Analyse. Fannt Differenzen tëscht dem aktuelle Status an dem gewënschten (definéiert vun der Benotzerkonfiguratioun).
- Aktioun. Léisst entdeckt Differenzen mat der etcd an / oder Kubernetes Service APIs.
Fir dës Logik ëmzesetzen, goufen Funktiounen am Operator virbereet Schafen / Zerstéieren (Erstellen an läschen etcd Cluster Memberen) an Änneren (Ännerung vun der Zuel vun de Cluster Memberen). D'Korrektheet vu senger Operatioun gouf gepréift mat engem Utility erstallt an der Ähnlechkeet vum Chaos Monkey vun Netflix, d.h. ëmbréngen etcd pods zoufälleg.
Fir voll Operatioun vun etcd, bitt de Bedreiwer zousätzlech Funktiounen: Backup (automatesch an onsichtbar fir d'Benotzer Schafung vu Backupkopien - an der Konfiguratioun ass et genuch fir ze bestëmmen wéi dacks se se maachen a wéi vill ze späicheren - a spéider Restauratioun vun Daten aus hinnen) an Aktualiséierung (Aktualiséierung etcd Installatiounen ouni Ausdauer).
Wéi gesäit mat engem Operator schaffen aus?
$ 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 aktuelle Status vum etcd Operator ass eng Beta Versioun, déi Kubernetes 1.5.3+ an etcd 3.0+ erfuerdert fir ze lafen. Quelltext an Dokumentatioun (dorënner Uweisunge fir benotzen) sinn op .
En anert Beispill Implementatioun vu CoreOS gouf erstallt - , awer et ass nach ëmmer an der Alpha Versioun (net all geplangte Funktiounen goufen ëmgesat).
Status an Perspektiven
5 Méint sinn zënter der Ukënnegung vu Kubernetes Operators vergaangen. Et sinn nach ëmmer nëmmen zwou Implementatiounen verfügbar am offiziellen CoreOS Repository (fir etcd a Prometheus). Béid hunn hir stabil Versiounen nach net erreecht, awer Verpflichtungen ginn all Dag observéiert.
D'Entwéckler virstellen "eng Zukunft an där d'Benotzer Postgres Operators, Cassandra Operators oder Redis Operators op hire Kubernetes Cluster installéieren a mat de skalierbare Entitéite vun dësen Uwendungen esou einfach schaffen wéi d'Deployment vun Repliken vun stateless Web Uwendungen ass haut." Éischten Opérateuren vun Drëttubidder Entwéckler wierklech ugefaang ze erschéngen:
- vun UPMC Enterprises;
- aus Crunchy Data (Enn Mäerz 2017 ugekënnegt);
- vun den Auteuren vun engem verdeelt Datelagerungssystem baséiert op Ceph (Rook ass am Alpha-Status);
- aus SAP CCloud.
Op der gréisster europäescher gratis Software Konferenz FOSDEM, déi am Februar 2017 zu Bréissel stattfonnt huet, huet de Josh Wood vu CoreOS d'Operateuren an (e Video ass um Link verfügbar!), Wat zum Wuesstum vun der Popularitéit vun dësem Konzept an der breeder Open Source Gemeinschaft bäidroe soll.
PS Merci fir Ären Interessi am Artikel! Abonnéiert Iech op eisem Hub, fir net nei Materialien a Rezepter op DevOps a GNU/Linux Systemverwaltung ze verpassen - mir publizéieren se regelméisseg!
Source: will.com