Англійський словник для операторів Kubernetes

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

---

Концепція операційної системи

Визначення нетипового ресурсу (CRD)

** Нетипове визначення ресурсу ** (CRD) є розширенням API Kubernetes, яке дозволяє визначати власні типи ресурсів. Після того, як CRD зареєстровано, API Kubernetes обробляє екземпляри цього ресурсу так само, як і вбудовані об’єкти, такі як Pods або Services.

“Ми визначили CRD під назвою DatabaseCluster, щоб команди могли запитувати керовані екземпляри Postgres за допомогою стандартних команд kubectl.”

“Перед тим, як розгорнути оператора, переконайтеся, що встановлено CRD — інакше контролер не буде мати типу для спостереження.”

Нетиповий ресурс (CR)

** Нетиповий ресурс ** — це екземпляр типу, визначеного за допомогою CRD. Це об’ єкт, який користувачі створюють для визначення бажаного стану.

• “Команда створила нетиповий ресурс, який вказує кластер Redis з трьох вузлів. Оператор виявив новий CR і почав забезпечення.”*

Operator

У Kubernetes, operator є програмним розширенням, яке використовує нетипові ресурси для керування програмами та їх компонентами. Термін був введений CoreOS в 2016 році.

• “Ми написали оператор для автоматичного оброблення планування резервування, відключення і оновлення версій для наших кластерів Kafka.” *

---

Схема примирення

Примирення

Цикл примирення (також званий циклом контролю) є основним механізмом оператора Kubernetes. Контролер стежить за змінами у ресурсах, порівнює * бажаний стан * (спеціфікацію) з * фактичним станом * (станом) і виконує дії, щоб вирівняти їх.

• “Перетвірка виявила, що кількість реплік у специфікації становить три, але працювали лише два підсистеми, тому було створено третю.” *

• “Піксель примирення нашого контролера запускається кожні тридцять секунд і також запускається при будь- якій зміні ресурсу, за яким слідкують.” *

Порівняння бажаного стану з фактичним

Ці дві концепції лежать в основі всіх Kubernetes:

• ** Бажання стану ** — те, що ви оголошуєте у специфікації ресурсу
• ** Поточне стан ** — поточний стан виконання у кластері

“Задача примирителя - це закрити прогалину між бажаним станом і фактичним станом. Якщо вони збігаються, це нічого не робить.»

Idempotency

Цикл примирення має бути ** неможливим ** — запуск його декілька разів з тим же вхідним сигналом має дати той самий результат без небажаних побічних ефектів.

• “У нас була помилка, коли програма порівняння створювала дублікат карти налаштувань на кожному циклі. Виправлення полягало в тому, щоб перевірити існування перед створенням — зробити операцію idempotent.”*

---

Внутрішнє управління

Нетиповий контролер

** Нетиповий контролер ** — це компонент мови Go (або іншої мови), який реалізує логіку примирення. Він стежить за змінами в API Kubernetes і відповідно реагує.

• “Нетиповий контролер слухає кеш інформатора і створює черги робочих елементів щоразу, коли змінюється ресурс, за яким слідкують.” *

Інформатор і спостерігач

** informer ** — це кешований, керований подією механізм спостереження за змінами ресурсів без безпосереднього опитування сервера API.

“Ми використовуємо інформатора для спостереження за змінами в нашому CRD і пов’ язаних з ним ConfigMaps, отже контролер запускатиметься лише у разі зміни чогось важливого.”

Finalizer

** finalizer ** — це поле на ресурсі, яке запобігає його вилученню до тих пір, поки контролер не завершить завдання з очищення.

“Ми додали фіналізатор, щоб коли користувач вилучає DatabaseCluster, оператор спочатку робить остаточну резервну копію, перш ніж дозволити Kubernetes вилучити об’єкт.”

---

Веб-портал Прикарпаття

Введення Webhook

** webhook прийому ** це зворотний виклик HTTP, який сервер API Kubernetes викликає перед тим, як зберегти ресурс. Існує два типи:

• ** Перевірка webhook прийняття ** — перевіряє запит і приймає або відкидає його
• ** webhook з дозволом зміни ** — може змінювати об’ єкт перед його збереженням

• “Наш мутуючий webhook автоматично вставляє контейнер sidecar в кожен Pod, який запитує анотацію observability: enabled.” *

“Перевіряючий webhook відкидає будь- яке розгортання, яке не встановлює обмеження на обсяг процесора і пам’ яті — застосовуючи нашу політику ресурсів до всіх просторів імен.”

Керування сертифікатами Webhook

Для доступу до webhooks потрібні сертифікати TLS. На практиці команди використовують cert-manager для автоматизації цього.

“Ми використовували cert-manager для забезпечення та зміни сертифіката TLS для нашого webhook для прийому, тому нам не потрібно керувати терміном дії сертифіката вручну.”

---

Оператор зрілості і шаблонів

Операторна модель зрілості

** Модель зрілості оператора ** описує п’ ять рівнів можливостей оператора, від базового встановлення до повної автоматизації:

1. ** Базове встановлення ** — автоматичне забезпечення програм
2. ** Безперервне оновлення ** — кероване оновлення і відновлення
3. Повний життєвий цикл — резервування, відновлення, масштабування
4. ** Deep Insights ** — метричні дані, панелі, попередження
5. ** Автопілот ** — автоматичне масштабування і налаштування

“Наш оператор бази даних знаходиться на рівні 3 — він автоматично обробляє резервування і відновлення, але ми ще не реалізували автоматичне налаштування.”

Список власників

** Посилання на власника ** створюють зв’ язок батьківський- дочірній між ресурсами. Коли батьківський об’ єкт вилучається, Kubernetes автоматично збирає сміття з дочірніх об’ єктів.

“Оператор встановлює посилання власника на створені ним ConfigMaps і Служби, щоб їх було автоматично очищено при вилученні батьківського екземпляра CRD.”

---

Практичні фрази для роботи оператора

• “Примиритель обнаружил дрейф между желаемым и фактическим состоянием и переходит в следующий.”
• • “Ми маємо додати фіналізатор, щоб забезпечити виконання операцій очищення перед вилученням об’ єкта з etcd.” *
• • “Веб- гачок для прийняття відкидає запити, які не містять необхідних міток.” *
• “Наша схема CRD використовує перевірку OpenAPI для відкидання некоректних значень полів під час прийняття.”
• • “Оператор є ідемпотентним — ви можете безпечно повторити прирівнювання без побічних ефектів.” *

---

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

Наприклад, слово «навигація» означає: пошук невідомих об’єктів

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

Одним з повторюваних питань є відмінність між «бажаним станом» і «фактичним станом». Багато команд спочатку перекладають це буквально з їх рідної мови, припускаючи пряму еквівалентність. Однак, в Kubernetes, бажаний стан є декларативним представленням того, як ви *бажаєте, щоб виглядав ваш кластер — визначений CRD (Custom Resource Definitions). * Фактичний стан * — це те, як він * зараз * виглядає. Петлі примирення постійно працюють, щоб наблизити поточний стан до бажаного стану, але завжди існує невід’ ємна можливість дрейфу через зовнішні зміни або непередбачені обставини. Важливо підкреслити, що «бажаний стан» не є обіцянкою ідеального вирівнювання; це мета, якою активно керується. Наприклад, при перегляді PR для нового розгортання, ви можете побачити коментар на кшталт: «Поле replicas в Deployment CRD встановлено на 3, але я бачу 2 піди, що працюють. Будь ласка, перевірте цикл примирення і переконайтеся, що він правильно масштабує програму. » Зауважте, що цей текст написано дуже обережно — він не звинувачує жодного користувача у помилці, а зосереджується на різниці між наміром і реальністю у системі.

Іншою складною областю є використання дієслів, пов’ язаних з контролем і автоматикою. Фрази на кшталт «пригнічення» або «активація» можуть бути неправильно інтерпретовані. Загалом краще використовувати такі терміни, як «оркестрація» або «керування», коли мова йде про операції Kubernetes. Уявіть повідомлення Slack, у якому обговорюється проблема: « Хтось повідомив, що webhook для прийому не запускає оновлення облікового запису служби ». Яскравішим варіантом буде « Webhook для прийому неправильно керує переходом облікового запису служби ». Таким чином уникається натяку на активну, негайну подію і підкреслюється триваючий процес керування.

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

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: deployments.example.com
spec:
  group: example.com
  versions:
    - name: v1alpha1
      servedVersioning: true
      schema:
        openTypes:
          "Pod": ["pod"]
        subresources:
          status: {}
  scope: Namespaced

Цей CRD визначає ресурс Deployment в просторі імен example.com, використовуючи групу розширення API apiextensions.k8s.io/v1beta1. Розділ versions містить схему для цього нетипового типу ресурсу, що дозволяє майбутнє версування і еволюцію визначення. scope: Namespaced вказує, що ці розгортання існуватимуть тільки в межах певного простору імен, а не в кластері.