Проблемът с приложенията със състояние в Kubernetes
Конфигурирането, стартирането и по-нататъшното мащабиране на приложения и услуги е лесно, когато става въпрос за случаи, класифицирани като без състояние, т.е. без запазване на данни. Удобно е да се изпълняват такива услуги в Kubernetes, като се използват неговите стандартни API, защото всичко се случва „извън кутията“: според стандартните конфигурации, без да се включват никакви специфики или магия.
Просто казано, за да стартирате още пет копия на бекенда в PHP/Ruby/Python в клъстер от контейнери, трябва само да настроите нов сървър 5 пъти и да копирате изходния код. Тъй като и изходният код, и началният скрипт са в изображението, мащабирането на приложение без състояние става напълно елементарно. Както феновете на контейнерите и микросервизната архитектура знаят добре, трудността започва с приложения със състояние, т.е. с постоянство на данни като бази данни и кешове (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Това се отнася както за софтуер, който независимо внедрява кворум клъстер (например Percona XtraDB и Cassandra), така и за софтуер, който изисква отделни помощни програми за управление (като Redis, MySQL, PostgreSQL...).
Трудностите възникват, защото изходният код и стартирането на услугата вече не са достатъчни - трябва да извършите още няколко стъпки. Като минимум копирайте данните и/или се присъединете към клъстера. По-точно, тези услуги изискват разбиране как правилно да се мащабират, актуализират и преконфигурират без загуба на данни или временна недостъпност. Вземането предвид на тези нужди се нарича „оперативни знания“.
Оператори на CoreOS
За да се "програмират" оперативни знания, в края на миналата година проектът CoreOS „нов клас софтуер“ за платформата Kubernetes - Оператори (от английското „operation“, т.е. „операция“).
Оператори, използващи и разширяващи основните възможности на Kubernetes (вкл. StatefulSets, вижте разликата по-долу) позволяват на специалистите по DevOps да добавят оперативни знания към кода на приложението.
Цел на оператора — осигурете на потребителя API, който ви позволява да управлявате множество приложни обекти със състояние в клъстер на Kubernetes, без да мислите какво има под капака (какви данни и какво да правите с тях, какви команди все още трябва да бъдат изпълнени, за да поддържате клъстера ). Всъщност Операторът е предназначен да опрости максимално работата с приложението в рамките на клъстера, автоматизирайки изпълнението на оперативни задачи, които преди това трябваше да се решават ръчно.
Как работят операторите
ReplicaSets Kubernetes ви позволява да посочите желания брой работещи подове, а контролерите гарантират, че техният брой се поддържа (чрез създаване и изтриване на подове). Операторът работи по подобен начин, като добавя набор от оперативни знания към стандартен ресурс и контролер на Kubernetes, който ви позволява да извършвате допълнителни действия, за да поддържате необходимия брой приложни обекти.
Как това е различно от StatefulSets, предназначени за приложения, които изискват клъстерът да им предоставя ресурси със състояние, като съхранение на данни или статични IP адреси? За такива приложения операторите могат да използват StatefulSets (вместо ReplicaSets) като основа, предлагане допълнителна автоматизация: извършете необходимите действия в случай на сривове, направете резервни копия, актуализирайте конфигурацията и др.
По този начин, как работи всичко това? Операторът е мениджърски демон, който:
- се абонира за API на събитието в Kubernetes;
- получава от него данни за системата (за нейния ReplicaSets, Саксии, Услуги и др.);
- получава данни за Ресурси на трети страни (вижте примерите по-долу);
- реагира на появата/промяната Ресурси на трети страни (например за промяна на размера, промяна на версията и т.н.);
- реагира на промените в състоянието на системата (за нейните ReplicaSets, Саксии, Услуги и др.);
- най-важно:
- призовава API на Kubernetes да създаде всичко, от което се нуждае (отново собствено ReplicaSets, Саксии, Услуги...),
- извършва някаква магия (за да опростите, можете да мислите, че Операторът влиза в самите модули и извиква команди, например за присъединяване към клъстер или за надграждане на формата на данните при актуализиране на версия).
Всъщност, както се вижда от снимката, към Kubernetes просто се добавя отделно приложение (обикновено внедряване с ReplicaSet), който се нарича оператор. Живее в обикновена шушулка (обикновено само една) и по правило отговаря само за своята Именно пространство. Това операторско приложение реализира своя API - макар и не директно, а чрез Ресурси на трети страни в Kubernetes.
Така, след като сме създали в Именно пространство Оператор, можем да добавим към него Ресурси на трети страни.
Пример за 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 оператор
Пример за внедряване на оператор - etcd оператор, в деня на обявяването на тази концепция. Конфигурацията на клъстера etcd може да бъде сложна поради необходимостта от поддържане на кворум, необходимостта от преконфигуриране на членството в клъстера, създаване на резервни копия и т.н. Например ръчното мащабиране на etcd клъстер означава, че трябва да създадете DNS име за нов член на клъстера, да стартирате нов etcd обект и да предупредите клъстера за новия член (etcdctl добавяне на член). В случая на оператора, потребителят ще трябва само да промени размера на клъстера - всичко останало ще се случи автоматично.
И тъй като etcd също беше създаден в CoreOS, беше съвсем логично да видим оператора му да се появи първи. Как работи той? Операторска логика и др се определя от три компонента:
- Наблюдавайте. Операторът следи състоянието на клъстера с помощта на Kubernetes API.
- Анализ. Открива разлики между текущото състояние и желаното (дефинирано от потребителската конфигурация).
- Действие. Разрешава откритите разлики с помощта на API на etcd и/или услугата Kubernetes.
За реализиране на тази логика в Оператора са подготвени функции Създаване/унищожаване (създаване и изтриване на членове на клъстер etcd) и Преоразмеряване (промяна в броя на членовете на клъстера). Коректността на работата му беше проверена с помощта на помощна програма, създадена по подобие на Chaos Monkey от Netflix, т.е. произволно убиване на etcd капсули.
За пълноценна работа на etcd, Операторът предоставя допълнителни функции: Архивиране (автоматично и невидимо за потребителите създаване на резервни копия - в конфигурацията е достатъчно да се определи колко често да се правят и колко да се съхраняват - и последващо възстановяване на данните от тях) и Upgrade (актуализиране на 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, оператори Cassandra или оператори Redis на своите Kubernetes клъстери и работят с мащабируемите обекти на тези приложения толкова лесно, колкото е внедряването на реплики на уеб приложения без състояние днес.“ Първо Оператори от разработчици на трети страни наистина започна да се появява:
- от UPMC Enterprises;
- от Crunchy Data (обявен в края на март 2017 г.);
- от авторите на разпределена система за съхранение на данни, базирана на Ceph (Rook е в алфа статус);
- от SAP CCloud.
На най-голямата европейска конференция за свободен софтуер FOSDEM, която се проведе през февруари 2017 г. в Брюксел, Джош Ууд от CoreOS обяви операторите в (видео е достъпно на линка!), което трябва да допринесе за нарастването на популярността на тази концепция в по-широката общност с отворен код.
PS Благодаря за интереса към статията! Абонирайте се за нашия център, за да не пропускате нови материали и рецепти за DevOps и GNU/Linux системна администрация - ще ги публикуваме редовно!
Източник: www.habr.com