Розширення можливостей Kubernetes

Kubernetes добре налаштовується та розширюється. Тому потреба робити форк або надсилати патчі до коду проєкту Kubernetes виникає рідко.

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

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

Конфігурація

Файли конфігурації та аргументи командного рядка описано в розділі Довідник онлайн-документації, де для кожного бінарного файлу є окрема сторінка:

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• kubelet
• kube-proxy

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

Вбудовані API політик, такі як ResourceQuota, NetworkPolicy та керування доступом на основі ролей (RBAC), є вбудованими API Kubernetes, які надають декларативно налаштовувані параметри політик. Ці API зазвичай доступні навіть у сервісах Kubernetes, що надаються провайдером, та в керованих інсталяціях Kubernetes. Вбудовані API політик дотримуються тих самих домовленостей, що й інші ресурси Kubernetes, такі як Podʼи. Коли ви використовуєте стабільний API політик, ви отримуєте переваги визначеної політики підтримки, як і для інших API Kubernetes. З цих причин, де це доречно, рекомендується використовувати API політик, а не файли конфігурації та аргументи командного рядка.

Розширення

Розширення — це програмні компоненти, які розширюють Kubernetes і глибоко з ним інтегруються. Вони адаптують його для підтримки нових типів ресурсів і нових видів обладнання.

Багато адміністраторів кластерів використовують екземпляри Kubernetes, що надаються провайдером, або встановлені з дистрибутива. У таких кластерах розширення вже попередньо встановлено. Тому більшості користувачів Kubernetes не потрібно встановлювати розширення, і ще меншій кількості потрібно створювати нові.

Шаблони розширень

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

Існує особливий шаблон написання клієнтських програм, які добре працюють із Kubernetes, відомий як шаблон контролера. Контролери зазвичай читають .spec обʼєкта, можливо, виконують певні дії, а потім оновлюють .status обʼєкта.

Контролер є клієнтом API Kubernetes. Коли Kubernetes є клієнтом і звертається до віддаленого сервісу, Kubernetes називає це вебхуком. Віддалений сервіс називається бекендом вебхука. Як і власні контролери, вебхуки додають точку відмови.

У моделі вебхуків Kubernetes надсилає мережевий запит до віддаленого сервісу. В альтернативній моделі бінарних втулків Kubernetes виконує бінарний файл (програму). Бінарні втулки використовуються в kubelet (наприклад, втулки сховища CSI та мережеві втулки CNI), а також у kubectl (дивіться Розширення kubectl за допомогою втулків).

Точки розширення

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

Пояснення до діаграми

1. Користувачі часто взаємодіють з API Kubernetes через kubectl. Втулки налаштовують поведінку клієнтів. Існують загальні розширення, які можна застосовувати до різних клієнтів, а також спеціальні способи розширення kubectl.

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

3. API-сервер обслуговує різні види ресурсів. Вбудовані види ресурсів, такі як pods, визначені проєктом Kubernetes і не можуть бути змінені. Про розширення API Kubernetes читайте в розділі Розширення API.

4. Планувальник Kubernetes вирішує, на яких вузлах розмістити Podʼи. Існує кілька способів розширити планування, вони описані в розділі Розширення планувальника.

5. Значну частину поведінки Kubernetes реалізовано програмами, які називаються контролерами і є клієнтами API-сервера. Контролери часто використовуються разом із власними ресурсами. Докладніше читайте в розділах Поєднання нових API з автоматизацією та Зміна вбудованих ресурсів.

6. kubelet працює на серверах (вузлах) і допомагає Podʼам виглядати як віртуальні сервери з власними IP-адресами в мережі кластера. Мережеві втулки дозволяють різні реалізації мережі Podʼів.

7. Ви можете використовувати втулки пристроїв, щоб інтегрувати власне обладнання або інші спеціальні локальні можливості вузла і зробити їх доступними для Podʼів, що працюють у вашому кластері. kubelet містить підтримку роботи з втулками пристроїв.

   kubelet також монтує та демонтує томи для Podʼів та їхніх контейнерів. Ви можете використовувати втулки сховища, щоб додати підтримку нових видів сховища та інших типів томів.

Блок-схема вибору точки розширення

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

Розширення клієнта

Втулки для kubectl — це окремі бінарні файли, які додають або замінюють поведінку певних підкоманд. Інструмент kubectl також може інтегруватися з втулками облікових даних. Ці розширення впливають лише на локальне середовище окремого користувача, тому не можуть застосовувати політики для всього кластера.

Якщо ви хочете розширити інструмент kubectl, прочитайте Розширення kubectl за допомогою втулків.

Розширення API

Визначення власних ресурсів

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

Докладніше про власні ресурси дивіться на сторінці Власні ресурси.

Шар агрегації API

Ви можете використовувати шар агрегації API Kubernetes, щоб інтегрувати API Kubernetes з додатковими сервісами, такими як Metrics API.

Поєднання нових API з автоматизацією

Поєднання API власного ресурсу та циклу управління називається шаблоном контролера. Якщо ваш контролер заміняє оператора-людину, який розгортає інфраструктуру на основі бажаного стану, то він також може дотримуватися шаблону Operator. Шаблон Operator використовується для керування конкретними застосунками; зазвичай це застосунки, які зберігають стан і потребують уважного керування.

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

Зміна вбудованих ресурсів

Коли ви розширюєте API Kubernetes, додаючи власні ресурси, додані ресурси завжди потрапляють до нової групи API. Ви не можете замінити чи змінити наявні групи API. Додавання API не дає прямого впливу на поведінку наявних API (таких як Podʼи), тоді як розширення доступу до API це дозволяють.

Розширення доступу до API

Коли запит потрапляє до API-сервера Kubernetes, він спочатку автентифікується, потім авторизується, а потім проходить різні типи контролю допуску (деякі запити насправді не автентифікуються й обробляються особливим чином). Докладніше про цей процес дивіться в розділі Керування доступом до API Kubernetes.

Кожен крок процесу автентифікації/авторизації в Kubernetes пропонує точки розширення.

Автентифікація

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

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

Авторизація

Авторизація визначає, чи можуть певні користувачі читати, записувати та виконувати інші операції з ресурсами API. Вона працює на рівні цілих ресурсів і не розрізняє їх за довільними полями обʼєктів.

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

Динамічний контроль допуску

Після авторизації запит, якщо це операція запису, також проходить кроки контролю допуску. На додаток до вбудованих кроків є кілька розширень:

• Вебхук Image Policy обмежує, які образи можна запускати в контейнерах.
• Для прийняття довільних рішень щодо контролю допуску можна використовувати загальний вебхук допуску. Вебхуки допуску можуть відхиляти створення або оновлення. Деякі вебхуки допуску змінюють дані вхідного запиту до того, як Kubernetes обробить його далі.

Розширення інфраструктури

Втулки пристроїв

Втулки пристроїв дозволяють вузлу виявляти нові ресурси вузла (на додаток до вбудованих, таких як cpu та memory) за допомогою втулка пристроїв.

Втулки сховища

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

Kubernetes також містить підтримку втулків FlexVolume, які застаріли з Kubernetes v1.23 (на користь CSI).

Втулки FlexVolume дозволяють користувачам монтувати типи томів, які Kubernetes не підтримує нативно. Коли ви запускаєте Pod, який залежить від сховища FlexVolume, kubelet викликає бінарний втулок для монтування тому. Більше подробиць про цей підхід є в архівній проєктній пропозиції FlexVolume.

Kubernetes Volume Plugin FAQ for Storage Vendors містить загальну інформацію про втулки сховища.

Мережеві втулки

Вашому кластеру Kubernetes потрібен мережевий втулок, щоб мати робочу мережу Podʼів і підтримувати інші аспекти мережевої моделі Kubernetes.

Мережеві втулки дозволяють Kubernetes працювати з різними мережевими топологіями та технологіями.

Втулки kubelet image credential provider

Постачальники облікових даних образів kubelet (kubelet image credential providers) — це втулки, які дозволяють kubelet динамічно отримувати облікові дані реєстрів образів. Ці облікові дані потім використовуються під час завантаження образів із реєстрів образів контейнерів, які відповідають конфігурації.

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

Подробиці налаштування втулка дивіться на сторінці Налаштування kubelet image credential provider.

Розширення планувальника

Планувальник — це особливий тип контролера, який стежить за Podʼами та призначає їх вузлам. Стандартний планувальник можна повністю замінити, продовжуючи використовувати інші компоненти Kubernetes, або ж одночасно запускати кілька планувальників.

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

Ви можете контролювати, які втулки планування активні, або привʼязувати набори втулків до різних іменованих профілів планувальника. Ви також можете написати власний втулок, який інтегрується з однією або кількома точками розширення kube-scheduler.

Нарешті, вбудований компонент kube-scheduler підтримує вебхук, який дозволяє віддаленому HTTP-бекенду (розширенню планувальника) фільтрувати та/або пріоритизувати вузли, які kube-scheduler обирає для Podʼа.

Що далі

• Дізнайтеся більше про розширення інфраструктури
  • Втулки пристроїв
  • Мережеві втулки
  • Втулки сховища CSI
• Дізнайтеся про втулки kubectl
• Дізнайтеся більше про власні ресурси
• Дізнайтеся більше про API-сервери розширення
• Дізнайтеся про динамічний контроль допуску
• Дізнайтеся про шаблон Operator