🥇Аператары для Kubernetes: як запускаць stateful-прыкладанні

Праблема stateful-прыкладанняў у Kubernetes

Канфігурацыя, запуск і далейшае маштабаванне прыкладанняў і службаў ажыццяўляюцца проста, калі гаворка ідзе аб выпадках, якія класіфікуюцца як stateless, г.зн. без захавання дадзеных. Такія сэрвісы зручна запускаць у Kubernetes, карыстаючыся яго стандартнымі API, таму што ўсё адбываецца "са скрынкі": па стандартных канфігурацыях, без прыцягнення якой-небудзь спецыфікі і магіі.

Прасцей кажучы, для запуску ў кластары з кантэйнераў яшчэ пяці дзід бэкенда на PHP/Ruby/Python патрабуецца толькі 5 раз падняць новы сервер і скапіяваць зыходнікі. Паколькі і зыходнікі, і init-скрыпт ляжаць у выяве, маштабаванне stateless-прыкладанні становіцца зусім элементарным. Як добра вядома аматарам кантэйнераў і мікрасэрвіснай архітэктуры, складанасці пачынаюцца для прыкладанняў катэгорыі stateful, г.зн. з захаваннем дадзеных, такіх як базы дадзеных і кэшы (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…). Гэта датычыцца як софту, самастойна які рэалізуе кворумны кластар (напрыклад, Percona XtraDB і Cassandra), так і софту, які патрабуе асобных кіраўнікоў утыліт (такога, як Redis, MySQL, PostgreSQL…).

Складанасці ўзнікаюць па тым чынніку, што зыходнікаў і запуску сэрвісу становіцца мала – трэба выканаць яшчэ некаторыя дзеянні. Як мінімум - скапіяваць дадзеныя і / або далучыцца да кластара. А калі дакладней, то гэтыя сэрвісы патрабуюць разумення, як іх правільна маштабаваць, абнаўляць і пераканфігураваць без страты даных і іх часовай недаступнасці. Улік гэтых патрэбаў і называецца «эксплуатацыйнымі ведамі» (operational knowledge).

Аператары CoreOS

Для таго, каб "запраграмаваць" эксплуатацыйныя веды, у канцы мінулага года праект CoreOS прадставіў "новы клас праграмнага забеспячэння" для платформы Kubernetes - Аператары (Operators, ад англ. "operation", г.зн. "эксплуатацыя").

Аператары, выкарыстоўваючы і пашыраючы базавыя магчымасці Kubernetes (у т.л. StatefulSets, аб розніцы з якімі гл. ніжэй), дазваляюць DevOps-спецыялістам дадаць эксплуатацыйныя веды ў код прыкладанняў.

Мэта Аператара - падаць карыстачу API, які дазваляе кіраваць мноствам сутнасцяў stateful-прыкладанні ў кластары Kubernetes, не задумляючыся аб тым, што ў яго пад капотам (якія дадзеныя і што з імі рабіць, якія каманды неабходна яшчэ выканаць для падтрымання кластара). Фактычна Аператар закліканы максімальна спрасціць працу з дадаткам у рамках кластара, аўтаматызуючы выкананне эксплуатацыйных задач, якія раней даводзілася вырашаць уручную.

Як працуюць Аператары

ReplicaSets у Kubernetes дазваляюць паказваць жаданую колькасць запушчаных подаў, а кантролеры сочаць за тым, каб іх колькасць захоўвалася (ствараючы і выдаляючы поды). Аналагічна працуе Аператар, які дадае да стандартнага рэсурсу і кантролеру Kubernetes набор эксплуатацыйных ведаў, якія дазваляюць выконваць дадатковыя дзеянні для падтрымання патрэбнай колькасці сутнасцяў прыкладання.

Чым гэта адрозніваецца ад StatefulSets, прызначаных для прыкладанняў, якія патрабуюць ад кластара даць ім такія stateful-рэсурсы, як сховішча дадзеных ці статычныя IP? Для такіх прыкладанняў Аператары могуць выкарыстоўваць StatefulSets (замест ReplicaSets) у якасці асновы, прапаноўваючы дадатковую аўтаматызацыю: выконваць неабходныя дзеянні ў выпадку падзенняў, рабіць бэкапы, абнаўляць канфігурацыю і да т.п.

