Օպերատորներ Kubernetes-ի համար. ինչպես գործարկել պետական ​​ծրագրեր

Պետական ​​հավելվածների խնդիրը Kubernetes-ում

Հավելվածների և ծառայությունների կազմաձևումը, գործարկումը և հետագա մասշտաբը հեշտ է, երբ խոսքը վերաբերում է քաղաքացիություն չունեցող դեպքերին, այսինքն. առանց տվյալների պահպանման: Նման ծառայությունները հարմար է գործարկել Kubernetes-ում՝ օգտագործելով իր ստանդարտ API-ները, քանի որ ամեն ինչ տեղի է ունենում «դուրս արկղից»՝ ըստ ստանդարտ կոնֆիգուրացիաների՝ առանց որևէ յուրահատկության կամ կախարդանքի ներգրավման:

Պարզ ասած, PHP/Ruby/Python-ի ևս հինգ օրինակ գործարկելու համար կոնտեյներների կլաստերում անհրաժեշտ է միայն 5 անգամ տեղադրել նոր սերվեր և պատճենել աղբյուրները: Քանի որ և՛ սկզբնաղբյուրը, և՛ սկզբնական սկրիպտը պատկերում են, քաղաքացիություն չունեցող հավելվածի մասշտաբը դառնում է ամբողջովին տարրական: Քանի որ կոնտեյներների և միկրոսերվիսների ճարտարապետության սիրահարները լավ գիտեն, դժվարությունը սկսվում է նրանից պետական ​​ծրագրեր, այսինքն. տվյալների կայունությամբ, ինչպիսիք են տվյալների բազաները և քեշերը (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...): Սա վերաբերում է և՛ ծրագրերին, որոնք ինքնուրույն իրականացնում են քվորումի կլաստեր (օրինակ՝ Percona XtraDB և Cassandra), և՛ ծրագրերին, որոնք պահանջում են առանձին կառավարման կոմունալ ծառայություններ (օրինակ՝ Redis, MySQL, PostgreSQL...):

Դժվարություններ են առաջանում, քանի որ սկզբնական կոդը և ծառայության գործարկումն այլևս բավարար չեն. դուք պետք է կատարեք ևս մի քանի քայլ: Առնվազն պատճենեք տվյալները և/կամ միացեք կլաստերին: Ավելի ճիշտ, այս ծառայությունները պահանջում են հասկանալ, թե ինչպես ճիշտ չափել, թարմացնել և վերակազմավորել դրանք առանց տվյալների կորստի կամ ժամանակավոր անհասանելիության: Այս կարիքները հաշվի առնելը կոչվում է «գործառնական գիտելիքներ»:

CoreOS օպերատորներ

Գործառնական գիտելիքները «ծրագրավորելու» համար անցած տարվա վերջին CoreOS նախագիծը ներկայացրեց «ծրագրային ապահովման նոր դաս» Kubernetes պլատֆորմի համար - Օպերատորներ (անգլերեն «operation», այսինքն. «operation»):

Օպերատորներ, որոնք օգտագործում և ընդլայնում են Kubernetes-ի հիմնական հնարավորությունները (ներառյալ. StatefulSets, տես ստորև ներկայացված տարբերությունը) թույլ տվեք DevOps-ի մասնագետներին ավելացնել գործառնական գիտելիքներ հավելվածի կոդը:

Օպերատորի նպատակը — օգտատիրոջը տրամադրեք API, որը թույլ է տալիս կառավարել բազմաթիվ պետական ​​կիրառական սուբյեկտներ Kubernetes կլաստերում՝ առանց մտածելու, թե ինչ կա գլխարկի տակ (ինչ տվյալներ և ինչ անել դրա հետ, ինչ հրամաններ դեռ պետք է կատարվեն՝ կլաստերը պահպանելու համար։ ) Փաստորեն, Օպերատորը նախատեսված է հնարավորինս պարզեցնելու աշխատանքը կլաստերի ներսում հավելվածի հետ՝ ավտոմատացնելով գործառնական առաջադրանքների կատարումը, որոնք նախկինում պետք է լուծվեին ձեռքով:

