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. Детальніше ці пункти будуть розглянуті нижче.
Operator |
Helm | |
Просте встановлення кластера за допомогою однієї команди |
✅ |
✅ |
Робить Hazelcast нативним для Kubernetes |
✅ |
❌ |
Автоматичне конфігурування кластера під різні платформи |
✅ |
❌ |
Можливість динамічної конфігурації без перенавантаження кластера |
✅ |
❌ |
Повний контроль над конфігурацією Hazelcast кластеру |
❌ |
✅ |
Автоматичне керування життєвим циклом кластера та функціоналу |
✅ |
❌ |
Проста абстракція над складною конфігурацією Hazelcast |
✅ |
❌ |
Підтримується весь функціонал Hazelcast |
⏳ |
✅ |
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 покриє відсутній функціонал, допоки він не стане доступним в операторі нативно, тож ви можете обирати, орієнтуючись на ваші потреби.
18 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів