Словник для операторів Kubernetes

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

---

Шаблон оператора

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

• “Ми створили оператор для керування кластерами PostgreSQL. Замість вручну запускати скрипти відключення, оператор моніторить стан кластера і запускає автоматичне відключення, коли первинний стає невідповідним.”*
• “Операторний шаблон є найціннішим для станових програм, які вимагають складного керування життєвим циклом — баз даних, черг повідомлень, індексів пошуку.” *

---

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

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

• “Ми визначили PostgresCluster CRD з полями для кількості реплік, класу зберігання і розкладу резервування. Розробник може створити новий кластер з одним YAML-маніфестом.”* “Схема CRD перевіряє поля в нетиповому ресурсі — якщо розробник надає невірне значення, Kubernetes відкидає манифест перед тим, як він досягне контролера.”

---

Контрольна петля

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

• “Контролер розгортання запускає цикл: він перевіряє скільки підсистем працює, порівнює їх з бажаною кількістю реплік у специфікації і створює або вилучає підсистеми, щоб заповнити прогалини.” *
• “Пелети контролера запускаються за рівнем, а не за межами. Контролер діє на поточний стан, а не на події — тому він буде періодично перепримирюватися, навіть якщо нічого не зміниться.»*

---

Reconcile

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

• “Функція примирення отримує назву ресурсу, який викликав подію. Він отримує поточний стан з сервера API, порівнює його з бажаним станом і застосовує будь-які необхідні зміни. ”* “Функції примирення повинні бути ідемпотентними: виклик їх декілька разів з тим же вхідним сигналом завжди повинен дати той самий результат.”

---

Watch

** watch ** — це потокове викликання API, яке сповіщає контролер про зміну ресурсу — подію створити, оновити або вилучити. Контролери використовують годинники, а не опитування, щоб ефективно отримувати зміни.

• “Контролер стежить за змінами ресурсів PostgresCluster у всіх просторах імен. Коли створюється новий кластер, годинник викликає подію примирення. ”* “Годинник підтримується в сховищі etcd сервера API Kubernetes. Під високою навантаженням, події спостереження можуть бути відкладені - ваш контролер повинен обробляти можливу послідовність граціозно.”

---

Patch

** Латка ** це часткове оновлення ресурсу Kubernetes. Замість заміни всього ресурсу, латка застосовує лише змінені поля. Поширені типи латок в Kubernetes включають JSON merge patch і server-side apply.

• “Контролер латить підресурс status, щоб оновити кількість readyReplicas без зміни специфікації.” * “Використовуйте server-side apply, коли декільком учасникам потрібно керувати полями в одному ресурсі — це відстежує власника поля і запобігає конфліктам.”

---

Умови статусу

** Умови стану ** є стандартним шаблоном у Kubernetes для повідомлення стану ресурсу користувачам та іншим системам. Умова має тип (наприклад, Ready, Degraded, Progressing ), стан (True, False, Unknown ), причину (машинно-читальний код) і повідомлення (людсько-читане пояснення).

“Наш оператор встановлює умову Ready на False з причиною PrimaryUnreachable і повідомленням, що пояснює, що первинна репліка не відповіла на перевірки стану за 30 секунд.”

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

---

Введення Webhook

admission webhook це зворотний виклик HTTP, який перехоплює запити на сервер API Kubernetes перед тим, як вони будуть передані до etcd. Існує два типи:

• ** Зміна webhook прийняття** — може змінювати вхідний ресурс
• ** Перевірка webhook прийняття ** — може прийняти або відхилити вхідний ресурс

“Наш webhook з мутацією вставляє контейнер sidecar у кожен під у просторах імен, що мають позначку monitored: true, не вимагаючи від розробників додавати його вручну до їхніх манифестів.” “Наш перевіряючий webhook відкидає будь-який ресурс PostgresCluster, який вимагає більше 10 ТБ пам’яті — це запобігає випадковому надмірному забезпеченню, яке перевищує наш бюджет хмарного зберігання.”

---

Finaliser

** finaliser ** це поле в ресурсі Kubernetes, яке запобігає вилученням ресурсу до завершення певних завдань очищення. Контролер відповідає за виконання цих завдань, а потім за вилучення фіналіста.

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

---

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

• “Функція примирення повинна бути ідемпотентною — ми можемо викликати її декілька разів для однієї події.”
• “Ми використовуємо серверні програми для керування специфікацією розгортання, щоб декілька контролерів не вступали в конфлікт.”
• • “Веб- гачок прийняття відкидає будь- який ресурс, який не містить мітки центру витрат.” *
• “Схема CRD використовує перевірку OpenAPI v3 для забезпечення того, щоб replicas було між 1 і 10.”
• “Умови стану показують Degraded: True — оператор виявив, що одна репліка не відповідає.”
• • « Фіналізатор блокує вилучення, оскільки завдання очищення S3 все ще запущено. » *

---

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

Науковий напрямок: «Технічні засоби навігації»

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

Наприклад, уявіть ситуацію під час перегляду коду: « Цикл контролера не ефективно узгоджує підсистему ». Людина, для якої англійська мова є рідною, мабуть, зрозуміє, що мова йде про автоматизований процес перевірки та виправлення змін у ресурсах. Однак, хтось, хто вивчає термінологію, може пропустити тонкі наслідки - можливо, петля займає занадто багато часу, або вона не реагує достатньо швидко на зміну. Додавши контекст, наприклад, «Вік примирення петлі контролера в даний час перевищує нашу цільову оцінку в 5 секунд, що може вплинути на служби нижче по течії», негайно прояснює проблему і звертає увагу на вимірювану проблему, а не просто заявляє абстрактну концепцію. Аналогічно, в Slack, просто сказати «Застосований латок» не допомагає - замість цього, описуючи * чому * ви залатали його («Застосовано латок для розв’язання проблеми з пробою готовності»), надає цінну інформацію для будь-кого, хто переглядає зміну.

Інша поширена область плутанини виникає навколо «статусних умов». Багато не-рідних англомовних людей борються з цим терміном, тому що він такий абстрактний. Важливо перекласти « У модуля є стан TransientLackOfAvailable » на щось більш зрозуміле, наприклад, « У модуля зараз є періодична проблема, яка буде автоматично вирішена контролером ». Розбиття жаргону і пояснення * наслідків * стану — що це тимчасове і обробляється — може запобігти небажаному тривожності або неправильному тлумаченню. Сфокусування на результаті, а не просто на назву технічного стану покращує ясність.

Нарешті, пам’ ятайте, що опис змін у запиті на завантаження має значення. Замість того, щоб просто сказати « Оновлене розгортання », розгляньте « Рефакторизоване розгортання для використання нової версії образу з поліпшеним показником продуктивності » — останнє забезпечує контекст навколо * чому * зміна була зроблена і її очікуваний вплив. Ці невеликі зміни мови можуть значно зменшити неоднозначність і сприяти більш продуктивним розмовам у вашому середовищі Kubernetes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:latest

Цей приклад розгортання YAML показує основні налаштування. У полі replicas вказано бажану кількість запущених підсистем, а у розділі template визначено специфікації контейнера для кожної підсистеми. Зрозуміння цих елементів є фундаментальним для управління розгортанням Kubernetes і забезпечення їх функціонування за призначенням.