Ինչպես են աշխատում օպերատորները

ReplicaSets Kubernetes-ը թույլ է տալիս նշել գործարկվող փոդերի ցանկալի թիվը, իսկ կարգավորիչները ապահովում են դրանց քանակի պահպանումը (ստեղծելով և ջնջելով պատյաններ): Օպերատորն աշխատում է նույն կերպ՝ ավելացնելով մի շարք գործառնական գիտելիքներ Kubernetes-ի ստանդարտ ռեսուրսին և վերահսկիչին, որը թույլ է տալիս կատարել լրացուցիչ գործողություններ՝ աջակցելու համար անհրաժեշտ թվով հավելվածների օբյեկտներ:

Ինչո՞վ է սա տարբերվում StatefulSets, նախատեսված հավելվածների համար, որոնք պահանջում են, որ կլաստերը տրամադրի իրենց պետական ​​ռեսուրսներ, ինչպիսիք են տվյալների պահպանումը կամ ստատիկ IP-ները: Նման հավելվածների համար Օպերատորները կարող են օգտագործել StatefulSets (փոխարենը) ReplicaSets) որպես հիմք, առաջարկ լրացուցիչ ավտոմատացումԿատարել անհրաժեշտ գործողությունները խափանումների դեպքում, կատարել կրկնօրինակումներ, թարմացնել կոնֆիգուրացիան և այլն:

Այնպես որ, ինչպես է այս ամենը աշխատում: Օպերատորը մենեջեր դեյմոն է, որը.

1. բաժանորդագրվում է իրադարձության API-ին Kubernetes-ում;
2. դրանից ստանում է տվյալներ համակարգի մասին (դրա մասին ReplicaSets, pods, Ծառայություններ և այլն);
3. մասին տվյալներ է ստանում Երրորդ կողմի ռեսուրսներ (տես ստորև բերված օրինակները);
4. արձագանքում է արտաքին տեսքին/փոփոխությանը Երրորդ կողմի ռեսուրսներ (օրինակ՝ չափը փոխելու, տարբերակը փոխելու և այլն);
5. արձագանքում է համակարգի վիճակի փոփոխություններին (դրա մասին ReplicaSets, pods, Ծառայություններ և այլն);
6. ամենակարևորը.
   1. կոչ է անում Kubernetes API-ին ստեղծել այն ամենը, ինչ իրեն անհրաժեշտ է (կրկին՝ իր ReplicaSets, pods, Ծառայություններ...),
   2. կատարում է ինչ-որ կախարդանք (պարզեցնելու համար կարող եք մտածել, որ Օպերատորն ինքն է մտնում պատյանների մեջ և հրամաններ է կանչում, օրինակ՝ միանալու կլաստերին կամ թարմացնելու տվյալների ձևաչափը տարբերակը թարմացնելու ժամանակ):

Իրականում, ինչպես երևում է նկարից, Kubernetes-ին ուղղակի ավելացվում է առանձին հավելված (սովորական տեղակայումը с ReplicaSet), որը կոչվում է Օպերատոր։ Այն ապրում է սովորական պատիճում (սովորաբար միայն մեկում) և, որպես կանոն, պատասխանատու է միայն դրա համար Անվանատարածք. Այս օպերատորի հավելվածն իրականացնում է իր API-ն, թեև ոչ ուղղակիորեն, այլ միջոցով Երրորդ կողմի ռեսուրսներ Կուբերնետեսում։

Այսպիսով, այն բանից հետո, երբ մենք ստեղծել ենք Անվանատարածք Օպերատոր, մենք կարող ենք ավելացնել դրան Երրորդ կողմի ռեսուրսներ.

Օրինակ և այլն (տես ստորև մանրամասների համար):

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

Օրինակ 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

Պահանջներ օպերատորներին

