🥇Оператори для 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, стручки, Послуги і т.п.);
отримує дані про Ресурси третіх осіб (Див. Приклади нижче);
реагує на появу/зміну Ресурси третіх осіб (наприклад, зміна розміру, зміна версії тощо);
реагує на зміну стану системи (про свої ReplicaSets, стручки, Послуги і т.п.);
найголовніше:
1. звертається до Kubernetes API, щоб створювати все необхідне (знову ж таки, свої ReplicaSets, стручки, Послуги...),
2. виконує деяку магію (можна, для спрощення, думати, що Оператор заходить у самі поди і викликає команди, наприклад, для вступу в кластер або апгрейду формату даних при оновленні версії).

За фактом, як видно з картинки, 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 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 Оператор Прометейале він поки що знаходиться в альфа-версії (не всі заплановані функції реалізовані).

Статус та перспективи

З моменту анонсу операторів 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-додатки