Problemet med stateful applikationer i Kubernetes
Konfiguration, lancering og yderligere skalering af applikationer og tjenester er let, når det kommer til sager, der er klassificeret som statsløse, dvs. uden at gemme data. Det er praktisk at køre sådanne tjenester i Kubernetes ved hjælp af dets standard API'er, fordi alt sker "ud af boksen": i henhold til standardkonfigurationer uden at involvere nogen detaljer eller magi.
Kort sagt, for at lancere yderligere fem kopier af backend i PHP/Ruby/Python i en klynge af containere, behøver du kun at oprette en ny server 5 gange og kopiere kilderne. Da både kildekoden og init-scriptet er i billedet, bliver skalering af en statsløs applikation fuldstændig elementær. Som fans af containere og mikroservicearkitektur godt ved, begynder vanskeligheden med statelige apps, dvs. med datapersistens såsom databaser og caches (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Dette gælder både software, der selvstændigt implementerer en kvorumklynge (for eksempel Percona XtraDB og Cassandra), og software, der kræver separate administrationsværktøjer (såsom Redis, MySQL, PostgreSQL...).
Der opstår vanskeligheder, fordi kildekoden og lanceringen af tjenesten ikke længere er nok - du skal udføre nogle flere trin. Kopier som minimum dataene og/eller tilmeld dig klyngen. Mere præcist kræver disse tjenester en forståelse af, hvordan man korrekt skalerer, opdaterer og rekonfigurerer dem uden datatab eller midlertidig utilgængelighed. At tage disse behov i betragtning kaldes "operationel viden".
CoreOS-operatører
For at "programmere" operationel viden, slutningen af sidste år CoreOS-projektet "en ny klasse af software" til Kubernetes-platformen - Operatører (fra det engelske "operation", dvs. "operation").
Operatører, der bruger og udvider kernefunktionerne i Kubernetes (inkl. StatefulSets, se forskellen nedenfor) giver DevOps-specialister mulighed for at tilføje operationel viden til applikationskoden.
Operatørens formål — giv brugeren en API, der giver dig mulighed for at administrere flere stateful applikationsenheder i en Kubernetes-klynge uden at tænke på, hvad der er under hætten (hvilke data og hvad de skal gøre med dem, hvilke kommandoer der stadig skal udføres for at vedligeholde klyngen ). Faktisk er Operatøren designet til at forenkle arbejdet med applikationen i klyngen så meget som muligt, og automatisere udførelsen af driftsopgaver, der tidligere skulle løses manuelt.
Sådan arbejder operatører
Replikasæt Kubernetes giver dig mulighed for at angive det ønskede antal kørende pods, og controllere sikrer, at deres antal vedligeholdes (ved at oprette og slette pods). En operatør fungerer på lignende måde og tilføjer et sæt driftsviden til en standard Kubernetes-ressource og -controller, der giver dig mulighed for at udføre yderligere handlinger for at understøtte det nødvendige antal applikationsenheder.
Hvordan er dette forskelligt fra StatefulSets, designet til applikationer, der kræver, at klyngen forsyner dem med stateful ressourcer såsom datalagring eller statiske IP'er? Til sådanne applikationer kan operatører bruge StatefulSets (i stedet Replikasæt) som grundlag, at tilbyde yderligere automatisering: udfør de nødvendige handlinger i tilfælde af nedbrud, lav sikkerhedskopier, opdater konfigurationen osv.
således hvordan virker alt dette? Operatøren er en manager-dæmon, der:
- abonnerer på begivenheds-API'en i Kubernetes;
- modtager fra det data om systemet (om dets Replikasæt, bælg, Tjenester og så videre.);
- modtager data vedr Tredjepartsressourcer (se eksempler nedenfor);
- reagerer på udseende/ændring Tredjepartsressourcer (for eksempel for at ændre størrelsen, ændre versionen og så videre);
- reagerer på ændringer i systemets tilstand (ca Replikasæt, bælg, Tjenester og så videre.);
- det vigtigste:
- opfordrer Kubernetes API til at skabe alt, hvad den har brug for (igen, sin egen Replikasæt, bælg, Tjenester...),
- udfører noget magi (for at forenkle, kan du tro, at operatøren går ind i selve pods og kalder kommandoer, for eksempel for at deltage i en klynge eller for at opgradere dataformatet, når en version opdateres).
Faktisk, som det kan ses af billedet, tilføjes en separat applikation blot til Kubernetes (en almindelig Deployment с ReplicaSet), som kaldes operatøren. Den lever i en almindelig pod (normalt kun én) og er som regel kun ansvarlig for dens navnerum. Denne operatørapplikation implementerer sin API - dog ikke direkte, men gennem Tredjepartsressourcer i Kubernetes.
Således, efter at vi har skabt i navnerum Operatør, vi kan tilføje til det Tredjepartsressourcer.
Eksempel på etcd (se nedenfor for detaljer):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Eksempel på 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 til operatører
CoreOS formulerede de vigtigste mønstre opnået af ingeniører, mens de arbejdede på operatører. På trods af at alle operatører er individuelle (skabt til en specifik applikation med sine egne karakteristika og behov), skal deres oprettelse være baseret på en slags ramme, der stiller følgende krav:
- Installation skal ske gennem en enkelt Deployment: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - og kræver ikke yderligere handlinger.
- Når du installerer en operatør i Kubernetes, skal der oprettes en ny tredjepartstype (ThirdPartyResource). For at starte applikationsforekomster (klyngeforekomster) og administrere dem yderligere (opdatering af versioner, ændring af størrelse osv.), vil brugeren bruge denne type.
- Når det er muligt, bør du bruge de primitiver, der er indbygget i Kubernetes, som f.eks Tjenester и Replikasætat bruge velafprøvet og forståelig kode.
- Kræver bagudkompatibilitet af operatører og understøttelse af ældre versioner af brugerskabte ressourcer.
- Hvis operatøren fjernes, bør selve applikationen fortsætte med at fungere uden ændringer.
- Brugere bør være i stand til at definere den ønskede applikationsversion og orkestrere opdateringer af applikationsversioner. Mangel på softwareopdateringer er en almindelig kilde til drifts- og sikkerhedsproblemer, så operatører skal hjælpe brugere i denne sag.
- Operatører bør testes med et værktøj som Chaos Monkey, som identificerer potentielle fejl i pods, konfigurationer og netværket.
etcd Operatør
Operatør implementeringseksempel - etcd operatør, på dagen for offentliggørelsen af dette koncept. Etcd-klyngekonfigurationen kan være kompleks på grund af behovet for at opretholde kvorum, behovet for at omkonfigurere klyngemedlemskab, oprette sikkerhedskopier osv. Manuel skalering af en etcd-klynge betyder for eksempel, at du skal oprette et DNS-navn til et nyt klyngemedlem, starte en ny etcd-entitet og advare klyngen om det nye medlem (etcdctl medlem tilføje). I tilfældet med operatøren skal brugeren kun ændre klyngestørrelsen - alt andet vil ske automatisk.
Og da etcd også blev oprettet i CoreOS, var det ret logisk at se dens Operator vises først. Hvordan arbejder han? Operatørlogik osv bestemmes af tre komponenter:
- Observere. Operatøren overvåger klyngens tilstand ved hjælp af Kubernetes API.
- Analyse. Finder forskelle mellem den aktuelle status og den ønskede (defineret af brugerkonfigurationen).
- Handling. Løser opdagede forskelle ved hjælp af etcd og/eller Kubernetes service API'er.
For at implementere denne logik er der udarbejdet funktioner i operatøren Opret/ødelæg (oprettelse og sletning af etcd klyngemedlemmer) og Resize (ændring i antallet af klyngemedlemmer). Rigtigheden af dens drift blev kontrolleret ved hjælp af et hjælpeprogram, der er oprettet i lighed med Chaos Monkey fra Netflix, dvs. dræber etcd pods tilfældigt.
For fuld drift af etcd giver operatøren yderligere funktioner: backup (automatisk og usynlig for brugere oprettelse af sikkerhedskopier - i konfigurationen er det nok til at bestemme, hvor ofte de skal laves og hvor mange, der skal gemmes - og efterfølgende gendannelse af data fra dem) og Opgrader (opdatering af etcd installationer uden nedetid).
Hvordan ser det ud at arbejde 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 aktuelle status for etcd Operator er en betaversion, der kræver Kubernetes 1.5.3+ og etcd 3.0+ for at køre. Kildekode og dokumentation (herunder brugsanvisning) er tilgængelig på .
Et andet eksempel på implementering fra CoreOS er blevet oprettet - , men den er stadig i alfaversion (ikke alle planlagte funktioner er implementeret).
Status og udsigter
5 måneder er gået siden annonceringen af Kubernetes Operators. Der er stadig kun to implementeringer tilgængelige i det officielle CoreOS-lager (til etcd og Prometheus). Begge har endnu ikke nået deres stabile versioner, men commits observeres på daglig basis.
Udviklerne forestiller sig "en fremtid, hvor brugere installerer Postgres Operators, Cassandra Operators eller Redis Operators på deres Kubernetes-klynger og arbejder med de skalerbare entiteter af disse applikationer lige så let som at implementere replikaer af statsløse webapplikationer er i dag." Først Operatører fra tredjepartsudviklere begyndte virkelig at dukke op:
- fra UPMC Enterprises;
- fra Crunchy Data (annonceret sidst i marts 2017);
- fra forfatterne af et distribueret datalagringssystem baseret på Ceph (Rook er i alfa-status);
- fra SAP CCloud.
På den største europæiske gratis softwarekonference FOSDEM, som fandt sted i februar 2017 i Bruxelles, annoncerede Josh Wood fra CoreOS Operatører i (en video er tilgængelig på linket!), som skulle bidrage til væksten i populariteten af dette koncept i det bredere Open Source-fællesskab.
PS Tak for din interesse for artiklen! Abonner på vores hub, for ikke at gå glip af nye materialer og opskrifter på DevOps og GNU/Linux systemadministration - vi udgiver dem regelmæssigt!
Kilde: www.habr.com