Такім чынам, як жа ўсё гэта працуе? Аператар уяўляе сабой дэман-кіраўнік, які:

падпісваецца на падзейнае API у Kubernetes;
атрымлівае з яго дадзеныя аб сістэме (аб сваіх ReplicaSets, струкі, Паслугі і да т.п.);
атрымлівае дадзеныя аб Third Party Resources (гл. прыклады ніжэй);
рэагуе на з'яўленне/змяненне Third Party Resources (напрыклад, на змену памеру, змену версіі і гэтак далей);
рэагуе на змяненне стан сістэмы (пра свае ReplicaSets, струкі, Паслугі і да т.п.);
самае галоўнае:
1. звяртаецца да Kubernetes API, каб ствараць усё неабходнае (ізноў жа, свае ReplicaSets, струкі, Паслугі...),
2. выконвае некаторую магію (можна, для спрашчэння, думаць, што Аператар заходзіць у самі поды і выклікае каманды, напрыклад, для ўступлення ў кластар або для апгрэйду фармату дадзеных пры абнаўленні версіі).

Па факце, як відаць з карцінкі, у Kubernetes проста дадаецца асобнае прыкладанне (звычайны разгортванне с ReplicaSet), якое і называецца Аператарам. Яно жыве ў звычайным подзе (звычайна адным-адзіным) і, як правіла, адказвае толькі за свой прастору імёнаў. Гэта дадатак-аператар рэалізуе свой API – праўда, не напрамую, а праз Third Party Resources у Kubernetes.

Такім чынам, пасля таго, як мы стварылі ў прастору імёнаў Аператара, мы можам дадаваць у яго Third Party Resources.

Прыклад для etcd (падрабязнасці гл. ніжэй):

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 сфармулявалі асноўныя патэрны, атрыманыя інжынерамі падчас працы над Аператарамі. Нягледзячы на тое, што ўсе Аператары індывідуальныя (ствараюцца пад пэўны дадатак са сваімі асаблівасцямі і патрэбамі), іх стварэнне павінна абапірацца на своеасаблівы каркас, які прад'яўляе наступныя патрабаванні:

Ўстаноўка павінна вырабляцца праз адзіны разгортванне: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - І не патрабаваць дадатковых дзеянняў.
Пры ўсталёўцы Аператара ў Kubernetes павінен стварацца новы іншы тып (ThirdPartyResource). Для запуску асобнікаў прыкладанняў (экзэмпляраў кластараў) і далейшага кіравання імі (абнаўленне версій, змена памеру і інш.) карыстач будзе выкарыстаць гэты тып.
Пры любой магчымасці неабходна выкарыстоўваць убудаваныя ў Kubernetes прымітывы, такія як Паслугі и ReplicaSets, Каб задзейнічаць добра правераны і зразумелы код.
Неабходна зваротная сумяшчальнасць Аператараў і падтрымка старых версій рэсурсаў, створаных карыстачом.
Пры выдаленні Аператара само прыкладанне павінна працягнуць функцыянаваць без змен.
У карыстальнікаў павінна быць магчымасць вызначаць жаданую версію прыкладання і выконваць аркестроўку абнаўленняў версіі прыкладання. Адсутнасць абнаўленняў ПЗ - частая крыніца праблем эксплуатацыі і бяспекі, таму Аператары павінны дапамагаць карыстальнікам у гэтым пытанні.
Аператары павінны тэставацца прыладай тыпу Chaos Monkey, якія выяўляюць патэнцыйныя збоі ў падах, канфігурацыях і сеткі.

etcd Operator

Прыклад рэалізацыі Аператара - etcd Operator, падрыхтаваны да дня анонсу гэтай канцэпцыі. Кластарная канфігурацыя etcd можа быць складанай з-за неабходнасці падтрымання кворуму, запатрабаванні ў пераканфігурацыі сяброўства ў кластары, стварэнні бэкапаў і да т.п. Напрыклад, маштабаванне кластара etcd ўручную азначае неабходнасць стварэння DNS-імя для новага члена кластара, запуск новай сутнасці etcd, абвесткі кластара аб новым члене (etcdctl member add). У выпадку з Аператарам карыстальніку дастаткова будзе змяніць памер кластара - усё астатняе адбудзецца аўтаматычна.

І паколькі etcd стварылі таксама ў CoreOS, суцэль лагічным было ўбачыць з'яўленне яго Аператара першым. Як ён працуе? Логіка Аператара etcd вызначаецца трыма складнікамі:

Назіранне (Observe). Аператар сочыць за станам кластара па Kubernetes API.
Аналіз (Analyze). Знаходзіць адрозненні бягучага статуту ад жаданага (вызначанага карыстацкай канфігурацыяй).
Дзеянне (Act). Ухіляе выяўленыя адрозненні з дапамогай API сэрвісу etcd і/ці Kubernetes.

Для рэалізацыі гэтай логікі ў Аператары падрыхтаваны функцыі Create/Destroy (стварэнне і выдаленне членаў кластара etcd) і змена памеру (змяненне колькасці членаў кластара). Праверка карэктнасці яе працаздольнасці правяралася з дапамогай утыліты, створанай па падабенстве Chaos Monkey ад Netflix, г.зн. забівалай поды etcd выпадковым чынам.

Для паўнавартаснай эксплуатацыі 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 Operator - бэта-версія, якая патрабуе для працы Kubernetes 1.5.3+ і etcd 3.0+. Зыходны код і дакументацыя (уключаючы інструкцыю па ўжыванні) даступныя на GitHub.

Створаны і іншы прыклад рэалізацыі ад CoreOS. Prometheus Operator, Але ён пакуль знаходзіцца ў альфа-версіі (не ўсе запланаваныя функцыі рэалізаваны).

Статус і перспектывы

З моманту анонсу Аператараў Kubernetes прайшло 5 месяцаў. У афіцыйным рэпазітары CoreOS па-ранейшаму даступныя толькі дзве рэалізацыі (для etcd і Prometheus). Абедзьве яшчэ не дасягнулі сваіх стабільных вэрсіяў, але коміты ў іх назіраюцца штодня.

Распрацоўнікі чакаюць "будучыню, у якім карыстачы ўсталёўваюць Postgres Operators, Cassandra Operators або Redis Operators у сваіх кластарах Kubernetes і працуюць з якія маштабуюцца сутнасцямі гэтых прыкладанняў гэтак жа лёгка, як сёння гэта адбываецца з дэплоем рэплік stateless-прыкладанняў для вэба". Першыя Аператары ад іншых распрацоўшчыкаў сапраўды пачалі з'яўляцца:

Elasticsearch Operator ад UPMC Enterprises;
PostgreSQL Operator ад Crunchy Data (анансаваны ў канцы сакавіка 2017 г.);
Rook Operator ад аўтараў размеркаванай сістэмы захоўвання дадзеных на базе Ceph (Rook знаходзіцца ў альфа-статусе);
Openstack Operators ад SAP CCloud.

На найбуйнейшай еўрапейскай канферэнцыі па свабодным праграмным забеспячэнні FOSDEM, што праходзіла ў лютым 2017 года ў Бруселі, Josh Wood з CoreOS анансаваў Аператараў у дакладзе (па спасылцы даступна відэа!), што павінна спрыяць росту папулярнасці гэтай канцэпцыі ў шырэйшай Open Source-супольнасці.

PS Дзякуй за цікавасць да артыкула! Падпісвайцеся на наш хаб, каб не прапусціць новыя матэрыялы і рэцэпты па DevOps і сістэмнаму адміністраванню GNU/Linux - мы будзем публікаваць іх рэгулярна!

Крыніца: habr.com

Аператары для Kubernetes: як запускаць stateful-прыкладанні