Helm vs. Operator: приклад Hazelcast

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт, мене звати Сергій. Я працюю Software engineer в Cloud-native команді в компанії Hazelcast. В цій команді ми займаємось тим, щоб зробити наш продукт по справжньому cloud-native.

Коли ж ми говоримо про cloud-native, одне з перших що приходить на думку — це Kubernetes. І саме інтеграції з ним ми приділяємо особливу увагу. В даній статті я розповім про наш досвід інтеграції з даною платформою та розповім чому ми вирішили написати оператор, вже маючи справний та активно підтримуваний Helm chart.

Популярність Kubernetes робить його однією з найрозповсюдженіших платформ в сучасній cloud-native розробці. І однією з важливих задач є деплой на Kubernetes. Щоб цю задачу спростити є багато різних рішень, але найбільше виділяються два: Helm та Operator.

Дисклеймер: ця стаття є перекладом оригіналу, опублікованого тут. Переклад з англійської мови організовано редакцією DOU.

Чому потрібен Hazelcast Platform Operator

Hazelcast дотримується концепції cloud-native, і для цього в нас є Helm chart, який є зрілим та активно підтримуваним, та дозволяє швидко та легко задеплоїти Hazelcast та Management Center на Kubernetes.

Hazelcast досить потужний продукт, який має багату функціональність, але ця функціональність додає складності. Саме тому ми намагаємось зробити cloud-native досвід користувачів Hazelcast якомога простішим та спокійним.

Використовуючи Helm, досить просто встановити кластер Hazelcast, але для використання складнішого функціоналу, користувачам потрібно мати певний досвід роботи з Hazelcast та Kubernetes. І щоб спростити це для користувачів, ми вирішили не намагатись заімплементити у Helm те, для чого він не передбачений, а натомість написати Kubernetes Operator.

Одна з основних ідей була розробити абстракцію над комплексною конфігурацією Hazelcast. Це означає, що замість того, щоб користувачі використовували потужну, але, водночас, складну конфігурацію Hazelcast, яка описує, як саме платформа має працювати, ми розробляємо API, який фокусується на тому, який саме функціонал потрібен користувачам.

На цей час Hazelcast Platform Operator бере під свій контроль повний життєвий цикл застосунку та функціоналу, це означає, що він є Level III оператором. Але чудова сторона оператора в тому, що його легко розширювати та доповнювати новим функціоналом, таким як метрики, оповіщення, масштабування тощо.

Проблеми, які вирішує оператор

В таблиці нижче наведене порівняння функціональностей, які підтримують Helm та Operator. Детальніше ці пункти будуть розглянуті нижче.

Custom Resource Definition (CRD)

За допомогою оператора Hazelcast кластер стає насправді нативним для Kubernetes, використовуючи CRD. Ми маємо ресурс Hazelcast CR, та можемо створювати та керувати ним як будь-яким іншим ресурсом Kubernetes.

apiVersion: hazelcast.com/v1alpha1 
kind: Hazelcast 
metadata:   
  name: my-hazelcast

І Helm, і Operator можуть мати набір конфігурації за замовчанням, щоб таким чином користувач міг змінювати тільки те, що йому потрібно. Однак за допомогою оператора ми можемо в реальному часі визначати, яку конфігурацію використовувати.

Для прикладу, Hazelcast Platform Operator використовує іншу конфігурацію SecurityContext, коли кластер встановлюється на платформі OpenShift. Використовуючи Helm, користувачеві доведеться самому змінити конфігурацію SecurityContext для різних платформ.

І, звичайно, Hazelcast не був би по справжньому нативним для Kubernetes, якби ми не могли спостерігати за станом кластера:

$ kubectl get hazelcast my-hazelcast 
NAME         STATUS  MEMBERS EXTERNAL-ADDRESSES 
my-hazelcast Running 3/3

Динамічна конфігурація

Далеко не всі користувачі знають одразу, який функціонал їм може знадобитись надалі.

