Розширення API Kubernetes: Посібник по кастомних контролерах та агрегатному шару - javascript.org.ua

Цей пост охоплює теми, пояснені в керівництві по розширенню API — https://kubernetes.io/docs/concepts/extend-kubernetes/#api-extensions.

У цьому пості ми розглянемо два основні способи розширення Kubernetes: через кастомні контролери та кастомні ресурси і через агрегатний шар.

Варіант 1: Кастомні контролери та кастомні ресурси

1. Кастомний контролер

Кастомний контролер — це частина логіки, яка слідкує за змінами в ресурсах Kubernetes і виконує певні дії. Він не обов'язково має керувати життєвим циклом цих ресурсів, але може виконувати завдання, такі як ведення журналу, сповіщення або управління зовнішніми системами.

Приклад використання: Ви можете створити кастомний контролер для моніторингу Pods і відправки сповіщень, коли виконуються певні умови.

2. Кастомний контролер + кастомний ресурс (CRD) = Оператор

Коли ви комбінуєте кастомний контролер з Custom Resource Definition (CRD), ви створюєте так званий оператор. Оператор керує життєвим циклом складних додатків, визначаючи новий тип ресурсу і реалізуючи цикл узгодження для забезпечення відповідності бажаного стану системи її фактичному стану.

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

Приклад використання: Кастомний ресурс MySQLCluster, яким керує оператор для виконання завдань, таких як масштабування, резервне копіювання та оновлення.

Варіант 2: Розширення через агрегатний шар

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

Як це працює:

Ви створюєте об'єкт APIService, який реєструє ваш зовнішній API сервер у сервері API Kubernetes.
Запити до нового API проксійовані до зовнішнього сервера, який обробляє логіку і відповідає назад.

Приклад використання: API для метрик, який надає кастомні метрики з зовнішнього сервера, доступні через команди kubectl, як якби це був рідний API Kubernetes.

Порівняння двох підходів

Як кастомні контролери з CRD, так і агрегатний шар дозволяють розширювати Kubernetes, але вони служать різним цілям і працюють по-різному.

CRD API vs. Агреговані API на практиці

CRD: Коли ви створюєте CRD (наприклад, kubectl create -f mycrd.yaml), Kubernetes автоматично відкриває його API і реєструє його. Він з'явиться в kubectl api-resources і також буде відображений як APIService, але насправді він не є частиною агрегатного шару. Усі дані кастомного ресурсу зберігаються в базі даних etcd Kubernetes, і для обробки логіки узгодження та управління життєвим циклом ресурсу необхідно реалізувати кастомний контролер.
Агреговані API: Ви явно створюєте об'єкт APIService, щоб маршрутизувати запити до зовнішнього API сервера. Kubernetes проксійовує запити до цього сервера, який управляє даними незалежно.
Агреговані API делегують зберігання та управління даними зовнішній системі, без безпосереднього зберігання в etcd.

Як CRD відрізняються від агрегованих API у списках APIService

API на основі CRD і агреговані API можуть виглядати подібно в списках, але вони функціонують зовсім по-різному:

CRD:

Зберігаються в etcd: Усі дані кастомного ресурсу зберігаються в базі даних etcd Kubernetes.
Потрібен кастомний контролер: Щоб працювати з даними CRD, необхідно реалізувати кастомний контролер, який обробляє логіку узгодження та керує життєвим циклом ресурсу.

Агреговані API:

Керуються зовнішнім API сервером: Агреговані API делегують зберігання та управління даними зовнішній системі.
Немає прямого зберігання в etcd: Натомість Kubernetes перенаправляє запити до зовнішнього API сервера, який самостійно обробляє дані.

Чому API на основі CRD з'являються у списках APIService?

Незважаючи на те, що API на основі CRD і агреговані API мають різні цілі, вони обидва з'являються в результатах команди kubectl get apiservices. Ось чому:

CRD є частиною основного API сервера Kubernetes:

Коли ви створюєте CRD, сервер API Kubernetes керує ним нативно і надає його як частину API Kubernetes.

2. Механізм виявлення:

Як API на основі CRD, так і API агрегатного шару використовують однаковий механізм виявлення, що дозволяє їм з'являтися в списках API. Це забезпечує єдиний погляд на доступні API.

3. Об'єкти APIService все одно створюються:

Kubernetes створює внутрішні об'єкти APIService для API на основі CRD, щоб стандартизувати спосіб, у який API відображаються, навіть якщо ці API на основі CRD не є справжньою частиною агрегатного шару.

Ключове зауваження

Kubernetes є розширюваним: Kubernetes надає гнучкі механізми, такі як кастомні контролери, CRD і агрегатний шар, щоб розширювати його функціональність і адаптувати до різних сценаріїв використання.
API на основі CRD і агреговані API можуть виглядати схоже у списках API Kubernetes, але вони суттєво різняться: CRD повністю керуються Kubernetes, тоді як агреговані API залежать від зовнішніх серверів. Розуміння цих відмінностей допомагає вибрати правильний підхід для розширення Kubernetes в залежності від ваших специфічних потреб.

Перекладено з: Extending Kubernetes API: A Guide to Custom Controllers and the Aggregate Layer