Проблем са апликацијама са стањем у Кубернетесу
Конфигурисање, покретање и даље скалирање апликација и сервиса је једноставно када су у питању случајеви класификовани као апатриди, тј. без чувања података. Погодно је покретати такве сервисе у Кубернетесу, користећи његове стандардне АПИ-је, јер се све дешава „из кутије“: према стандардним конфигурацијама, без икаквих специфичности или магије.
Једноставно речено, да бисте покренули још пет копија бацкенд-а у ПХП/Руби/Питхон-у у групи контејнера, потребно је само 5 пута да подесите нови сервер и копирате изворе. Пошто су и изворни код и инит скрипта на слици, скалирање апликације без стања постаје потпуно елементарно. Као што љубитељи контејнера и микросервисне архитектуре добро знају, тешкоће почињу са апликације са стањем, тј. са постојаношћу података као што су базе података и кешови (МиСКЛ, ПостгреСКЛ, Редис, ЕластицСеарцх, Цассандра...). Ово се односи и на софтвер који независно имплементира кворум кластер (на пример, Перцона КстраДБ и Цассандра), и на софтвер који захтева одвојене услужне програме за управљање (као што су Редис, МиСКЛ, ПостгреСКЛ...).
Потешкоће настају јер изворни код и покретање сервиса више нису довољни - потребно је извршити још неколико корака. У најмању руку, копирајте податке и/или се придружите кластеру. Тачније, ове услуге захтевају разумевање како да их правилно скалирају, ажурирају и реконфигуришу без губитка података или привремене недоступности. Узимање у обзир ових потреба назива се „оперативно знање“.
ЦореОС Оператори
У циљу "програмирања" оперативног знања, крајем прошле године пројекат ЦореОС „нова класа софтвера“ за Кубернетес платформу – Оператори (од енглеског „операција“, тј. „операција“).
Оператори који користе и проширују основне могућности Кубернетес-а (укљ. СтатефулСетс, погледајте разлику у наставку) дозволите стручњацима за ДевОпс да додају оперативно знање коду апликације.
Сврха оператера — обезбедите кориснику АПИ који вам омогућава да управљате вишеструким ентитетима апликације са статусом у Кубернетес кластеру, без размишљања о томе шта је испод хаубе (који подаци и шта да се ради са њима, које команде још треба да се изврше да би се кластер одржао ). У ствари, Оператор је дизајниран да максимално поједностави рад са апликацијом унутар кластера, аутоматизујући извршавање оперативних задатака који су се раније морали решавати ручно.
Како раде оператери
РеплицаСетс Кубернетес вам омогућава да одредите жељени број покренутих подова, а контролори осигуравају да се њихов број одржава (креирањем и брисањем подова). Оператор ради на сличан начин, додајући скуп оперативног знања стандардном Кубернетес ресурсу и контролеру који вам омогућава да извршите додатне радње за подршку потребном броју ентитета апликације.
Како се ово разликује од СтатефулСетс, дизајниран за апликације које захтевају да им кластер обезбеди ресурсе са стањем као што су складиштење података или статичке ИП адресе? За такве апликације, оператери могу да користе СтатефулСетс (уместо РеплицаСетс) као основа, понуда додатна аутоматизација: извршите потребне радње у случају пада, направите резервне копије, ажурирајте конфигурацију итд.
Дакле, како све ово функционише? Оператор је демон менаџер који:
- претплати се на АПИ догађаја у Кубернетесу;
- прима од њега податке о систему (о његовом РеплицаСетс, махуна, Usluge итд.);
- прима податке о Ресурси трећих страна (погледајте примере испод);
- реагује на изглед/промену Ресурси трећих страна (на пример, да промените величину, промените верзију и тако даље);
- реагује на промене у стању система (о његовом РеплицаСетс, махуна, Usluge итд.);
- најважније:
- позива Кубернетес АПИ да креира све што му је потребно (опет, сопствено РеплицаСетс, махуна, Usluge...),
- изводи неку магију (да поједноставимо, можете мислити да Оператор улази у саме подове и позива команде, на пример, да се придружи кластеру или да надогради формат података приликом ажурирања верзије).
У ствари, као што се може видети са слике, у Кубернетес се једноставно додаје посебна апликација (обична развој с РеплицаСет), који се зове Оператор. Живи у обичној махуни (обично само једној) и, по правилу, одговорна је само за своје Простор имена. Ова оператерска апликација имплементира свој АПИ - иако не директно, већ преко Ресурси трећих страна у Кубернетесу.
Дакле, након што смо креирали у Простор имена Оператер, можемо му додати Ресурси трећих страна.
Пример за итд (погледајте доле за детаље):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Пример за Еластицсеарцх:
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
Захтеви за оператере
ЦореОС је формулисао главне обрасце које су добили инжењери док су радили на Операторима. Упркос чињеници да су сви Оператери индивидуални (креирани за одређену апликацију са својим карактеристикама и потребама), њихово креирање мора бити засновано на својеврсном оквиру који намеће следеће захтеве:
- Инсталација се мора извршити преко једног развој: кубецтл цреате -ф СОМЕ_ОПЕРАТОР_УРЛ/деплоимент.иамл - и не захтевају додатне радње.
- Када инсталирате Оператор у Кубернетес, мора се креирати нови тип треће стране (ТхирдПартиРесоурце). За покретање инстанци апликације (инстанце кластера) и даље управљање њима (ажурирање верзија, промена величине, итд.), корисник ће користити овај тип.
- Кад год је могуће, требало би да користите примитиве уграђене у Кубернетес, као нпр Usluge и РеплицаСетсда користи добро тестиран и разумљив код.
- Захтева компатибилност оператера уназад и подршку за старије верзије ресурса које креирају корисници.
- Ако се Оператор уклони, сама апликација би требало да настави да функционише без промена.
- Корисници би требало да буду у могућности да дефинишу жељену верзију апликације и оркестрирају ажурирања верзије апликације. Недостатак ажурирања софтвера је чест извор оперативних и безбедносних проблема, тако да оператери морају да помогну корисницима у овом питању.
- Оператере треба тестирати помоћу алата као што је Цхаос Монкеи који идентификује потенцијалне кварове у подовима, конфигурацијама и мрежи.
етцд Оператор
Пример имплементације оператора - етцд оператер, на дан објаве овог концепта. Конфигурација етцд кластера може бити сложена због потребе за одржавањем кворума, потребе за реконфигурацијом чланства у кластеру, креирањем резервних копија итд. На пример, ручно скалирање етцд кластера значи да морате да креирате ДНС име за новог члана кластера, покренете нови етцд ентитет и обавестите кластер о новом члану (етцдцтл члан адд). У случају Оператера, корисник ће морати само да промени величину кластера - све остало ће се десити аутоматски.
А пошто је етцд такође креиран у ЦореОС-у, било је сасвим логично видети да се његов Оператор појављује први. Како он ради? Операторска логика итд одређују три компоненте:
- Посматрајте. Оператор прати стање кластера користећи Кубернетес АПИ.
- Анализа. Проналази разлике између тренутног статуса и жељеног (дефинисаног конфигурацијом корисника).
- Поступак. Решава откривене разлике користећи етцд и/или Кубернетес сервис АПИ.
За имплементацију ове логике, функције су припремљене у Оператору Креирај/уништи (креирање и брисање етцд чланова кластера) и Ресизе (промена броја чланова кластера). Исправност његовог рада проверена је помоћу услужног програма креираног по угледу на Цхаос Монкеи из Нетфлик-а, тј. убијање етцд махуна насумично.
За потпуни рад етцд-а, Оператер пружа додатне функције: Бацкуп (аутоматско и невидљиво за кориснике прављење резервних копија – у конфигурацији је довољно да се одреди колико често да се праве и колико да се чувају – и накнадно враћање података из њих) и Упграде (ажурирање етцд инсталација без застоја).
Како изгледа рад са Оператором?
$ 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
Тренутни статус етцд Оператор-а је бета верзија, која захтева Кубернетес 1.5.3+ и етцд 3.0+ за покретање. Изворни код и документација (укључујући упутства за употребу) доступни су на .
Направљен је још један пример имплементације из ЦореОС-а - , али је и даље у алфа верзији (нису имплементиране све планиране функције).
Статус и изгледи
Прошло је 5 месеци од објављивања Кубернетес оператера. Још увек постоје само две имплементације доступне у званичном спремишту ЦореОС-а (за етцд и Прометхеус). Оба још увек нису достигла своје стабилне верзије, али урезивања се посматрају свакодневно.
Програмери предвиђају „будућност у којој корисници инсталирају Постгрес Операторе, Цассандра Операторе или Редис Операторе на своје Кубернетес кластере и раде са скалабилним ентитетима ових апликација једнако лако као што је данас постављање реплика веб апликација без стања. Први Оператери независних програмера заиста почео да се појављује:
- од УПМЦ Ентерприсес;
- из Црунцхи Дата (најављено крајем марта 2017.);
- од аутора дистрибуираног система за складиштење података заснованог на Цепх-у (Роок је у алфа статусу);
- из САП ЦЦлоуд-а.
На највећој европској конференцији о слободном софтверу ФОСДЕМ, која је одржана у фебруару 2017. у Бриселу, Џош Вуд из ЦореОС-а најавио је Операторе у (видео је доступан на линку!), што би требало да допринесе расту популарности овог концепта у широј Опен Соурце заједници.
ПС Хвала на интересовању за чланак! Претплатите се на наш центар, како не би пропустили нове материјале и рецепте о ДевОпс и ГНУ/Линук системској администрацији - редовно ћемо их објављивати!
Извор: ввв.хабр.цом