Gweithredwyr ar gyfer Kubernetes: sut i redeg cymwysiadau gwladwriaethol

Y broblem gyda chymwysiadau gwladwriaethol yn Kubernetes

Mae'n hawdd ffurfweddu, lansio a graddio cymwysiadau a gwasanaethau ymhellach o ran achosion a ddosberthir yn ddi-wladwriaeth, h.y. heb arbed data. Mae'n gyfleus rhedeg gwasanaethau o'r fath yn Kubernetes, gan ddefnyddio ei APIs safonol, oherwydd mae popeth yn digwydd "allan o'r bocs": yn ôl ffurfweddiadau safonol, heb gynnwys unrhyw fanylion na hud.

Yn syml, i lansio pum copi arall o'r backend yn PHP/Ruby/Python mewn clwstwr o gynwysyddion, dim ond 5 gwaith sydd angen i chi sefydlu gweinydd newydd a chopïo'r ffynonellau. Gan fod y cod ffynhonnell a'r sgript init yn y ddelwedd, mae graddio cymhwysiad di-wladwriaeth yn dod yn gwbl elfennol. Fel y mae cefnogwyr cynwysyddion a phensaernïaeth microwasanaeth yn gwybod yn dda, mae'r anhawster yn dechrau apps wladwriaethol, h.y. gyda dyfalbarhad data fel cronfeydd data a caches (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Mae hyn yn berthnasol i feddalwedd sy'n gweithredu clwstwr cworwm yn annibynnol (er enghraifft, Percona XtraDB a Cassandra), a meddalwedd sy'n gofyn am gyfleustodau rheoli ar wahân (fel Redis, MySQL, PostgreSQL ...).

Mae anawsterau'n codi oherwydd nad yw'r cod ffynhonnell a lansio'r gwasanaeth yn ddigon bellach - mae angen i chi gymryd mwy o gamau. O leiaf, copïwch y data a/neu ymunwch â'r clwstwr. Yn fwy manwl gywir, mae'r gwasanaethau hyn yn gofyn am ddealltwriaeth o sut i'w graddio, eu diweddaru a'u hailgyflunio'n gywir heb golli data neu heb fod ar gael dros dro. Gelwir cymryd yr anghenion hyn i ystyriaeth yn “wybodaeth weithredol”.

Gweithredwyr CoreOS

Er mwyn "rhaglennu" gwybodaeth weithredol, yn hwyr y llynedd y prosiect CoreOS cyflwyno “dosbarth newydd o feddalwedd” ar gyfer platfform Kubernetes - Gweithredwyr (o’r Saesneg “operation”, h.y. “operation”).

Gweithredwyr sy'n defnyddio ac yn ymestyn galluoedd craidd Kubernetes (gan gynnwys. Setiau Gwladol, gweler y gwahaniaeth isod) caniatáu i arbenigwyr DevOps ychwanegu gwybodaeth weithredol at god y cais.

Pwrpas y Gweithredwr - darparu API i'r defnyddiwr sy'n eich galluogi i reoli endidau cais gwladwriaethol lluosog mewn clwstwr Kubernetes, heb feddwl beth sydd o dan y cwfl (pa ddata a beth i'w wneud ag ef, pa orchmynion sydd angen eu gweithredu o hyd i gynnal y clwstwr ). Mewn gwirionedd, mae'r Gweithredwr wedi'i gynllunio i symleiddio'r gwaith gyda'r cais o fewn y clwstwr cymaint â phosibl, gan awtomeiddio cyflawni tasgau gweithredol yr oedd yn rhaid eu datrys â llaw yn flaenorol.

Sut mae Gweithredwyr yn Gweithio

ReplicaSets Mae Kubernetes yn caniatáu ichi nodi'r nifer a ddymunir o godennau rhedeg, ac mae rheolwyr yn sicrhau bod eu rhif yn cael ei gynnal (trwy greu a dileu codennau). Mae Gweithredwr yn gweithio mewn ffordd debyg, gan ychwanegu set o wybodaeth weithredol at adnodd a rheolydd Kubernetes safonol sy'n eich galluogi i gyflawni camau gweithredu ychwanegol i gefnogi'r nifer ofynnol o endidau cais.

Sut mae hyn yn wahanol i Setiau Gwladol, a gynlluniwyd ar gyfer cymwysiadau sy'n ei gwneud yn ofynnol i'r clwstwr ddarparu adnoddau gwladwriaethol iddynt megis storio data neu IPs sefydlog? Ar gyfer ceisiadau o'r fath, gall Gweithredwyr ddefnyddio Setiau Gwladol (yn lle ReplicaSets) fel sail, offrwm awtomeiddio ychwanegol: cyflawni'r camau angenrheidiol rhag ofn y bydd damweiniau, gwneud copïau wrth gefn, diweddaru'r ffurfweddiad, ac ati.

Felly, sut mae hyn i gyd yn gweithio? Mae'r gweithredwr yn ellyll rheolwr sy'n:

  1. yn tanysgrifio i'r API digwyddiad yn Kubernetes;
  2. yn derbyn oddi wrtho ddata am y system (am ei ReplicaSets, pod, Gwasanaethau ac yn y blaen.);
  3. yn derbyn data am Adnoddau Trydydd Parti (gweler yr enghreifftiau isod);
  4. yn ymateb i ymddangosiad/newid Adnoddau Trydydd Parti (er enghraifft, i newid y maint, newid y fersiwn, ac yn y blaen);
  5. yn ymateb i newidiadau yng nghyflwr y system (am ei ReplicaSets, pod, Gwasanaethau ac yn y blaen.);
  6. y pwysicaf:
    1. yn galw ar yr API Kubernetes i greu popeth sydd ei angen arno (eto, ei ben ei hun ReplicaSets, pod, Gwasanaethau...),
    2. yn perfformio rhywfaint o hud (i symleiddio, gallwch chi feddwl bod y Gweithredwr yn mynd i mewn i'r codennau eu hunain ac yn galw gorchmynion, er enghraifft, i ymuno â chlwstwr neu i uwchraddio'r fformat data wrth ddiweddaru fersiwn).

Gweithredwyr ar gyfer Kubernetes: sut i redeg cymwysiadau gwladwriaethol
Mewn gwirionedd, fel y gwelir o'r llun, mae cais ar wahân yn cael ei ychwanegu at Kubernetes (rheolaidd Defnyddio с ReplicaSet), a elwir y Gweithredwr. Mae'n byw mewn pod cyffredin (dim ond un fel arfer) ac, fel rheol, mae'n gyfrifol amdano yn unig Enwau. Mae'r cais gweithredwr hwn yn gweithredu ei API - er nad yn uniongyrchol, ond drwodd Adnoddau Trydydd Parti yn Kubernetes.

Felly, ar ôl i ni greu i mewn Enwau Gweithredwr, gallwn ychwanegu ato Adnoddau Trydydd Parti.

Enghraifft ar gyfer etcd (gweler isod am fanylion):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

Enghraifft ar gyfer 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

Gofynion ar gyfer Gweithredwyr

Ffurfiodd CoreOS y prif batrymau a gafwyd gan beirianwyr wrth weithio ar Weithredwyr. Er gwaethaf y ffaith bod pob Gweithredwr yn unigol (wedi'i greu ar gyfer cais penodol gyda'i nodweddion a'i anghenion ei hun), rhaid i'w creu fod yn seiliedig ar fath o fframwaith sy'n gosod y gofynion canlynol:

  1. Rhaid gosod yn cael ei wneud drwy sengl Defnyddio: kubectl creu -f SOME_OPERATOR_URL/deployment.yaml - ac nid oes angen camau gweithredu ychwanegol arnynt.
  2. Wrth osod Gweithredwr yn Kubernetes, rhaid creu math trydydd parti newydd (Adnodd Trydydd Parti). I lansio achosion cais (achosion clwstwr) a'u rheoli ymhellach (diweddaru fersiynau, newid maint, ac ati), bydd y defnyddiwr yn defnyddio'r math hwn.
  3. Lle bynnag y bo modd, dylech ddefnyddio'r cyntefigau sydd wedi'u cynnwys yn Kubernetes, megis Gwasanaethau и ReplicaSetsdefnyddio cod dealladwy sydd wedi'i brofi'n dda.
  4. Mae angen i Weithredwyr gydnaws yn ôl a chefnogaeth ar gyfer fersiynau hŷn o adnoddau a grëwyd gan ddefnyddwyr.
  5. Os caiff y Gweithredwr ei dynnu, dylai'r cais ei hun barhau i weithredu heb newidiadau.
  6. Dylai defnyddwyr allu diffinio'r fersiwn cais a ddymunir a threfnu diweddariadau fersiwn cais. Mae diffyg diweddariadau meddalwedd yn ffynhonnell gyffredin o broblemau gweithredol a diogelwch, felly rhaid i Weithredwyr gynorthwyo defnyddwyr yn y mater hwn.
  7. Dylid profi gweithredwyr gydag offeryn fel Chaos Monkey, sy'n nodi methiannau posibl mewn codennau, ffurfweddiadau, a'r rhwydwaith.

ac ati Gweithredwr

Enghraifft Gweithredu Gweithredwr - ac ati Gweithredwr, parod ar ddiwrnod cyhoeddi'r cysyniad hwn. Gall cyfluniad clwstwr ac ati fod yn gymhleth oherwydd yr angen i gynnal cworwm, yr angen i ad-drefnu aelodaeth clwstwr, creu copïau wrth gefn, ac ati. Er enghraifft, mae graddio clwstwr etcd â llaw yn golygu bod angen i chi greu enw DNS ar gyfer aelod clwstwr newydd, cychwyn endid newydd ac ati, a rhybuddio'r clwstwr am yr aelod newydd (aelod etcdctl ychwanegu). Yn achos y Gweithredwr, dim ond maint y clwstwr y bydd angen i'r defnyddiwr ei newid - bydd popeth arall yn digwydd yn awtomatig.

A chan fod ac ati hefyd wedi'i greu yn CoreOS, roedd yn eithaf rhesymegol gweld ei Weithredydd yn ymddangos yn gyntaf. Sut mae e'n gweithio? Rhesymeg gweithredwr ac ati yn cael ei bennu gan dair cydran:

  1. Arsylwi. Mae'r gweithredwr yn monitro cyflwr y clwstwr gan ddefnyddio API Kubernetes.
  2. Dadansoddi. Yn canfod gwahaniaethau rhwng y statws cyfredol a'r un a ddymunir (a ddiffinnir gan ffurfweddiad y defnyddiwr).
  3. Gweithred. Yn datrys gwahaniaethau a ganfuwyd gan ddefnyddio APIs gwasanaeth ac ati a/neu Kubernetes.

Gweithredwyr ar gyfer Kubernetes: sut i redeg cymwysiadau gwladwriaethol

Er mwyn gweithredu'r rhesymeg hon, mae swyddogaethau wedi'u paratoi yn y Gweithredwr Creu/dinistrio (creu a dileu aelodau clwstwr ac ati) a Newid maint (newid yn nifer aelodau'r clwstwr). Gwiriwyd cywirdeb ei weithrediad gan ddefnyddio cyfleustodau a grëwyd yn debyg i Chaos Monkey o Netflix, h.y. lladd codennau etcd ar hap.

Ar gyfer gweithrediad llawn ac ati, mae'r Gweithredwr yn darparu nodweddion ychwanegol: Backup (awtomatig ac anweledig i ddefnyddwyr greu copïau wrth gefn - yn y ffurfwedd mae'n ddigon i benderfynu pa mor aml i'w gwneud a faint i'w storio - ac adfer data oddi wrthynt wedi hynny) a Uwchraddio (diweddaru gosodiadau ac ati heb amser segur).

Sut olwg sydd ar weithio gyda Gweithredwr?

$ 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

Mae statws cyfredol Gweithredwr etcd yn fersiwn beta, sy'n gofyn am Kubernetes 1.5.3+ ac ati 3.0+ i redeg. Mae cod ffynhonnell a dogfennaeth (gan gynnwys cyfarwyddiadau defnyddio) ar gael yn GitHub.

Mae enghraifft arall o weithrediad CoreOS wedi'i greu - Gweithredwr Prometheus, ond mae'n dal i fod mewn fersiwn alffa (nid yw'r holl nodweddion cynlluniedig wedi'u gweithredu).

Statws a rhagolygon

Mae 5 mis wedi mynd heibio ers cyhoeddi Kubernetes Operators. Dim ond dau weithrediad sydd ar gael o hyd yn ystorfa swyddogol CoreOS (ar gyfer ac ati a Prometheus). Nid yw'r ddau wedi cyrraedd eu fersiynau sefydlog eto, ond gwelir ymrwymiad yn ddyddiol.

Mae’r datblygwyr yn rhagweld “dyfodol lle mae defnyddwyr yn gosod Postgres Operators, Gweithredwyr Cassandra neu Weithredwyr Redis ar eu clystyrau Kubernetes ac yn gweithio gydag endidau graddadwy y cymwysiadau hyn mor hawdd â defnyddio copïau o gymwysiadau gwe di-wladwriaeth heddiw.” Yn gyntaf Gweithredwyr o ddatblygwyr trydydd parti dechrau ymddangos mewn gwirionedd:

Yn y gynhadledd meddalwedd rhydd Ewropeaidd fwyaf FOSDEM, a gynhaliwyd ym mis Chwefror 2017 ym Mrwsel, cyhoeddodd Josh Wood o CoreOS Gweithredwyr yn adroddiad (mae fideo ar gael yn y ddolen!), a ddylai gyfrannu at dwf poblogrwydd y cysyniad hwn yn y gymuned Ffynhonnell Agored ehangach.

PS Diolch am eich diddordeb yn yr erthygl! Tanysgrifiwch i'n hyb, er mwyn peidio â cholli deunyddiau a ryseitiau newydd ar weinyddiaeth system DevOps a GNU/Linux - byddwn yn eu cyhoeddi'n rheolaidd!

Ffynhonnell: hab.com

Ychwanegu sylw