Проблемот со државните апликации во Кубернетес
Конфигурацијата, стартувањето и понатамошното скалирање на апликациите и услугите е лесно кога станува збор за случаи класифицирани како без државјанство, т.е. без зачувување на податоци. Удобно е да се извршуваат такви услуги во Kubernetes, користејќи ги неговите стандардни API, бидејќи сè се случува „надвор од кутијата“: според стандардните конфигурации, без да вклучува никакви специфики или магија.
Едноставно кажано, за да започнете уште пет копии од заднината во PHP/Ruby/Python во кластер од контејнери, треба само да поставите нов сервер 5 пати и да ги копирате изворите. Бидејќи и изворниот код и почетната скрипта се на сликата, скалирањето на апликацијата без државјанство станува целосно елементарно. Како што добро знаат љубителите на контејнерите и микросервисната архитектура, тешкотијата започнува со државни апликации, т.е. со упорност на податоци како што се бази на податоци и кешови (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ова се однесува и на софтверот што независно имплементира кластер на кворум (на пример, Percona XtraDB и Cassandra), и на софтверот што бара посебни алатки за управување (како Redis, MySQL, PostgreSQL...).
Тешкотиите се јавуваат затоа што изворниот код и стартувањето на услугата веќе не се доволни - треба да извршите уште неколку чекори. Најмалку, копирајте ги податоците и/или придружете се на кластерот. Поточно, овие услуги бараат разбирање за тоа како правилно да се размерат, ажурираат и реконфигурираат без губење на податоци или привремена недостапност. Земањето предвид на овие потреби се нарекува „оперативно знаење“.
Оператори на CoreOS
Со цел да се „програмира“ оперативното знаење, кон крајот на минатата година проектот CoreOS „нова класа на софтвер“ за платформата Кубернетес - Оператори (од англискиот „операција“, т.е. „операција“).
Оператори кои ги користат и ги прошируваат основните можности на Kubernetes (вкл. StatefulSets, видете ја разликата подолу) дозволете им на специјалистите на DevOps да додадат оперативно знаење во кодот на апликацијата.
Цел на операторот — дајте му на корисникот API што ви овозможува да управувате со повеќе државни апликациски ентитети во кластерот Kubernetes, без да размислувате за тоа што е под капакот (кои податоци и што да правите со нив, кои команди сè уште треба да се извршат за да се одржи кластерот ). Всушност, Операторот е дизајниран да ја поедностави работата со апликацијата во кластерот што е можно повеќе, автоматизирајќи го извршувањето на оперативните задачи кои претходно требаше да се решат рачно.
Како работат операторите
ReplicaSets Kubernetes ви овозможува да го одредите саканиот број на подлоги за работа, а контролорите обезбедуваат дека нивниот број се одржува (со креирање и бришење на подлоги). Оператор работи на сличен начин, додавајќи збир на оперативни знаења на стандарден ресурс и контролер на Kubernetes што ви овозможува да извршите дополнителни дејства за поддршка на потребниот број на апликациски ентитети.
Како се разликува ова од StatefulSets, дизајниран за апликации кои бараат кластерот да им обезбеди државни ресурси како што се складирање податоци или статични IP-адреси? За такви апликации, операторите можат да користат StatefulSets (наместо тоа ReplicaSets) како основа, понуда дополнителна автоматизација: извршете ги потребните дејства во случај на падови, правете резервни копии, ажурирајте ја конфигурацијата итн.
Значи, како функционира сето ова? Операторот е менаџерски демон кој:
- се претплати на настанот API во Kubernetes;
- добива од него податоци за системот (за неговиот ReplicaSets, мешунки, Услуги и така натаму.);
- добива податоци за Ресурси од трета страна (види примери подолу);
- реагира на изглед/промена Ресурси од трета страна (на пример, за промена на големината, промена на верзијата и така натаму);
- реагира на промените во состојбата на системот (за него ReplicaSets, мешунки, Услуги и така натаму.);
- најважно:
- го повикува Kubernetes API да создаде сè што му треба (повторно, свое ReplicaSets, мешунки, Услуги...),
- врши некоја магија (за да се поедностави, може да мислите дека Операторот влегува во самите подлоги и повикува команди, на пример, да се приклучи на кластер или да го надгради форматот на податоци при ажурирање верзија).
Всушност, како што може да се види од сликата, посебна апликација е едноставно додадена на 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 ги формулираше главните обрасци добиени од инженерите додека работеа на Оператори. И покрај фактот дека сите Оператори се индивидуални (создадени за одредена апликација со свои карактеристики и потреби), нивното создавање мора да се заснова на еден вид рамка која ги наметнува следните барања:
- Инсталирањето мора да се изврши преку сингл распоредување: kubectl создаде -f SOME_OPERATOR_URL/deployment.yaml - и не бараат дополнителни активности.
- Кога инсталирате оператор во Kubernetes, мора да се креира нов тип на трета страна (ThirdPartyResource). За да стартува примероци на апликации (инстанци на кластер) и дополнително да управува со нив (ажурирање верзии, промена на големината итн.), корисникот ќе го користи овој тип.
- Секогаш кога е можно, треба да ги користите примитивите вградени во Кубернетите, како на пр Услуги и ReplicaSetsда користи добро тестиран и разбирлив код.
- Потребна е компатибилност на операторите наназад и поддршка за постари верзии на ресурси создадени од корисникот.
- Ако Операторот се отстрани, самата апликација треба да продолжи да функционира без промени.
- Корисниците треба да можат да ја дефинираат саканата верзија на апликацијата и да ги организираат ажурирањата на верзијата на апликацијата. Недостатокот на ажурирања на софтверот е чест извор на оперативни и безбедносни проблеми, па затоа операторите мора да им помагаат на корисниците во ова прашање.
- Операторите треба да се тестираат со алатка како Chaos Monkey, која ги идентификува потенцијалните неуспеси во подовите, конфигурациите и мрежата.
итн. Оператор
Пример за имплементација на операторот - etcd оператор, на денот на објавувањето на овој концепт. Конфигурацијата на кластерот etcd може да биде сложена поради потребата да се одржи кворум, потребата да се реконфигурира членството во кластерот, да се создадат резервни копии итн. На пример, рачното скалирање на кластерот etcd значи дека треба да креирате име DNS за нов член на кластерот, да започнете нов ентитет etcd и да го предупредите кластерот за новиот член (etcdctl член додадете). Во случајот со Операторот, корисникот ќе треба само да ја промени големината на кластерот - сè друго ќе се случи автоматски.
И бидејќи etcd беше создаден и во CoreOS, беше сосема логично да се види првиот што се појавува неговиот оператор. Како работи тој? Логика на операторот итн се определува со три компоненти:
- Набљудувај. Операторот ја следи состојбата на кластерот користејќи го Kubernetes API.
- Анализа. Ги наоѓа разликите помеѓу моменталниот статус и посакуваниот (дефиниран од конфигурацијата на корисникот).
- Акција. Ги решава откриените разлики со користење на etcd и/или Kubernetes сервисни API.
За да се имплементира оваа логика, во Операторот се подготвени функции Креирај/Уништи (создавање и бришење на членови на кластерот etcd) и Промена на големина (промена на бројот на членови на кластерот). Исправноста на неговото работење беше проверена со помош на алатка создадена на сличност со Chaos Monkey од Netflix, т.е. Случајно убивајќи мешунки и сл.
За целосно функционирање на 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+ да се извршува. Изворниот код и документацијата (вклучувајќи упатства за употреба) се достапни на .
Создаден е уште еден пример за имплементација од CoreOS - , но сè уште е во алфа верзија (не се имплементирани сите планирани функции).
Статус и изгледи
Поминаа 5 месеци од објавувањето на Kubernetes Operators. Сè уште има само две имплементации достапни во официјалното складиште на CoreOS (за etcd и Prometheus). И двајцата сè уште не ги достигнале своите стабилни верзии, но обврските се набљудуваат на дневна основа.
Програмерите замислуваат „иднина во која корисниците ќе инсталираат Postgres Operators, Cassandra Operators или Redis Operators на нивните Kubernetes кластери и работат со скалабилните ентитети на овие апликации исто толку лесно како што е денес распоредувањето на копии на веб-апликации без државјанство“. Прво Оператори од трети лица програмери навистина почна да се појавува:
- од UPMC Enterprises;
- од Crunchy Data (најавен кон крајот на март 2017 година);
- од авторите на дистрибуиран систем за складирање податоци базиран на Ceph (Рук е во алфа статус);
- од SAP CCloud.
На најголемата европска конференција за слободен софтвер FOSDEM, која се одржа во февруари 2017 година во Брисел, Џош Вуд од CoreOS објави оператори во (достапно видео е на линкот!), што треба да придонесе за растот на популарноста на овој концепт во пошироката заедница со отворен код.
PS Ви благодариме за вашиот интерес за статијата! Претплатете се на нашиот центар, за да не пропуштите нови материјали и рецепти на DevOps и администрацијата на системот GNU/Linux - ќе ги објавуваме редовно!
Извор: www.habr.com