Наприклад, починаючи зі звичайного in-memory датаґріду, користувач може захотіти використати функціонал WAN Replication, щоб реплікувати всі дані між двома кластерами. Це можливо налаштувати за допомогою Helm.

Однак, подібна зміна налаштування призведе до рестарту кластера. Використовуючи ж оператор, потрібно лише створити WanReplication ресурс, і оператор динамічно налаштує кластер та не буде потребувати рестарту.

apiVersion: hazelcast.com/v1alpha1
kind: WanReplication 
metadata:   
  name: wanreplication-sample 
spec:   
  mapResourceName: my-map   
  targetClusterName: dev   
  endpoints: "203.0.113.61"

API

Однією з найважливіших частих будь-якого продукту є його API. За допомогою оператора ми хочемо полегшити використання Hazelcast для користувачів, і тому ми вирішили абстрагувати складну конфігурацію та зробити API простим та інтуїтивно зрозумілим для користувача.

Одним з прикладів є підключення до кластера Hazelcast з-за меж Kubernetes за допомогою smart-клієнта. Щоб це зробити, кожному користувачеві потрібно створити Service для кожного Hazelcast Pod. Це можна зробити або вручну, що викличе проблеми у випадку масштабування, або використовувати сторонні інструменти, такі як metacontroller.

За допомогою оператора, користувачеві потрібно лише декларативно описати exposeExternally конфігурацію в Hazelcast CR.

apiVersion: hazelcast.com/v1alpha1
kind: Hazelcast
metadata:
  name: hazelcast
spec:
  licenseKeySecret: hazelcast-license-key
  exposeExternally:
    type: Smart
    discoveryServiceType: LoadBalancer
    memberAccess: NodePortExternalIP

Оператор подбає про створення сервісів вказаного типу для кожного Hazelcast Pod.

Життєвий цикл функціонала

Hazelcast має широкий набір функціональності. Але дуже часто цей функціонал є досить просунутим та його використання потребує ручних кроків.

Наприклад, користувач може захотіти створити резервну копію кластера та скопіювати його на зовнішньому сервісі-сховищі даних, такому як S3. Helm допоможе в тому, щоб змонтувати Volume до кожного з екземплярів Hazelcast, але оскільки Helm не керує життєвим циклом функціонала, користувачеві доведеться вручну запустити процес створення резервної копії.

Після чого доведеться, також вручну, скопіювати створену копію на потрібний сервіс-сховище даних. Оператор спрощує цей процес: дозволяє досягти потрібного результату, просто налаштувавши persistence та створивши HotBackup CR.

apiVersion: hazelcast.com/v1alpha1
kind: Hazelcast
metadata:
  name: hazelcast
spec:
  licenseKeySecret: hazelcast-license-key
  persistence:
    baseDir: "/data/hot-restart/"

apiVersion: hazelcast.com/v1alpha1
kind: HotBackup
metadata:
  name: hot-backup
spec:
  hazelcastResourceName: my-hazelcast
  bucketURI: "s3://operator-backup"
  secret: "br-secret-s3"

Щобільше, процес створення резервної копії можна налаштувати за розкладом, використовуючи CronHotBackup, що дозволить автоматично створювати їх.

Висновки

Ми розглянули, наскільки Hazelcast Platform Operatom може бути корисним користувачам Hazelcast. Однак, це зовсім не означає, що Helm chart більше не потрібен. Helm все ще є дуже корисним для досвідчених користувачів, які хочуть самі контролювати всі процесу свого кластеру.

Але якщо ви надаєте перевагу простоті, автоматизації та Kubernetes-native досвіду, тоді оператор буде правильним вибором для вас. На перший погляд, може здатись, що Hazelcast Platform Operator підтримує менше функціоналу, однак він все ще активно розробляється, та новий функціонал додається з кожним новим релізом.

Крім того, Custom Configuration покриє відсутній функціонал, допоки він не стане доступним в операторі нативно, тож ви можете обирати, орієнтуючись на ваші потреби.

Діліться вашим досвідом у коментарях, у Slack та Github.