CoreOS-ը ձևակերպել է հիմնական օրինաչափությունները, որոնք ստացել են ինժեներները Օպերատորների վրա աշխատելիս: Չնայած այն հանգամանքին, որ բոլոր Օպերատորները անհատական ​​են (ստեղծվել են որոշակի հավելվածի համար՝ իր առանձնահատկություններով և կարիքներով), նրանց ստեղծումը պետք է հիմնված լինի մի տեսակ շրջանակի վրա, որը պարտադրում է հետևյալ պահանջները.

1. Տեղադրումը պետք է կատարվի միայնակ միջոցով տեղակայումը: kubectl ստեղծել -f SOME_OPERATOR_URL/deployment.yaml - և չեն պահանջում լրացուցիչ գործողություններ:
2. Kubernetes-ում Օպերատոր տեղադրելիս պետք է ստեղծվի երրորդ կողմի նոր տեսակ (ThirdPartyResource). Հավելվածների օրինակները (կլաստերի օրինակներ) գործարկելու և դրանք հետագա կառավարելու համար (տարբերակների թարմացում, չափափոխում և այլն), օգտատերը կօգտագործի այս տեսակը:
3. Հնարավորության դեպքում դուք պետք է օգտագործեք Kubernetes-ում ներկառուցված պրիմիտիվները, ինչպիսիք են Ծառայություններ и ReplicaSetsօգտագործել լավ փորձարկված և հասկանալի ծածկագիր:
4. Պահանջում է օպերատորների հետամնաց համատեղելիություն և օգտատիրոջ կողմից ստեղծված ռեսուրսների հին տարբերակների աջակցություն:
5. Եթե ​​Օպերատորը հեռացվի, ապա հավելվածն ինքը պետք է շարունակի գործել առանց փոփոխությունների:
6. Օգտագործողները պետք է կարողանան սահմանել հավելվածի ցանկալի տարբերակը և կազմակերպել հավելվածի տարբերակների թարմացումները: Ծրագրային ապահովման թարմացումների բացակայությունը գործառնական և անվտանգության խնդիրների ընդհանուր աղբյուր է, ուստի Օպերատորները պետք է օգնեն օգտատերերին այս հարցում:
7. Օպերատորները պետք է փորձարկվեն այնպիսի գործիքով, ինչպիսին է Chaos Monkey-ը, որը բացահայտում է պոտենցիալ խափանումները pods-ում, կոնֆիգուրացիաներում և ցանցում:

etcd Օպերատոր

Օպերատորի իրականացման օրինակ - etcd օպերատոր, պատրաստված այս հայեցակարգի հայտարարության օրը։ etcd կլաստերի կոնֆիգուրացիան կարող է բարդ լինել՝ պայմանավորված քվորումի պահպանման անհրաժեշտությամբ, կլաստերի անդամակցությունը վերակազմավորելու, կրկնօրինակներ ստեղծելու անհրաժեշտությամբ և այլն: Օրինակ, etcd կլաստերի ձեռքով մասշտաբելը նշանակում է, որ դուք պետք է ստեղծեք DNS անուն նոր կլաստերի անդամի համար, սկսեք նոր etcd կազմավորում և ծանուցեք կլաստերին նոր անդամի մասին (etcdctl անդամ ավելացնել) Օպերատորի դեպքում օգտատերը պետք է փոխի միայն կլաստերի չափը. մնացած ամեն ինչ ինքնաբերաբար տեղի կունենա:

Եվ քանի որ etcd-ը նույնպես ստեղծվել է CoreOS-ում, միանգամայն տրամաբանական էր տեսնել դրա Օպերատորի առաջին տեսքը։ Ինչպե՞ս է նա աշխատում: Օպերատորի տրամաբանությունը և այլն որոշվում է երեք բաղադրիչով.

1. Դիտարկեք. Օպերատորը վերահսկում է կլաստերի վիճակը՝ օգտագործելով Kubernetes API:
2. Վերլուծություն. Գտնում է տարբերություններ ընթացիկ և ցանկալիի միջև (սահմանված է օգտագործողի կազմաձևով):
3. Գործողություն. Լուծում է հայտնաբերված տարբերությունները՝ օգտագործելով etcd և/կամ Kubernetes ծառայության API-ները:

