Problemet med statlige applikasjoner i Kubernetes
Konfigurasjon, lansering og videre skalering av applikasjoner og tjenester er enkelt når det gjelder saker klassifisert som statsløse, d.v.s. uten å lagre data. Det er praktisk å kjøre slike tjenester i Kubernetes ved å bruke standard APIer, fordi alt skjer rett ut av esken: i henhold til standardkonfigurasjoner, uten å involvere noen spesifikasjoner og magi.
Enkelt sagt, for å kjøre fem flere kopier av PHP/Ruby/Python-backend i en klynge fra containere, trenger du bare å heve en ny server 5 ganger og kopiere kildene. Siden både kildekoden og init-skriptet er i bildet, blir det å skalere et statsløst program ganske elementært. Som elskere av containere og mikrotjenestearkitekturer er godt klar over, begynner vanskelighetene for statlige søknader, dvs. med vedvarende data som databaser og cacher (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra ...). Dette gjelder både programvare som uavhengig implementerer en quorum-klynge (for eksempel Percona XtraDB og Cassandra), og programvare som krever separate administrasjonsverktøy (som Redis, MySQL, PostgreSQL ...).
Vanskeligheter oppstår fordi kildekoden og lanseringen av tjenesten ikke er nok - du må utføre noen flere handlinger. Som et minimum, kopier dataene og/eller bli med i klyngen. For å være mer presis krever disse tjenestene å forstå hvordan de skal skaleres, oppdateres og rekonfigureres på riktig måte uten tap av data og midlertidig utilgjengelighet. Å redegjøre for disse behovene kalles «operativ kunnskap» (operativ kunnskap).
CoreOS-operatører
For å "programmere" operasjonell kunnskap, på slutten av fjoråret CoreOS-prosjektet "En ny klasse programvare" for Kubernetes-plattformen - Operatører (Operatorer, fra engelsk "operation", dvs. "operation").
Operatører som bruker og utvider de grunnleggende egenskapene til Kubernetes (inkl. StatefulSets, se nedenfor for forskjeller) lar DevOps legge til operasjonell kunnskap til applikasjonskoden.
Operatørens formål - gi brukeren en API som lar deg administrere mange enheter av en stateful applikasjon i en Kubernetes-klynge uten å tenke på hva som er under panseret (hvilke data og hva de skal gjøre med dem, hvilke kommandoer som fortsatt må utføres for å opprettholde klynge). Operatøren er faktisk designet for å forenkle arbeidet med applikasjonen i klyngen så mye som mulig, og automatisere utførelsen av driftsoppgaver som tidligere måtte løses manuelt.
Hvordan operatører fungerer
Replikasett Kubernetes lar deg spesifisere ønsket antall kjørende pods, og kontrollere sørger for at antallet opprettholdes (ved å opprette og slette pods). På samme måte fungerer operatøren ved å legge til et sett med operasjonell kunnskap til standard Kubernetes-ressurs og kontrolleren, slik at du kan utføre ytterligere handlinger for å opprettholde det nødvendige antallet applikasjonsenheter.
Hvordan skiller dette seg fra StatefulSetsfor applikasjoner som krever at klyngen gir dem stateful ressurser som datalagring eller statiske IP-er? For slike applikasjoner kan operatører bruke StatefulSets (i stedet Replikasett) som grunnlag, tilbud ekstra automatisering: utfør nødvendige handlinger i tilfelle krasj, lag sikkerhetskopier, oppdater konfigurasjonen, etc.
således hvordan fungerer det hele? Operatøren er en kontrolldemon som:
- abonnerer på hendelses-APIet i Kubernetes;
- mottar fra det data om systemet (om dets Replikasett, pods, Tjenester og så videre.);
- mottar informasjon om Tredjepartsressurser (se eksempler nedenfor);
- reagerer på utseendet/endringen Tredjepartsressurser (for eksempel for å endre størrelse, endre versjon og så videre);
- reagerer på en endring i systemets tilstand (omtrent dets Replikasett, pods, Tjenester og så videre.);
- det viktigste:
- får tilgang til Kubernetes API for å lage alt du trenger (igjen din egen Replikasett, pods, Tjenester...),
- utfører litt magi (du kan for enkelhets skyld tro at operatøren går inn i selve podene og kaller kommandoer, for eksempel for å bli med i klyngen eller for å oppgradere dataformatet når du oppdaterer versjonen).
Faktisk, som du kan se fra bildet, legges en egen applikasjon ganske enkelt til Kubernetes (den vanlige Utplassering с Replika sett), som kalles Operatøren. Den lever i en vanlig pod (vanligvis en enkelt) og er som regel bare ansvarlig for sin egen namespace. Denne operatørapplikasjonen implementerer API-en - men ikke direkte, men gjennom Tredjepartsressurser i Kubernetes.
Altså, etter at vi har skapt namespace Operatør, vi kan legge til det Tredjepartsressurser.
Eksempel for etcd (se detaljer nedenfor):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Eksempel for 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 formulerte hovedmønstrene oppnådd av ingeniører mens de jobbet med operatører. Til tross for det faktum at alle operatører er individuelle (de er laget for en spesifikk applikasjon med sine egne egenskaper og behov), må deres opprettelse være basert på et slags rammeverk som stiller følgende krav:
- Installasjon må gjøres gjennom en enkelt Utplassering: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - og krever ikke ytterligere handling.
- Installering av en operatør i Kubernetes bør opprette en ny utenlandsk type (ThirdPartyResource). For å starte applikasjonsforekomster (klyngeforekomster) og administrere dem videre (oppdatere versjoner, endre størrelse osv.), vil brukeren bruke denne typen.
- Når det er mulig, bør Kubernetes innebygde primitiver brukes, som f.eks Tjenester и Replikasettå bruke godt testet og forståelig kode.
- Bakoverkompatibilitet for operatører og støtte for eldre versjoner av brukerskapte ressurser kreves.
- Når operatøren er fjernet, skal selve applikasjonen fortsette å fungere uten endringer.
- Brukere bør kunne bestemme ønsket applikasjonsversjon og organisere oppdateringer av applikasjonsversjon. Mangel på programvareoppdateringer er en vanlig kilde til drifts- og sikkerhetsproblemer, og operatører må bistå brukere i denne saken.
- Operatører bør testes av et verktøy som Chaos Monkey, som oppdager potensielle feil i pods, konfigurasjoner og nettverket.
etcd Operatør
Operatør implementeringseksempel - etcd operatør, til dagen for kunngjøringen av dette konseptet. Etcd klyngekonfigurasjon kan være kompleks på grunn av behovet for å opprettholde quorum, behovet for å rekonfigurere klyngemedlemskap, lage sikkerhetskopier, og så videre. Manuell skalering av en etcd-klynge betyr for eksempel å opprette et DNS-navn for et nytt klyngemedlem, starte en ny etcd-enhet, varsle klyngen om det nye medlemmet (etcdctl medlem add). Når det gjelder Operatøren, vil det være nok for brukeren å endre størrelsen på klyngen - alt annet vil skje automatisk.
Og siden etcd også ble opprettet i CoreOS, var det ganske logisk å se utseendet til operatøren først. Hvordan jobber han? etcd Operatørlogikk definert av tre komponenter:
- Observasjon. Operatøren overvåker statusen til klyngen ved hjelp av Kubernetes API.
- Analyse (Analyse). Finner forskjeller mellom gjeldende status og ønsket (definert av brukerkonfigurasjon).
- Handling (Act). Eliminerer oppdagede forskjeller ved å bruke etcd og/eller Kubernetes tjeneste APIer.
For å implementere denne logikken har operatøren forberedt funksjoner Opprett/ødelegg (opprett og fjern klyngemedlemmer etcd) og Resize (endring i antall klyngemedlemmer). Kontroll av riktigheten av ytelsen ble kontrollert ved hjelp av et verktøy laget i likhet med Chaos Monkey fra Netflix, dvs. drepe etcd pods tilfeldig.
For full drift av etcd tilbyr operatøren tilleggsfunksjoner: Backup (automatisk og umerkelig for brukere å lage sikkerhetskopier - i konfigurasjonen er det nok å bestemme hvor ofte de skal gjøres og hvor mye de skal lagre - og påfølgende datagjenoppretting fra dem) og Oppgradere (oppdatering etcd installasjoner uten nedetid).
Hvordan ser det ut å jobbe 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 nåværende statusen til etcd Operator er en betaversjon som krever Kubernetes 1.5.3+ og etcd 3.0+ for å kjøre. Kildekode og dokumentasjon (inkludert bruksanvisning) er tilgjengelig på .
Et annet implementeringseksempel fra CoreOS har blitt opprettet - , men den er fortsatt i alfa (ikke alle planlagte funksjoner er implementert).
Status og utsikter
Det har gått 5 måneder siden kunngjøringen av Kubernetes-operatørene. Bare to implementeringer er fortsatt tilgjengelige i det offisielle CoreOS-depotet (for etcd og Prometheus). Begge har ennå ikke nådd sine stabile versjoner, men de blir forpliktet på daglig basis.
Utviklere forventer "en fremtid der brukere installerer Postgres Operators, Cassandra Operators eller Redis Operators på Kubernetes-klynger og jobber med de skalerbare enhetene til disse applikasjonene like enkelt som å distribuere kopier av statsløse applikasjoner for nettet i dag." Først Tredjepartsoperatører begynte virkelig å dukke opp.
- fra UPMC Enterprises;
- fra Crunchy Data (kunngjort i slutten av mars 2017 .);
- fra forfatterne av et distribuert lagringssystem basert på Ceph (Rook er i alfa-status);
- fra SAP CCloud.
På den største europeiske fri programvarekonferansen FOSDEM, som fant sted i februar 2017 i Brussel, annonserte Josh Wood fra CoreOS Operatører i (video er tilgjengelig på lenken!) som bør bidra til veksten av populariteten til dette konseptet i det bredere Open Source-samfunnet.
PS Takk for din interesse for artikkelen! Abonner på vår hub, for ikke å gå glipp av nytt materiale og oppskrifter på DevOps og GNU / Linux systemadministrasjon - vi vil publisere dem regelmessig!
Kilde: www.habr.com