Այս տրամաբանությունն իրականացնելու համար Օպերատորում պատրաստվել են գործառույթներ Ստեղծել/ոչնչացնել (ստեղծելով և ջնջելով etcd կլաստերի անդամներ) և Փոփոխել (կլաստերի անդամների թվի փոփոխություն): Դրա գործողության ճիշտությունը ստուգվել է Netflix-ից Chaos Monkey-ի նմանությամբ ստեղծված օգտակար գործիքի միջոցով, այսինքն. պատահականորեն սպանելով etcd pods.

etcd-ի ամբողջական շահագործման համար Օպերատորը տրամադրում է լրացուցիչ հնարավորություններ. Կրկնօրինակեք (ավտոմատ և օգտագործողների համար անտեսանելի կրկնօրինակների ստեղծում. կոնֆիգուրայում բավական է որոշել, թե որքան հաճախ պետք է դրանք պատրաստել և քանիսը պահել, և դրանցից տվյալների հետագա վերականգնումը) և Բարձրացնել (թարմացնել etcd տեղադրումները՝ առանց պարապուրդի):

Ի՞նչ տեսք ունի օպերատորի հետ աշխատելը:

$ 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

etcd օպերատորի ներկայիս կարգավիճակը բետա տարբերակ է, որի գործարկման համար պահանջվում է Kubernetes 1.5.3+ և etcd 3.0+: Աղբյուրի կոդը և փաստաթղթերը (ներառյալ օգտագործման հրահանգները) հասանելի են այստեղ GitHub.

Ստեղծվել է CoreOS-ի իրականացման ևս մեկ օրինակ. Պրոմեթևսի օպերատոր, բայց այն դեռ ալֆա տարբերակում է (ծրագրված բոլոր հնարավորությունները չեն իրականացվել):

Կարգավիճակը և հեռանկարները

Kubernetes Operators-ի հայտարարությունից անցել է 5 ամիս։ Պաշտոնական CoreOS պահոցում դեռևս հասանելի է ընդամենը երկու ներդրում (ettdd-ի և Prometheus-ի համար): Երկուսն էլ դեռ չեն հասել իրենց կայուն տարբերակներին, սակայն պարտավորությունները պահպանվում են ամենօրյա ռեժիմով։

Մշակողները պատկերացնում են «ապագա, որտեղ օգտատերերը տեղադրում են Postgres Operators, Cassandra Operators կամ Redis Operators իրենց Kubernetes կլաստերներում և կաշխատեն այս հավելվածների մասշտաբավոր սուբյեկտների հետ նույնքան հեշտությամբ, որքան այսօր առանց քաղաքացիության վեբ հավելվածների կրկնօրինակների տեղակայումը»: Առաջին Օպերատորներ երրորդ կողմի մշակողներից իսկապես սկսեց հայտնվել.

• Elasticsearch օպերատոր UPMC Enterprises-ից;
• PostgreSQL օպերատոր Crunchy Data-ից (հայտարարվել է 2017 թվականի մարտի վերջին);
• Rook օպերատոր Ceph-ի վրա հիմնված բաշխված տվյալների պահպանման համակարգի հեղինակներից (Ռուկը ալֆա կարգավիճակում է);
• Openstack օպերատորներ SAP CCloud-ից:

Եվրոպական ամենամեծ ազատ ծրագրային ապահովման FOSDEM կոնֆերանսում, որը տեղի ունեցավ 2017 թվականի փետրվարին Բրյուսելում, Ջոշ Վուդը CoreOS-ից հայտարարեց օպերատորների մասին. զեկույցը (տեսանյութը հասանելի է հղումով), ինչը պետք է նպաստի այս հայեցակարգի ժողովրդականության աճին բաց կոդով ավելի լայն համայնքում:

PS Շնորհակալություն հոդվածի նկատմամբ ձեր հետաքրքրության համար: Բաժանորդագրվեք մեր կենտրոնին, որպեսզի բաց չթողնեք DevOps-ի և GNU/Linux համակարգի կառավարման նոր նյութերն ու բաղադրատոմսերը, մենք դրանք պարբերաբար կհրապարակենք:

Source: www.habr.com