Для надсилання викликів до API Kubernetes використовуючи одну з мов програмування ви можете використовувати клієнтські бібліотеки. Офіційно підтримуються наступні:
Список портів та протоколів, які повинні бути відкриті на вузлах панелі управління та робочих вузлах.
Конфігураційні API
Цей розділ містить документацію для "неопублікованих" API, які використовуються для налаштування компонентів або інструментів Kubernetes. Більшість з цих API не експонуються через API-сервер у стилі REST, хоча вони є важливими для користувача чи оператора для використання або управління кластером.
Цей розділ містить довідкову інформацію про API Kubernetes.
REST API є фундаментальною основою Kubernetes. Усі операції та комунікації між компонентами та зовнішніми командами користувачів є викликами REST API, які обробляє API-сервер. Внаслідок цього все в Kubernetes обробляється як обʼєкти API та має відповідний запис в API.
Для отримання загальної інформації, читайте API Kubernetes. Керування доступом до API Kubernetes описує, як клієнти можуть автентифікуватися до сервера API Kubernetes, та як їхні запити авторизуються.
Версіювання API
Схеми серіалізації JSON та Protobuf слідують однаковими принципами для змін схеми. Наступні описи стосуються обох форматів.
Версіювання API та версіювання програмного забезпечення непрямо повʼязані. Пропозиція з версіювання API та релізів описує відносини між версіюванням API та версіюванням програмного забезпечення.
Різні версії API вказують на різні рівні стабільності та підтримки. Докладнішу інформацію про критерії кожного рівня можна знайти в документації API Changes.
Ось короткий огляд кожного рівня:
Alpha:
Назви версій містять alpha (наприклад, v1alpha1).
Вбудовані версії API рівня alpha типово вимкнені та повинні бути явно увімкнені в конфігурації kube-apiserver для використання.
Програмне забезпечення може містити помилки. Увімкнення функції може виявити помилки.
Підтримка alpha API може бути відключена в будь-який момент без попередження.
API може змінитися несумісним чином у подальших версіях програмного забезпечення без попередження.
Рекомендується використовувати програмне забезпечення тільки в тестових кластерах для короткочасного тестування через збільшений ризик помилок та відсутність довгострокової підтримки.
Beta:
Назви версій містять beta (наприклад, v2beta3).
Вбудовані версії API рівня beta типово вимкнені та повинні бути явно увімкнені в конфігурації kube-apiserver для використання (за винятком бета-версій API, представлених до Kubernetes 1.22, які були типово увімкнені).
Вбудовані версії API рівня beta мають максимальний термін служби 9 місяців або 3 мінорні випуски (в залежності, що довше), починаючи від введення до застаріння, і 9 місяців або 3 мінорні випуски (в залежності, що довше) від застаріння до вилучення.
Програмне забезпечення добре протестоване. Увімкнення функції вважається безпечним.
Підтримка функції не буде відключена, хоча можуть змінитися деталі.
Схема та/або семантика обʼєктів може змінюватися несумісним чином у подальших версіях API рівня beta або стабільного. Коли це відбувається, надаються інструкції з міграції. Адаптація до наступної версії API рівня beta або стабільного може вимагати редагування чи повторного створення обʼєктів API, і це може бути не простим. Міграція може вимагати перерви у роботі застосунків, які покладаються на цю функцію.
Програмне забезпечення не рекомендується для використання в промисловій експлуатації. Подальші випуски можуть вносити несумісні зміни. Використання версій API рівня beta обовʼязкове для переходу до наступних версій API рівня beta або стабільного, якщо версія API рівня beta застаріє та більше не буде обслуговуватися.
Примітка:
Спробуйте бета-функції та надавайте відгуки. Після того, як функції вийдуть з бета, може бути непрактично вносити більше змін.
Stable:
Назва версії — vX, де X – це ціле число.
Стабільні версії API залишаються доступними для всіх майбутніх випусків в межах основної версії Kubernetes, і немає поточних планів щодо ревізії основної версії Kubernetes, що вилучає стабільні API.
Групи API
Групи API спрощують розширення API Kubernetes. Група API вказується в REST-шляху та в полі apiVersion серіалізованого обʼєкта.
У Kubernetes існує кілька груп API:
core (також називається legacy) група знаходиться за REST-шляхом /api/v1. Основна група не вказується як частина поля apiVersion, наприклад, apiVersion: v1.
Названі групи знаходяться за REST-шляхом /apis/$GROUP_NAME/$VERSION та використовують apiVersion: $GROUP_NAME/$VERSION (наприклад, apiVersion: batch/v1). Повний список підтримуваних груп API можна знайти в довіднику API Kubernetes.
Увімкнення чи вимкнення груп API
Деякі ресурси та групи API типово увімкнені. Ви можете увімкнути чи вимкнути їх, встановивши --runtime-config на API-сервері. Прапорець --runtime-config приймає розділені комами пари <key>[=<value>], що описують конфігурацію запуску API-сервера. Якщо частина =<value> пропущена, вона розглядається так, ніби вказано =true. Наприклад:
для вимкнення batch/v1 встановіть --runtime-config=batch/v1=false
для увімкнення batch/v2alpha1 встановіть --runtime-config=batch/v2alpha1
для увімкнення конкретної версії API, наприклад, storage.k8s.io/v1beta1/csistoragecapacities, встановіть --runtime-config=storage.k8s.io/v1beta1/csistoragecapacities
Примітка:
При увімкненні чи вимкненні груп, чи ресурсів потрібно перезапустити API-сервер та controller manager, щоб внести зміни до --runtime-config.
Збереження
Kubernetes зберігає свій серіалізований стан у термінах ресурсів API, записуючи їх в etcd.
API Kubernetes — це програмний інтерфейс на основі ресурсів (RESTful), який надається через HTTP. Він підтримує отримання, створення, оновлення та видалення основних ресурсів за допомогою стандартних HTTP-дієслів (POST, PUT, PATCH, DELETE, GET).
Для деяких ресурсів API включає додаткові субресурси, що дозволяють детальніше налаштовувати авторизацію (наприклад, окремі представлення для деталей Pod та отримання логів), і може приймати та надавати ці ресурси в різних форматах для зручності або ефективності.
Kubernetes підтримує ефективні сповіщення про зміни ресурсів за допомогою watches. Kubernetes також забезпечує послідовні операції зі списками, щоб клієнти API могли ефективно кешувати, відстежувати та синхронізувати стан ресурсів.
Ви можете переглянути Довідник API онлайн або прочитати далі, щоб дізнатися про API загалом.
Терміни API Kubernetes
Kubernetes зазвичай використовує загальноприйняту термінологію RESTful для опису концепцій API:
Тип ресурсу — це назва, що використовується в URL (pods, namespaces, services)
Усі типи ресурсів мають конкретне представлення (їх схему обʼєкта), яке називається kind
Список екземплярів типу ресурсу називається колекцією
Окремий екземпляр типу ресурсу називається ресурсом і зазвичай представляє обʼєкт
Для деяких типів ресурсів API включає один або більше субресурсів, які представлені як URI-шляхи після назви ресурсу
Більшість типів ресурсів API Kubernetes є обʼєктами — вони представляють конкретний екземпляр концепції у кластері, як-от pod або namespace. Невелика кількість типів ресурсів API є віртуальними, оскільки вони часто представляють операції над обʼєктами, а не самі обʼєкти, такі як перевірка дозволів (використання POST із JSON-кодованим тілом SubjectAccessReview для ресурсу subjectaccessreviews), або субресурс eviction у Pod (використовується для запуску виселення, ініційованого API).
Імена обʼєктів
Усі обʼєкти, які ви можете створити через API, мають унікальне імʼя, що дозволяє ідемпотентне1 створення та отримання, за винятком віртуальних типів ресурсів, які можуть не мати унікальних імен, якщо вони не можуть бути отримані або не залежать від ідемпотентності. У межах простору імен може бути лише один обʼєкт з вказаним іменем для даного виду. Однак, якщо ви видалите обʼєкт, ви можете створити новий обʼєкт з тим самим іменем. Деякі обʼєкти не мають простору імен (наприклад: Nodes), тому їх імена повинні бути унікальними у всьому кластері.
Дієслова API
Майже всі типи ресурсів підтримують стандартні HTTP-дієслова — GET, POST, PUT, PATCH, та DELETE. Kubernetes також використовує власні дієслова, які часто пишуться малими літерами, щоб відрізняти їх від HTTP-дієслів.
Kubernetes використовує термін list для опису отримання колекції ресурсів, щоб відрізняти його від отримання одного ресурсу, яке зазвичай називається get. Якщо ви надішлете HTTP-запит GET із параметром ?watch, Kubernetes називає це watch, а не get (див.
Ефективне виявлення змін для деталей).
Для запитів PUT Kubernetes внутрішньо класифікує їх як create або update залежно від стану наявного обʼєкта. Update відрізняється від patch; HTTP-дієслово для patch - PATCH.
URI ресурсів
Усі типи ресурсів або належать кластеру (/apis/GROUP/VERSION/*), або простору імен (/apis/GROUP/VERSION/namespaces/NAMESPACE/*). Тип ресурсу, що належить простору імен, буде видалений при видаленні простору імен, і доступ до цього типу ресурсу контролюється перевірками авторизації в межах простору імен.
Примітка: основні ресурси використовують /api замість /apis і пропускають сегмент GROUP.
Ви також можете отримати доступ до колекцій ресурсів (наприклад, переліку усіх Nodes). Наступні шляхи використовуються для отримання колекцій та ресурсів:
Ресурси кластерного рівня:
GET /apis/GROUP/VERSION/RESOURCETYPE — повертає колекцію ресурсів вказаного типу ресурсу
GET /apis/GROUP/VERSION/RESOURCETYPE/NAME — повертає ресурс з імʼям NAME вказаного типу ресурсу
Ресурси рівня простору імен:
GET /apis/GROUP/VERSION/RESOURCETYPE — повертає колекцію всіх екземплярів вказаного типу ресурсу в усіх просторах імен
GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE — повертає колекцію всіх екземплярів вказаного типу ресурсу в просторі імен NAMESPACE
GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME — повертає екземпляр вказаного типу ресурсу з імʼям NAME в просторі імен NAMESPACE
Оскільки простір імен є ресурсом кластерного рівня, ви можете отримати перелік (“колекцію”) всіх просторів імен за допомогою GET /api/v1/namespaces та деталі про конкретний простір імен за допомогою GET /api/v1/namespaces/NAME.
Субресурс кластерного рівня: GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE
Субресурс рівня простору імен: GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE
Підтримувані дієслова для кожного субресурсу будуть відрізнятися залежно від обʼєкта — див. Довідник API для отримання додаткової інформації. Немає можливості отримати доступ до субресурсів через декілька ресурсів — зазвичай використовується новий віртуальний тип ресурсу, якщо це стає необхідним.
Ефективне виявлення змін
API Kubernetes дозволяє клієнтам зробити початковий запит на обʼєкт або колекцію, а потім відстежувати зміни з моменту цього запиту: це watch. Клієнти можуть відправити list або get і потім зробити наступний запит watch.
Для реалізації цього відстеження змін кожен обʼєкт Kubernetes має поле resourceVersion, яке представляє версію цього ресурсу, що зберігається в постійному шарі збереження. При отриманні колекції ресурсів (як простору імен, так і кластерного рівня), відповідь від сервера API містить значення resourceVersion. Клієнт може використовувати це значення resourceVersion для ініціювання watch проти сервера API.
Коли ви надсилаєте запит watch, сервер API відповідає потоком змін. Ці зміни перераховують результати операцій (таких як create, delete, та update), що відбулись після resourceVersion, значення якого було вказане як параметр до запиту watch. Загальний механізм watch дозволяє клієнту отримати поточний стан і потім підписатися на подальші зміни, не пропускаючи жодної події.
Якщо клієнт watch відʼєднується, тоді цей клієнт може розпочати новий сеанс watch з останнього повернутого resourceVersion; клієнт також може виконати новий запити get/list і розпочати знову. Див. Семантика версій ресурсів для отримання детальнішої інформації.
Наприклад:
Отримання списку всіх Podʼів у вказаному просторі імен.
GET /api/v1/namespaces/test/pods
---
200 OK
Content-Type: application/json
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {"resourceVersion":"10245"},
"items": [...]
}
Починаючи з версії ресурсу 10245, отримуйте сповіщення про будь-які операції API (такі як create, delete, patch або update), що впливають на Podʼи у просторі імен test. Кожне сповіщення про зміну — це документ JSON. Тіло відповіді HTTP (надається як application/json) складається із серії документів JSON.
Сервер Kubernetes буде зберігати історичний запис змін лише протягом обмеженого часу. Кластери, що використовують etcd 3, стандартно зберігають зміни за останні 5 хвилин. Коли запитувані операції watch не вдаються через недоступність історичної версії цього ресурсу, клієнти повинні обробляти цей випадок, розпізнаючи код статусу 410 Gone, очищаючи свій локальний кеш, виконуючи новий get або list запит, і починаючи watch з resourceVersion, яке було повернуто.
Для підписки на колекції бібліотеки клієнтів Kubernetes зазвичай пропонують певну форму стандартного інструменту для логіки list-потім-watch. (У бібліотеці клієнтів Go це називається Reflector і знаходиться в пакеті k8s.io/client-go/tools/cache).
Закладки для Watch
Щоб зменшити вплив короткого вікна історії, API Kubernetes надає подію спостереження під назвою BOOKMARK. Це особливий вид події, що позначає, що всі зміни до вказаної клієнтом resourceVersion вже були надіслані. Документ, що представляє подію BOOKMARK, має тип який отримується запитом, але включає лише поле .metadata.resourceVersion. Наприклад:
Як клієнт, ви можете запитувати події BOOKMARK, встановлюючи параметр запиту allowWatchBookmarks=true у запиті watch, але не слід припускати, що закладки будуть повертатися з певним інтервалом, і клієнти не можуть очікувати, що сервер API надішле будь-яку подію BOOKMARK, навіть якщо її було запитано.
Потокові списки
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.27 [alpha]
У великих кластерах отримання колекції деяких типів ресурсів може призвести до значного збільшення використання ресурсів (переважно RAM) панелі управління. Щоб зменшити цей вплив та спростити користування шаблоном list + watch, Kubernetes v1.27 вводить альфа-функцію підтримки запиту початкового стану (раніше запитуваного через запит list) як частини запиту watch.
За умови, що ввімкнено функціоналWatchList, це можна зробити, вказавши sendInitialEvents=true як параметр рядка запиту у запиті watch. Якщо встановлено, сервер API починає потік спостереження з синтетичних початкових подій (типу ADDED) для побудови всього стану всіх наявних обʼєктів, після чого йде подія BOOKMARK (якщо запитано через параметр allowWatchBookmarks=true). Подія закладки включає версію ресурсу, до якої його було синхронізовано. Після надсилання події закладки сервер API продовжує роботу як для будь-якого іншого запиту watch.
Коли ви встановлюєте sendInitialEvents=true у рядку запиту, Kubernetes також вимагає, щоб ви встановили resourceVersionMatch до значення NotOlderThan. Якщо ви вказали resourceVersion у рядку запиту без значення або не вказали його взагалі, це інтерпретується як запит на узгоджене читання (consistent read); подія закладки надсилається, коли стан синхронізовано щонайменше до моменту узгодженого читання з моменту, коли запит почав оброблятися. Якщо ви вказуєте resourceVersion (у рядку запиту), подія закладки надсилається, коли стан синхронізовано щонайменше до вказаної версії ресурсу.
Приклад
Приклад: ви хочете спостерігати за колекцією Podʼів. Для цієї колекції поточна версія ресурсу
становить 10245, і є два Podʼи: foo та bar. Надсилання наступного запиту (який явно запитує узгоджене читання, встановлюючи порожню версію ресурсу за допомогою resourceVersion=) може призвести до наступної послідовності подій:
Опція APIResponseCompression дозволяє серверу API стискати відповіді на запити get та list, зменшуючи використання мережевої пропускної здатності та покращуючи продуктивність у великих кластерах. Її стандартно увімкнено з Kubernetes 1.16 і її можна вимкнути додаванням APIResponseCompression=false у прапорець --feature-gates на сервері API.
Стиснення відповідей API може значно зменшити розмір відповіді, особливо для великих ресурсів або колекцій. Наприклад, запит list для Podʼів може повернути сотні кілобайт або навіть мегабайти даних, залежно від кількості Podʼів та їх атрибутів. Стиснення відповіді дозволяє зберегти мережеву пропускну здатність та зменшити затримки.
Щоб перевірити, чи працює APIResponseCompression, ви можете надіслати запит get або list на сервер API з заголовком Accept-Encoding та перевірити розмір відповіді та заголовки. Наприклад:
GET /api/v1/pods
Accept-Encoding: gzip
---
200 OK
Content-Type: application/json
content-encoding: gzip
...
Заголовок content-encoding вказує, що відповідь стиснута за допомогою gzip.
Отримання великих наборів результатів частинами
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.29 [stable]
У великих кластерах отримання колекції деяких типів ресурсів може призвести до дуже великих відповідей, що може вплинути на сервер та клієнта. Наприклад, у кластері може бути десятки тисяч Podʼів, кожен з яких еквівалентний приблизно 2 КіБ у форматі JSON. Отримання всіх Podʼів через всі простори імен може призвести до дуже великої відповіді (10-20 МБ) та спожити багато ресурсів сервера.
Сервер API Kubernetes підтримує можливість розбиття одного великого запиту на колекцію на багато менших частин, зберігаючи при цьому узгодженість загального запиту. Кожна частина може бути повернута послідовно, що зменшує загальний розмір запиту і дозволяє клієнтам, орієнтованим на користувачів, показувати результати поетапно для покращення швидкості реагування.
Ви можете запитувати сервер API для обробки list запиту, використовуючи сторінки (які Kubernetes називає chunks). Щоб отримати одну колекцію частинами, підтримуються два параметри запиту limit та continue у запитах до колекцій, і поле відповіді continue повертається з усіх операцій list у полі metadata колекції. Клієнт повинен вказати максимальну кількість результатів, яку він бажає отримати у кожній частині за допомогою limit, і сервер поверне кількість ресурсів у результаті не більше limit та включить значення continue, якщо у колекції є більше ресурсів.
Як клієнт API, ви можете передати це значення continue серверу API у наступному запиті, щоб вказати серверу повернути наступну сторінку (chunk) результатів. Продовжуючи до тих пір, поки сервер не поверне порожнє значення continue, ви можете отримати всю колекцію.
Як і у випадку з операцією watch, токен continue закінчується через короткий проміжок часу (стандартно 5 хвилин) і повертає 410 Gone, якщо більше результатів не може бути повернуто. У цьому випадку клієнт повинен буде почати з початку або опустити параметр limit.
Наприклад, якщо у кластері є 1,253 Podʼів і ви хочете отримувати частини по 500 Podʼів за раз, запитуйте ці частини наступним чином:
Отримати всі Podʼи в кластері, отримуючи до 500 Podʼів за раз.
Продовжити попередній запит, отримуючи останні 253 Podʼів.
GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN_2
---
200 OK
Content-Type: application/json
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {
"resourceVersion":"10245",
"continue": "", // токен continue порожній, тому що ми досягли кінця списку
...
},
"items": [...] // повертає Podʼи 1001-1253
}
Зверніть увагу, що resourceVersion колекції залишається постійним в кожному запиті, що вказує на те, що сервер показує вам узгоджену копію Podʼів. Podʼи, що створюються, оновлюються або видаляються після версії 10245, не будуть показані, якщо ви не зробите окремий запит list без токена continue. Це дозволяє вам розбивати великі запити на менші частини, а потім виконувати операцію watch на повному наборі, не пропускаючи жодного оновлення.
Поле remainingItemCount вказує кількість наступних елементів у колекції, які не включені у цю відповідь. Якщо запит list містив мітки або поля селектори, тоді кількість залишкових елементів невідома, і сервер API не включає поле remainingItemCount у свою відповідь. Якщо list запит завершено (або тому, що він не розбивається на частини, або тому, що це остання частина), то більше немає залишкових елементів, і сервер API не включає поле remainingItemCount у свою відповідь. Очікуване використання `remainingItemCount — оцінка розміру колекції.
Колекції
У термінології Kubernetes відповідь, яку ви отримуєте за допомогою list, є колекцією. Однак Kubernetes визначає конкретні види для колекцій різних типів ресурсів. Колекції мають вид, названий на честь виду ресурсу, з доданим List.
Коли ви надсилаєте запит API для певного типу, всі елементи, повернуті цим запитом, є цього типу. Наприклад, коли ви надсилаєте list Services, відповідь колекції має kind, встановлений на ServiceList; кожен елемент у цій колекції представляє один Service. Наприклад:
Є десятки типів колекцій (таких як PodList, ServiceList та NodeList), визначених в API Kubernetes. Ви можете отримати більше інформації про кожен тип колекції з довідника Kubernetes API.
Деякі інструменти, такі як kubectl, представляють механізм колекцій Kubernetes трохи інакше, ніж сам API Kubernetes. Оскільки вихідні дані kubectl можуть включати відповідь з декількох операцій list на рівні API, kubectl представляє список елементів, використовуючи kind: List. Наприклад:
Памʼятайте, що API Kubernetes не має kind з іменем List.
kind: List є клієнтським внутрішнім деталям реалізації для обробки колекцій, які можуть бути різними типами обʼєктів. Уникайте залежності від kind: List в автоматизації або іншому коді.
Отримання ресурсів у вигляді таблиць
Коли ви запускаєте kubectl get, стандартний формат виводу є простою табличною репрезентацією одного або кількох екземплярів певного типу ресурсу. У минулому клієнти повинні були відтворювати табличний і описовий вивід, реалізований у kubectl, щоб виконувати прості списки обʼєктів. Деякі обмеження цього підходу включають нетривіальну логіку при роботі з певними обʼєктами. Крім того, типи, надані API агрегуванням або сторонніми ресурсами, не відомі під час компіляції. Це означає, що повинні бути реалізовані загальні механізми для типів, які не розпізнаються клієнтом.
Щоб уникнути можливих обмежень, описаних вище, клієнти можуть запитувати табличну репрезентацію обʼєктів, делегуючи серверу специфічні деталі виводу. API Kubernetes реалізує стандартні HTTP-узгодження щодо типу контенту: передача заголовка Accept, що містить значення application/json;as=Table;g=meta.k8s.io;v=v1 з запитом GET попросить сервер повернути обʼєкти у форматі таблиці.
Наприклад, список усіх Podʼів у кластері у форматі таблиці.
GET /api/v1/pods
Accept: application/json;as=Table;g=meta.k8s.io;v=v1
---
200 OK
Content-Type: application/json
{
"kind": "Table",
"apiVersion": "meta.k8s.io/v1",
...
"columnDefinitions": [
...
]
}
Для типів ресурсів API, які не мають табличного визначення, відомого панелі управління, сервер API повертає стандартну таблицю, яка складається з полів name та creationTimestamp ресурсу.
Не всі типи ресурсів API підтримують табличну відповідь; наприклад, CustomResourceDefinitions можуть не визначати відповідність полів таблиці, а APIService, що розширює основний API Kubernetes може взагалі не обслуговувати табличні відповіді. Якщо ви створюєте клієнта, що використовує інформацію з таблиці та який повинен працювати з усіма типами ресурсів, включаючи розширення, ви повинні робити запити, які вказують кілька типів контенту у заголовку Accept. Наприклад:
Типово Kubernetes повертає обʼєкти, серіалізовані у форматі JSON з типом контенту application/json. Це станадртний формат серіалізації для API. Однак клієнти можуть запросити більш ефективне представлення у форматі Protobuf цих обʼєктів для покращення продуктивності в масштабі. API Kubernetes реалізує стандартні HTTP-узгодження щодо типу контенту: передача заголовка Accept з викликом GET запросить сервер повернути відповідь у вашому бажаному медіа-типі, тоді як надсилання обʼєкта у форматі Protobuf на сервер для виклику PUT або POST означає, що ви повинні відповідним чином встановити заголовок Content-Type.
Сервер поверне відповідь з заголовком Content-Type, якщо запитаний формат підтримується, або помилку 406 Not acceptable, якщо жоден з медіа-типів, які ви запросили, не підтримується. Усі вбудовані типи ресурсів підтримують медіа-тип application/json.
GET /api/v1/pods
Accept: application/vnd.kubernetes.protobuf
---
200 OK
Content-Type: application/vnd.kubernetes.protobuf
... binary encoded PodList object
Створення Podʼа, надсиланням даних у форматі Protobuf на сервер, але із запитом відповідіу форматі JSON.
POST /api/v1/namespaces/test/pods
Content-Type: application/vnd.kubernetes.protobuf
Accept: application/json
... binary encoded Pod object
---
200 OK
Content-Type: application/json
{
"kind": "Pod",
"apiVersion": "v1",
...
}
Не всі типи ресурсів API підтримують Protobuf; зокрема, Protobuf недоступний для ресурсів, визначених як CustomResourceDefinitions або обслуговуються через шар агрегації. Як клієнт, який може працювати з розширеними типами, ви повинні вказати кілька типів контенту у заголовку запиту Accept для підтримки відкату до JSON. Наприклад:
Kubernetes використовує обгортку для кодування відповідей Protobuf. Ця обгортка починається з 4-байтового магічного числа для ідентифікації контенту на диску або в etcd як Protobuf (на відміну від JSON), а потім слідує Protobuf-кодована обгортка повідомлення, яка описує кодування і тип основного обʼєкта, а потім містить сам обʼєкт.
Формат обгортки виглядає так:
Чотирибайтовий префікс магічного числа:
Байти 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00]
Кодоване повідомлення Protobuf з наступним IDL:
message Unknown {
// typeMeta повинен мати рядкові значення для "kind" та "apiVersion", встановлені на обʼєкті JSON
optional TypeMeta typeMeta = 1;
// raw буде містити повністю серіалізований обʼєкт у форматі Protobuf. Дивіться визначення Protobuf у клієнтських бібліотеках для певного kind.
optional bytes raw = 2;
// contentEncoding — це кодування, що використовується для raw даних. Відсутність означає відсутність кодування.
optional string contentEncoding = 3;
// contentType — це метод серіалізації, використаний для серіалізації 'raw'. Відсутність означає application/vnd.kubernetes.protobuf
// і зазвичай опускається.
optional string contentType = 4;
}
message TypeMeta {
// apiVersion — це група/версія для цього типу
optional string apiVersion = 1;
// kind — це назва схеми обʼєкта. Визначення Protobuf повинно існувати для цього обʼєкта.
optional string kind = 2;
}
Примітка:
Клієнти, які отримують відповідь у форматі application/vnd.kubernetes.protobuf, яка не відповідає очікуваному префіксу, повинні відхилити відповідь, оскільки майбутні версії можуть потребувати зміни формату серіалізації у несумісний спосіб і зроблять це, змінивши префікс.
Видалення ресурсів
Коли ви видаляєте ресурс, цей процес проходить у два етапи:
Коли клієнт вперше надсилає запит на видалення ресурсу, .metadata.deletionTimestamp встановлюється на поточний час. Після встановлення .metadata.deletionTimestamp, зовнішні контролери, які працюють з завершувачами (finalizers), можуть почати виконувати свою очистку в будь-який час, у будь-якому порядку.
Порядок не встановлюється примусово між завершувачами, оскільки це може призвести до значного ризику застрягання .metadata.finalizers.
Поле .metadata.finalizers є спільним: будь-який áктор з дозволом може змінювати його порядок.
Якби список завершувачів оброблявся по порядку, це могло б призвести до ситуації, коли компонент, відповідальний за перший завершувач у списку, чекає на якийсь сигнал (значення поля, зовнішню систему або інше), що створюється компонентом, відповідальним за завершувач пізніше у списку, що призводить до застярягання всього списку.
Без примусового впорядкування завершувачі можуть вільно визначати свій власний порядок і не є вразливими до змін у списку.
Після видалення останнього завершувача ресурс фактично видаляється з etcd.
API для одного ресурсу
API Kubernetes з дієсловами get, create, update, patch, delete та proxy підтримують тільки одиничні ресурси. Ці дієслова з підтримкою одиничного ресурсу не підтримують надсилання кількох ресурсів разом в упорядкованому або неупорядкованому списку чи транзакції.
Коли клієнти (включаючи kubectl) виконують дії з набором ресурсів, клієнт робить серію одиничних API запитів до ресурсу, а потім, за потреби, агрегує відповіді.
На відміну від цього, API Kubernetes з дієсловами list і watch дозволяють отримувати кілька ресурсів, а deletecollection дозволяє видаляти кілька ресурсів.
Валідація полів
Kubernetes завжди перевіряє тип полів. Наприклад, якщо поле в API визначене як число, ви не можете встановити це поле в текстове значення. Якщо поле визначене як масив рядків, ви можете надати тільки масив. Деякі поля можна пропустити, інші поля є обовʼязковими. Пропуск обовʼязкового поля у запиті API є помилкою.
Якщо ви зробите запит з додатковим полем, яке не розпізнається панеллю управління кластера, тоді поведінка сервера API є складнішою.
Типово, сервер API видаляє поля, які він не розпізнає, з вхідних даних, які він отримує (наприклад, тіло JSON запиту PUT).
Є дві ситуації, коли сервер API видаляє поля, які ви надали у HTTP-запиті.
Ці ситуації такі:
Поле не розпізнається, оскільки воно не входить до схеми OpenAPI ресурсу. (Одним винятком є CRDs, які явно обирають не обрізати невідомі поля через x-kubernetes-preserve-unknown-fields).
Поле дублюється в обʼєкті.
Валідація для нерозпізнаних або дубльованих полів
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.27 [stable]
З версії 1.25 і далі, нерозпізнані або дубльовані поля в обʼєкті виявляються через валідацію на сервері при використанні HTTP-дієслів, які можуть надсилати дані (POST, PUT та PATCH). Можливі рівні валідації: Ignore, Warn (стандартно) та Strict.
Ignore
Сервер API успішно обробляє запит так, ніби у ньому немає неправильних полів, відкидаючи всі невідомі та дубльовані поля та не повідомляючи про це.
Warn
(Стандартно) Сервер API успішно обробляє запит і надсилає клієнту попередження. Попередження надсилається за допомогою заголовка відповіді Warning:, додаючи один елемент попередження для кожного невідомого або дубльованого поля. Для отримання додаткової інформації про попередження та API Kubernetes дивіться статтю блогу Warning: Helpful Warnings Ahead.
Strict
Сервер API відхиляє запит з помилкою 400 Bad Request, коли виявляє будь-які невідомі або дубльовані поля. Повідомлення відповіді від сервера API вказує всі невідомі або дубльовані поля, які сервер API виявив.
Рівень валідації полів встановлюється параметром запиту fieldValidation.
Примітка:
Якщо ви надсилаєте запит, що вказує на нерозпізнане поле, яке також є недійсним з іншої причини (наприклад, запит надає рядкове значення, де API очікує цілого числа для відомого поля), тоді сервер API відповідає з помилкою 400 Bad Request, але не надасть жодної інформації про невідомі або дубльовані поля (тільки про ту фатальну помилку, яку він виявив першою).
У цьому випадку ви завжди отримаєте відповідь про помилку, незалежно від того, який рівень валідації полів ви запросили.
Інструменти, які надсилають запити на сервер (такі як kubectl), можуть встановлювати свої власні типові значення, які відрізняються від рівня валідації Warn, що стандартно використовується сервером API.
Інструмент kubectl використовує прапорець --validate для встановлення рівня валідації полів. Він приймає значення ignore, warn та strict, а також приймає значення true (еквівалентно strict) і false (еквівалентно ignore). Станадртне налаштування валідації для kubectl — це --validate=true, що означає сувору валідацію полів на стороні сервера.
Коли kubectl не може підключитися до сервера API з валідацією полів (сервери API до Kubernetes 1.27), він повернеться до використання валідації на стороні клієнта. Валідація на стороні клієнта буде повністю видалена у майбутній версії kubectl.
Примітка:
До Kubernetes 1.25 прапорець kubectl --validate використовувався для перемикання валідації на стороні клієнта увімквимкання/вимиканнямнено булевого прапореця.
Dry-run
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.19 [stable]
При використанні HTTP-дієслів, які можуть змінювати ресурси (POST, PUT, PATCH і DELETE), ви можете надіслати свій запит у режимі dry run. Режим dry run допомагає оцінити запит через типові етапи обробки запиту (ланцюг допумків, валідацію, конфлікти злиття) аж до збереження обʼєктів у сховищі. Тіло відповіді на запит є максимально наближеним до відповіді у режимі non-dry-run. Kubernetes гарантує, що dry-run запити не будуть збережені в сховищі і не матимуть жодних інших побічних ефектів.
Виконання dry-run запиту
Dry-run активується встановленням параметра запиту dryRun. Цей параметр є рядковим, діє як перерахування, і єдині прийнятні значення:
[без значення]
Дозволити побічні ефекти. Ви запитуєте це за допомогою рядка запиту типу ?dryRun або ?dryRun&pretty=true. Відповідь є остаточним обʼєктом, який був би збережений, або помилкою, якщо запит не може бути виконаний.
All
Кожен етап виконується як зазвичай, за винятком кінцевого етапу збереження, де побічні ефекти запобігаються.
Коли ви встановлюєте ?dryRun=All, усі відповідні контролерів допуску виконуються, перевіряючи запит після зміни, злиття виконується для PATCH, поля заповнюються станадартними значеннями, і проводиться валідація схеми. Зміни не зберігаються в базовому сховищі, але остаточний обʼєкт, який був би збережений, все ще повертається користувачеві разом із звичайним кодом статусу.
Якщо версія запиту без dry-run викликала б контролер доступу, який має побічні ефекти, запит буде відхилений, щоб уникнути небажаних побічних ефектів. Усі вбудовані втулки контролю доступу підтримують dry-run. Додатково, admission webhooks можуть оголосити у своїй конфігураційній моделі, що вони не мають побічних ефектів, встановивши поле sideEffects на None.
Примітка:
Якщо вебхук дійсно має побічні ефекти, то поле sideEffects має бути встановлено на "NoneOnDryRun". Ця зміна є доречною за умови, що вебхук також модифіковано щоб він розумів поле DryRun у AdmissionReview і для запобігання побічним ефектам на будь-який запит, позначений як dry run.
Приклад dry-run запиту, який використовує ?dryRun=All:
POST /api/v1/namespaces/test/pods?dryRun=All
Content-Type: application/json
Accept: application/json
Відповідь буде виглядати так само, як для запиту без dry-run, але значення деяких згенерованих полів можуть відрізнятися.
Згенеровані значення
Деякі значення обʼєкта зазвичай генеруються перед його збереженням. Важливо не покладатися на значення цих полів, встановлених dry-run запитом, оскільки ці значення, ймовірно, будуть відрізнятися в dry-run режимі від реального запиту. Деякі з цих полів:
name: якщо встановлено generateName, name матиме унікальне випадкове імʼя
creationTimestamp / deletionTimestamp: фіксує час створення/видалення
Для ресурсу Service: Порти або IP-адреси, які kube-apiserver надає обʼєктам Service
Авторизація dry-run
Авторизація для dry-run і non-dry-run запитів ідентична. Таким чином, щоб виконати dry-run запит, ви повинні мати дозвіл на виконання non-dry-run запиту.
Наприклад, щоб виконати dry-run patch для Deployment, ви повинні мати дозвіл на виконання цього patch. Ось приклад правила для Kubernetes RBAC, що дозволяє робити patch для Deployment:
Kubernetes надає декілька способів оновлення наявних обʼєктів. Ви можете прочитати вибір механізму оновлення, щоб дізнатися, який підхід найкраще підходить для вашого випадку.
Ви можете перезаписати (оновити) наявний ресурс, наприклад, ConfigMap, використовуючи HTTP PUT. Для запиту PUT відповідальність за вказання resourceVersion (отриманого з обʼєкта, що оновлюється) лежить на клієнті. Kubernetes використовує інформацію resourceVersion, щоб сервер API міг виявити втрачені оновлення і відхилити запити від клієнта, який не актуальний для кластера. У разі зміни ресурсу (коли resourceVersion, надана клієнтом, застаріла), сервер API повертає відповідь з помилкою 409 Conflict.
Замість надсилання запиту PUT клієнт може надіслати інструкцію серверу API для накладання патчу до наявного ресурсу. Патч зазвичай підходить, якщо зміна, яку клієнт хоче внести, не залежить від наявних даних. Клієнти, яким потрібне ефективне виявлення втрачених оновлень, повинні розглянути можливість зробити свій запит умовним до існуючого resourceVersion (або HTTP PUT, або HTTP PATCH), а потім обробити будь-які повтори, які можуть знадобитися у разі конфлікту.
API Kubernetes підтримує чотири різні операції PATCH, які визначаються відповідним заголовком HTTP Content-Type:
application/apply-patch+yaml
Серверне застосування YAML (специфічне розширення Kubernetes, засноване на YAML). Всі документи JSON є дійсними в YAML, тому ви також можете надавати JSON, використовуючи цей тип медіа. Дивіться серіалізація для серверного застосування для отримання додаткової інформації. Для Kubernetes це операція створення, якщо обʼєкт не існує, або операція накладання патчу, якщо обʼєкт вже існує.
application/json-patch+json
JSON Patch, як визначено в RFC6902. JSON патч — це послідовність операцій, які виконуються з ресурсом; наприклад, {"op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ]}. Для Kubernetes це операція накладання патчу. Патч з використанням application/json-patch+json може включати умови для перевірки консистентності, дозволяючи операції зазнати невдачі, якщо ці умови не виконуються (наприклад, щоб уникнути втрати оновлення).
application/merge-patch+json
JSON Merge Patch, як визначено в RFC7386. JSON Merge Patch фактично є частковим представленням ресурсу. Поданий JSON комбінується з поточним ресурсом для створення нового, а потім новий зберігається. Для Kubernetes це операція накладання патчу.
application/strategic-merge-patch+json
Strategic Merge Patch (специфічне розширення Kubernetes на основі JSON). Strategic Merge Patch — це власна реалізація JSON Merge Patch. Ви можете використовувати Strategic Merge Patch лише з вбудованими API або з агрегованими серверами API, які мають спеціальну підтримку для цього. Ви не можете використовувати application/strategic-merge-patch+json з будь-яким API, визначеним за допомогою CustomResourceDefinition.
Примітка:
Механізм серверного застосування Kubernetes замінив Strategic Merge Patch.
Функція Серверного застосування Kubernetes дозволяє панелі управління відстежувати керовані поля для новостворених обʼєктів. SСерверне застосування забезпечує чітку схему для управління конфліктами полів, пропонує серверні операції apply і update, та замінює функціональність на стороні клієнта kubectl apply.
Для серверного застосування Kubernetes обробляє запит як створення, якщо обʼєкт ще не існує, і як патч в іншому випадку. Для інших запитів, які використовують PATCH на рівні HTTP, логічна операція Kubernetes завжди є патч.
Операція оновлення (HTTP PUT) проста у виконанні та гнучка, але має недоліки:
Потрібно вирішувати конфлікти, де resourceVersion обʼєкта змінюється між моментом його читання клієнтом і спробою записувати назад. Kubernetes завжди виявляє конфлікт, але вам як авторові клієнта потрібно реалізувати повторні спроби.
Ви можете випадково видаляти поля, якщо декодуєте обʼєкт локально (наприклад, використовуючи client-go, ви можете отримати поля, які ваш клієнт не вміє обробляти, і потім видаляти їх під час оновлення).
Якщо на обʼєкт накладається багато конкурентних операцій (навіть на поле або набір полів, які ви не намагаєтеся редагувати), ви можете мати проблеми з надсиланням оновлення. Проблема гостріша для великих обʼєктів та для обʼєктів з багатьма полями.
HTTP PATCH з використанням JSON Patch
Оновлення патчем корисне через такі причини:
Оскільки ви надсилаєте лише різницю, ви маєте менше даних для надсилання у запиті PATCH.
Ви можете робити зміни, які ґрунтуються на наявних значеннях, наприклад, копіювати значення певного поля в анотацію.
На відміну від оновлення (HTTP PUT), ваші зміни можуть відбуватися відразу навіть при частих змінах не повʼязаних полів: зазвичай вам не потрібно повторювати спроби.
Вам все ще може знадобитися вказати resourceVersion (щоб відповідати існуючому обʼєкту), якщо ви хочете бути особливо обережними, щоб уникнути втрати оновлень.
Все ж це хороша практика написати деяку логіку повторної спроби у випадку помилок.
Ви можете використовувати тестові умови для обережного створення конкретних умов оновлення. Наприклад, ви можете збільшити лічильник без його читання, якщо існуюче значення відповідає вашим очікуванням. Ви можете це зробити без ризику втрати оновлення, навіть якщо обʼєкт змінився іншим чином з моменту вашого останнього запису до нього. (Якщо тестова умова не виконається, ви можете використовувати поточне значення і потім записати змінене число).
Проте:
Вам потрібна більша локальна (клієнтська) логіка для створення патчу; дуже корисно мати реалізацію бібліотеки JSON Patch або навіть створення JSON Patch специально для Kubernetes.
Як автору клієнтського програмного забезпечення, вам потрібно бути обережним при створенні патчу (тіла запиту HTTP), щоб не видаляти поля (порядок операцій має значення).
HTTP PATCH з використанням Server-Side Apply
Серверне застосування має чіткі переваги:
Одноразовий прохід веред-назад: зазвичай спочатку не потребує виконання GET запиту.
і ви все ще можете виявляти конфлікти для неочікуваних змін
у вас є можливість примусово перезаписати конфлікт, якщо це доцільно
Реалізація клієнта легка для створення
Ви отримуєте атомарну операцію створення або оновлення без додаткових зусиль (аналогічно UPSERT у деяких діалектах SQL).
Проте:
Серверне застосування зовсім не працює для змін полів, які залежать від поточного значення обʼєкта.
Ви можете застосовувати оновлення лише до обʼєктів. Деякі ресурси в HTTP API Kubernetes не є обʼєктами (вони не мають поля .metadata), а серверне застосування стосується лише обʼєктів Kubernetes.
Версії ресурсів
Версії ресурсів — це рядки, які ідентифікують внутрішню версію обʼєкта на сервері. Версії ресурсів можуть використовуватися клієнтами для визначення змін в обʼєктах або для зазначення вимог до консистентності даних при отриманні, переліку та перегляді ресурсів. Версії ресурсів повинні розглядатися клієнтами як непрозорі та передаватися без змін назад на сервер.
Не слід припускати, що версії ресурсів є числовими або можуть бути впорядковані. API-клієнти можуть порівнювати лише дві версії ресурсів на рівність (це означає, що ви не можете порівнювати версії ресурсів за відносними значеннями "більше" або "менше").
Поля resourceVersion в метаданих
Клієнти знаходять версії ресурсів в ресурсах, включаючи ресурси з потоку відповіді під час спостереження (watch) або при отримані переліку (list) ресурсів.
v1.meta/ObjectMeta — metadata.resourceVersion екземпляра ресурсу ідентифікує версію ресурсу, на якій останній раз він був змінений.
v1.meta/ListMeta — metadata.resourceVersion колекції ресурсів (відповідь на перелік (list)) ідентифікує версію ресурсу, на якій була створена колекція.
Параметри resourceVersion у рядках запитів
Операції отримання (get), переліку (list) та спостереження (watch) підтримують параметр resourceVersion. Починаючи з версії v1.19, сервери API Kubernetes також підтримують параметр resourceVersionMatch у запитах list.
Сервер API інтерпретує параметр resourceVersion по-різному, залежно від операції, яку ви запитуєте, та від значення resourceVersion. Якщо ви встановлюєте resourceVersionMatch, то це також впливає на спосіб порівняння.
Семантика для операцій get та list
Для операцій get та list, семантика параметра resourceVersion така:
get:
resourceVersion невстановлено
resourceVersion="0"
resourceVersion="{значення, відмінне від 0}"
Найновіший
Будь-яке
Не старше
list:
Починаючи з версії v1.19, сервери API Kubernetes підтримують параметр resourceVersionMatch у запитах list. Якщо ви встановлюєте як resourceVersion, так і resourceVersionMatch, то параметр resourceVersionMatch визначає, як сервер API інтерпретує resourceVersion.
Вам завжди слід встановлювати параметр resourceVersionMatch, коли ви встановлюєте resourceVersion у запиті list. Однак будьте готові обробляти випадок, де сервер API, що відповідає, не підтримує resourceVersionMatch та ігнорує його.
Крім випадків сильних вимог до консистентності, використання resourceVersionMatch=NotOlderThan та відомої resourceVersion є бажаним, оскільки це може забезпечити кращу продуктивність та масштабованість вашого кластеру, ніж залишати resourceVersion і resourceVersionMatch невстановленими, що вимагає отримання кворуму для обслуговування.
Встановлення параметра resourceVersionMatch без встановлення resourceVersion є недійсним.
Ця таблиця пояснює поведінку запитів list з різними комбінаціями resourceVersion та resourceVersionMatch:
Параметри resourceVersionMatch та розбиття на сторінки для list
Параметр resourceVersionMatch
Параметри розбиття на сторінки
resourceVersion не встановлено
resourceVersion="0"
resourceVersion="{значення, відмінне від 0}"
не встановлено
limit не встановлено
Найновіший
Any
Не старше
не встановлено
limit=<n>, continue не встановлено
Найновіший
Any
Точно
не встановлено
limit=<n>, continue=<токен>
Continue Token, Exact
Недійсний, розглядається як Continue Token, Exact
Недійсний, HTTP 400 Bad Request
resourceVersionMatch=Exact
limit не встановлено
Недійсний
Недійсний
Exact
resourceVersionMatch=Exact
limit=<n>, continue не встановлено
Недійсний
Недійсний
Exact
resourceVersionMatch=NotOlderThan
limit не встановлено
Недійсний
Any
NotOlderThan
resourceVersionMatch=NotOlderThan
limit=<n>, continue не встановлено
Недійсний
Any
NotOlderThan
Примітка:
Якщо сервер API вашого кластера не враховує параметр resourceVersionMatch, поведінка буде такою самою, як і якщо ви його не встановили.
Сенс семантики операцій get та list такий:
Any
Повернути дані на будь-якій версії ресурсу. Вибирається найновіша доступна версія ресурсу, але не потрібна сильна консистентність; дані на будь-якій версії ресурсу можуть бути обслуговані. Є можливість отримати дані на значно старішій версії ресурсу, яку клієнт раніше спостерігав, особливо в конфігураціях високої доступності через розділи або застарілі кеші. Клієнти, які не можуть терпіти це, не повинні використовувати цю семантику.
Найновіший
Повернути дані на найновішій версії ресурсу. Повернені дані повинні бути консистентними (детально: обслуговуються з etcd за допомогою кворумного читання).
NotOlderThan
Повернути дані, які є принаймні так новими, як наданий resourceVersion. Вибирається найновіша доступна інформація, але будь-яка інформація, яка не старше наданої resourceVersion, може бути обслугована. Для запитів list до серверів, які підтримують параметр resourceVersionMatch, це гарантує, що .metadata.resourceVersion колекції не старше вказаної resourceVersion, але не надає гарантії щодо .metadata.resourceVersion будь-яких елементів у цій колекції.
Exact
Повернути дані на точній версії ресурсу, яка надана. Якщо надана resourceVersion недоступна, сервер відповідає HTTP 410 "Відсутній". Для запитів list до серверів, які підтримують параметр resourceVersionMatch, це гарантує, що .metadata.resourceVersion колекції співпадає з resourceVersion, яку ви запросили у рядку запиту. Ця гарантія не поширюється на .metadata.resourceVersion будь-яких елементів у цій колекції.
Continue Token, Exact
Повернути дані на версії ресурсу початкового виклику list розділеного на сторінки. Повернені продовження токенів відповідальні за відстеження початково наданої версії ресурсу для всіх викликів list розділених на сторінки після початкового виклику list.
Примітка:
Коли ви перелічцєте (list) ресурси та отримуєте відповідь у вигляді колекції, відповідь містить метадані списку колекції, а також метадані обʼєктів для кожного елемента у цій колекції. Для окремих обʼєктів, знайдених у відповіді колекції, .metadata.resourceVersion відстежує, коли цей обʼєкт був останній раз оновлений, а не те, наскільки актуальний обʼєкт, коли він обслуговується.
При використанні resourceVersionMatch=Не старше та встановленому ліміті клієнти мають обробляти відповіді HTTP 410 "Gone". Наприклад, клієнт може повторно спробувати з новішою resourceVersion або використовувати resourceVersion="".
При використанні resourceVersionMatch=Точно та не встановленому ліміті, клієнти мають перевірити, що .metadata.resourceVersion колекції співпадає з запитаною resourceVersion, і обробити випадок, коли це не так. Наприклад, клієнт може використовувати запит з встановленим лімітом.
Семантика для операції watch
Для операцій watch, семантика параметра resourceVersion така:
watch:
resourceVersion для watch
resourceVersion невстановлено
resourceVersion="0"
resourceVersion="{значення, відмінне від 0}"
Отримати стан і почати з найновішого
Отримати стан і почати з будь-якого
Почати точно з
Сенс цієї семантики для watch такий:
Отримати стан і почати з будь-якого
Увага:
Watch, ініційовані таким чином, можуть повернути довільно застарілі дані. Будь ласка, перегляньте цю семантику перед її використанням і за можливості віддавайте перевагу іншим семантикам.
Почати watch на будь-якій версії ресурсу; найбільш нова доступна версія є переважною, але не обовʼязковою. Дозволено будь-яку початкову версію ресурсу. Можливо, що watch почнеться на набагато старішій версії ресурсу, яку клієнт раніше спостерігав, особливо в конфігураціях високої доступності через розділи або застарілі кеші. Клієнти, які не можуть терпіти таке відмотування назад, не повинні починати watch з цією семантикою. Для встановлення початкового стану, watch починається з синтетичних подій "Added" для всіх екземплярів ресурсів, які існують на початковій версії ресурсу. Усі наступні події watch стосуються всіх змін, що сталися після початкової версії ресурсу, з якої почався watch.
Отримати стан і почати з найновішого
Почати watch на найбільш новій версії ресурсу, яка повинна бути консистентною (детально: обслуговується з etcd за допомогою отримання кворуму). Для встановлення початкового стану watch починається з синтетичних подій "Added" для всіх екземплярів ресурсів, які існують на початковій версії ресурсу. Усі наступні події watch стосуються всіх змін, що сталися після початкової версії ресурсу, з якої почався watch.
Почати точно з
Почати watch на точній версії ресурсу. Події watch стосуються всіх змін після наданої версії ресурсу. На відміну від "Отримати стан і почати з найновішого" та "Отримати стан і почати з будь-якого", watch не починається з синтетичних подій "Added" для наданої версії ресурсу. Вважається, що клієнт вже має початковий стан на стартовій версії ресурсу, оскільки клієнт надав цю версію ресурсу.
Відповіді "410 Gone"
Сервери не зобовʼязані зберігати всі старі версії ресурсів і можуть повернути код HTTP 410 (Gone), якщо клієнт запитує resourceVersion, який старіший, ніж версія, збережена сервером. Клієнти повинні бути готові обробляти відповіді 410 (Gone). Дивіться розділ Ефективне виявлення змін для отримання додаткової інформації про те, як обробляти відповіді 410 (Gone) при спостереженні за ресурсами.
Якщо ви запитуєте resourceVersion, який знаходиться за межами допустимого діапазону, то, залежно від того, чи обслуговується запит з кешу чи ні, API-сервер може відповісти HTTP-відповіддю 410 Gone.
Недоступні версії ресурсів
Сервери не зобовʼязані обслуговувати нерозпізнані версії ресурсів. Якщо ви запитуєте list або get для версії ресурсу, яку API-сервер не розпізнає, то API-сервер може або:
почекати трохи, поки версія ресурсу не стане доступною, а потім завершити з тайм-аутом і відповіддю 504 (Gateway Timeout), якщо надана версія ресурсу не стане доступною в розумний термін;
відповісти заголовком Retry-After, вказуючи, через скільки секунд клієнт повинен повторити запит.
Якщо ви запитуєте версію ресурсу, яку API-сервер не розпізнає, kube-apiserver додатково ідентифікує свої відповіді на помилки повідомленням "Too large resource version".
Якщо ви робите запит watch для нерозпізнаної версії ресурсу, API-сервер може чекати невизначений час (до тайм-ауту запиту), поки версія ресурсу не стане доступною.
Kubernetes підтримує співпрацю кількох аплікаторів для керування полями одного обʼєкта.
Server-Side Apply (Серверне застосування) надає необовʼязковий механізм для контролера вашого кластера, щоб відстежувати зміни в полях обʼєкта. На рівні конкретного ресурсу, Server-Side Apply записує та відстежує інформацію про контроль над полями цього обʼєкта.
Server-Side Apply допомагає користувачам та контролерам керувати своїми ресурсами за допомогою декларативної конфігурації. Клієнти можуть створювати та змінювати обʼєкти декларативно, подаючи їх повністю визначений намір.
Повністю визначений намір — це частковий обʼєкт, який містить лише ті поля та значення, щодо яких у користувача є чітке уявлення. Цей намір або створює новий обʼєкт (використовуючи стандартні значення для невизначених полів), або обʼєднується з наявним обʼєктом через API сервер.
Порівняння з Client-Side Apply пояснює, як Server-Side Apply відрізняється від початкової реалізації kubectl apply на стороні клієнта.
Управління полями
Kubernetes API сервер відстежує керовані поля для всіх новостворених обʼєктів.
При спробі застосувати обʼєкт, поля, які мають інше значення і належать іншому менеджеру, спричинять конфлікт. Це зроблено для того, щоб сигналізувати, що операція може скасувати зміни іншого спільника. Записи до обʼєктів з керованими полями можуть бути примусовими, в такому випадку значення будь-якого конфліктного поля буде перезаписане, а право власності передане.
Кожного разу, коли значення поля змінюється, право власності переходить від поточного менеджера до менеджера, що здійснює зміну.
Операція застосування перевіряє, чи є інші менеджери полів, які також володіють полем. Якщо поле не належить жодному іншому менеджеру полів, це поле встановлюється на стандартне значення (якщо таке є), або видаляється з обʼєкта. Те саме правило застосовується до полів, які є списками, асоціативними списками або map.
Для того, щоб користувач міг керувати полем в контексті Server-Side Apply, він повинен покладатися на те, що значення поля не зміниться. Користувач, який останнім висловив свою думку щодо значення поля, буде записаний як поточний менеджер поля. Це можна зробити, змінивши дані менеджера поля явним чином за допомогою HTTP POST (створення), PUT (оновлення), або не-застосувального PATCH (патч). Ви також можете оголосити та записати менеджера поля, включивши значення для цього поля в операції Server-Side Apply.
Запит на патч в контексті Server-Side Apply вимагає від клієнта вказати свою ідентичність як менеджера поля. При використанні Server-Side Apply спроба змінити поле, що контролюється іншим менеджером, призведе до відхилення запиту, якщо клієнт не виконає примусове перевизначення. Для деталей щодо примусових перевизначень дивіться Конфлікти.
Коли два або більше аплікатора встановлюють поле на однакове значення, вони спільно володіють цим полем. Будь-яка спроба змінити значення спільного поля будь-ким з аплікаторів призведе до конфлікту. Спільні власники поля можуть відмовитися від права власності на поле, здійснивши запит на патч в контексті Server-Side Apply, який не включає це поле.
Деталі управління полями зберігаються в полі managedFields, яке є частиною metadata обʼєкта.
Якщо ви видалите поле з маніфесту і застосуєте цей маніфест, Server-Side Apply перевірить, чи є інші менеджери полів, які також володіють цим полем. Якщо поле не належить жодному іншому менеджеру полів, воно буде або видалене з поточного обʼєкта, або скинуте до стандартного значення, якщо таке є. Те саме правило застосовується до елементів асоціативного списку або map.
У порівнянні з (застарілою) kubectl.kubernetes.io/last-applied-configuration анотацією, яка управляється kubectl, Server-Side Apply використовує більш декларативний підхід, який відстежує управління полями користувача (або клієнта), а не останній застосований стан користувача. Побічним ефектом використання Server-Side Apply є також доступність інформації про те, який менеджер поля управляє кожним полем в обʼєкті.
Приклад
Простий приклад обʼєкта, створеного за допомогою Server-Side Apply, може виглядати так:
---apiVersion:v1kind:ConfigMapmetadata:name:test-cmnamespace:defaultlabels:test-label:testmanagedFields:- manager:kubectloperation: Apply # зверніть увагу на великі літери:"Apply"(або "Update")apiVersion:v1time:"2010-10-10T0:00:00Z"fieldsType:FieldsV1fieldsV1:f:metadata:f:labels:f:test-label:{}f:data:f:key:{}data:key:some value
Цей приклад обʼєкта ConfigMap містить один запис про управління полями в .metadata.managedFields. Запис управління полями складається з основної інформації про саму сутність, що виконує управління, а також з деталей про поля, якими управляють, та відповідну операцію (Apply або Update). Якщо запит, що останнім змінив це поле, був патчем Server-Side Apply, тоді значення operation буде Apply; в іншому випадку, це буде Update.
Є ще один можливий результат. Клієнт може подати недійсний запит. Якщо повністю зазначений намір не створює дійсний обʼєкт, запит не вдасться виконати.
Однак, можливо змінити .metadata.managedFields за допомогою операції оновлення або патчу, які не використовують Server-Side Apply. Це наполегливо не рекомендується, але може бути доцільно спробувати, якщо, наприклад, .metadata.managedFields потрапить у неконсистентний стан (що не повинно відбуватися при нормальній роботі).
Поле .metadata.managedFields керується API сервером. Ви повинні уникати його ручного оновлення.
Конфлікти
Конфлікт — це спеціальна помилка статусу, яка виникає, коли операція Apply намагається змінити поле, на яке інший менеджер також заявляє права на керування. Це запобігає ненавмисному перезапису значення, встановленого іншим користувачем. У разі конфлікту аплікатор має 3 варіанти для вирішення конфліктів:
Перезаписати значення, стати єдиним менеджером: Якщо перезапис значення був навмисним (або якщо аплікатор є автоматичним процесом, таким як контролер), аплікатор повинен встановити параметр запиту force в true (для kubectl apply використовується параметр командного рядка --force-conflicts) і повторити запит. Це змусить операцію завершитись успішно, змінить значення поля та видалить це поле з усіх інших записів менеджерів у managedFields.
Не перезаписувати значення, відмовитися від права управління: Якщо аплікатор більше не піклується про значення поля, він може видалити його зі своєї локальної моделі ресурсу і зробити новий запит, виключивши це конкретне поле. Це залишить значення незмінним і видалить поле із запису аплікатора у managedFields.
Не перезаписувати значення, стати спільним менеджером: Якщо аплікатор все ще піклується про значення поля, але не хоче його перезаписувати, він може змінити значення цього поля у своїй локальній моделі ресурсу, щоб відповідати значенню обʼєкта на сервері, а потім зробити новий запит, враховуючи це локальне оновлення. Це залишить значення незмінним і зробить це поле керованим спільно аплікатором та всіма іншими менеджерами, які вже заявили про керування ним.
Менеджери полів
Менеджери визначають окремі робочі процеси, які змінюють обʼєкт (особливо корисно при конфліктах!), і можуть бути вказані через параметр запиту fieldManager як частина запиту на зміни. Коли ви застосовуєте зміни до ресурсу, параметр fieldManager є обовʼязковим. Для інших оновлень сервер API визначає ідентифікатор менеджера поля з заголовка HTTP "User-Agent:" (якщо він присутній).
Коли ви використовуєте інструмент kubectl для виконання операції Server-Side Apply, kubectl типово встановлює ідентифікатор менеджера в "kubectl".
Серіалізація
На рівні протоколу Kubernetes представляє тіла повідомлень Server-Side Apply у форматі YAML, з медіа типом application/apply-patch+yaml.
Примітка:
Незалежно від того, чи ви подаєте дані у форматі JSON чи YAML, використовуйте application/apply-patch+yaml як значення заголовка Content-Type.
Усі документи JSON є дійсними документами YAML. Однак, у Kubernetes є помилка, яка полягає в тому, що він використовує парсер YAML, який не повністю реалізує специфікацію YAML. Деякі JSON екранування можуть не бути розпізнаними.
Серіалізація є такою ж, як для обʼєктів Kubernetes, за винятком того, що клієнти не зобовʼязані надсилати повний обʼєкт.
Ось приклад тіла повідомлення Server-Side Apply (повністю специфікований намір):
{
"apiVersion": "v1",
"kind": "ConfigMap"}
(це зробить оновлення без змін, за умови, що це було надіслано як тіло patch запиту до дійсного ресурсу v1/configmaps, з відповідним заголовком запиту Content-Type).
Операції з області управління полями
Операції API Kubernetes, де враховується управління полями, включають:
Server-Side Apply (HTTP PATCH, з типом контенту application/apply-patch+yaml)
Заміна наявного обʼєкта (update для Kubernetes; PUT на рівні HTTP)
Обидві операції оновлюють .metadata.managedFields, але поводяться трохи по-різному.
Якщо не вказано примусове перезаписування, операція apply, що зустрічає конфлікти на рівні полів, завжди зазнає невдачі; у противагу, якщо зміну здійснено за допомогою update, що впливає на кероване поле, конфлікт ніколи не призводить до невдачі операції.
Усі запити Server-Side Apply patch повинні ідентифікувати себе, надаючи параметр запиту fieldManager, тоді як цей параметр запиту є необовʼязковим для операцій update. Нарешті, при використанні операції Apply ви не можете визначати managedFields у тілі запиту, який ви надсилаєте.
Приклад обʼєкта з декількома менеджерами може виглядати так:
---apiVersion:v1kind:ConfigMapmetadata:name:test-cmnamespace:defaultlabels:test-label:testmanagedFields:- manager:kubectloperation:ApplyapiVersion:v1fields:f:metadata:f:labels:f:test-label:{}- manager:kube-controller-manageroperation:UpdateapiVersion:v1time:'2019-03-30T16:00:00.000Z'fields:f:data:f:key:{}data:key:new value
У цьому прикладі друга операція була виконана як update менеджером з назвою kube-controller-manager. Запит на оновлення був успішним і змінив значення в полі даних, що призвело до зміни управління цим полем на kube-controller-manager.
Якби була спроба застосувати це оновлення за допомогою Server-Side Apply, запит зазнав би невдачі через конфлікт управління.
Стратегія злиття
Стратегія злиття, реалізована в Server-Side Apply, забезпечує більш стабільний життєвий цикл обʼєкта. Server-Side Apply намагається обʼєднати поля на основі того, хто ними керує, замість того, щоб замінювати їх значення. Таким чином, кілька акторів можуть оновлювати один і той самий обʼєкт без несподіваних перешкод.
Коли користувач надсилає обʼєкт із повністю специфікованим наміром на точку доступу Server-Side Apply, сервер зʼєднує його з поточним обʼєктом, надаючи перевагу значенню з тіла запиту, якщо воно вказане в обох місцях. Якщо набір елементів, присутніх у застосованій конфігурації, не є надмножиною елементів, застосованих тим самим користувачем минулого разу, кожен відсутній елемент, яким не керують інші аплікатори, видаляється. Для отримання додаткової інформації про те, як схема обʼєкта використовується для прийняття рішень під час злиття, дивіться sigs.k8s.io/structured-merge-diff.
API Kubernetes (та код Go, який реалізує це API для Kubernetes) дозволяє визначати маркери стратегії злиття. Ці маркери описують підтримувану стратегію злиття для полів в обʼєктах Kubernetes. Для CustomResourceDefinition, ви можете встановити ці маркери під час визначення власного ресурсу.
Маркер Golang
Розширення OpenAPI
Можливі значення
Опис
//+listType
x-kubernetes-list-type
atomic/set/map
Застосовується до списків. set застосовується до списків, які включають лише скалярні елементи. Ці елементи повинні бути унікальними. map застосовується до списків вкладених типів. Значення ключів (див. listMapKey) повинні бути унікальними в списку. atomic може застосовуватися до будь-якого списку. Якщо налаштовано як atomic, весь список замінюється під час злиття. У будь-який момент часу список належить одному менеджеру. Якщо set або map, різні менеджери можуть окремо керувати елементами.
//+listMapKey
x-kubernetes-list-map-keys
Список імен полів, наприклад, ["port", "protocol"]
Застосовується лише при +listType=map. Список імен полів, значення яких унікально ідентифікують елементи у списку. Хоча ключів може бути багато, listMapKey є одниною, тому що ключі потрібно вказувати індивідуально в типі Go. Поля ключів повинні бути скалярами.
//+mapType
x-kubernetes-map-type
atomic/granular
Застосовується до map. atomic означає, що map можна замінити повністю тільки одним менеджером. granular означає, що map підтримує окремих менеджерів, які оновлюють окремі поля.
//+structType
x-kubernetes-map-type
atomic/granular
Застосовується до структур; інакше те ж використання та анотація OpenAPI, як //+mapType.
Якщо listType відсутній, сервер API інтерпретує patchStrategy=merge як listType=map і відповідний маркер patchMergeKey як listMapKey.
Тип списку atomic є рекурсивним.
(У коді Go для Kubernetes, ці маркери вказуються як коментарі, і авторам коду не потрібно повторювати їх як теґи полів).
Власні ресурси та Серверне застосування
Стандартно, Server-Side Apply обробляє власні ресурси користувачів як неструктуровані дані. Усі ключі розглядаються як поля структури, а всі списки вважаються атомарними.
Якщо у визначенні CustomResourceDefinition міститься схема, яка містить анотації, визначені у попередньому розділі Стратегія злиття, ці анотації будуть використовуватись під час злиття обʼєктів цього типу.
Сумісність при зміні топології
У рідкісних випадках автор CustomResourceDefinition (CRD) або вбудованого ресурсу може захотіти змінити специфічну топологію поля у своєму ресурсі, не збільшуючи його версію API. Зміна топології типів шляхом оновлення кластера або CRD має різні наслідки при оновленні наявних обʼєктів. Є дві категорії змін: коли поле переходить від map/set/granular до atomic і навпаки.
Коли listType, mapType або structType змінюються з map/set/granular на atomic, весь список, map або структура наявних обʼєктів будуть в підсумку належати акторам, які володіли елементом цих типів. Це означає, що будь-яка подальша зміна цих обʼєктів призведе до конфлікту.
Коли listType, mapType або structType змінюються з atomic на map/set/granular, сервер API не може визначити нову власність цих полів. Через це конфлікти не виникатимуть під час оновлення обʼєктів із цими полями. Тому не рекомендується змінювати тип із atomic на map/set/granular.
Візьмемо, наприклад, власний ресурс користувача ресурс:
До того, як spec.data зміниться з atomic на granular, manager-one володіє полем spec.data і всіма полями в ньому (key1 та key2). Коли CRD змінюється, щоб зробити spec.datagranular, manager-one продовжує володіти полем верхнього рівня spec.data (що означає, що жоден інший менеджер не може видалити map data без конфлікту), але він більше не володіє key1 та key2, тому інший менеджер може змінити або видалити ці поля без конфлікту.
Використання Server-Side Apply в контролер
Як розробник контролера, ви можете використовувати Server-Side Apply як спосіб спростити логіку оновлення вашого контролера. Основні відмінності від кead-modify-write та/або patch наступні:
застосований обʼєкт повинен містити всі поля, які цікавлять контролер.
немає способу видалити поля, які не були застосовані контролером раніше (контролер все ще може надіслати patch або update для цих випадків використання).
обʼєкт не обовʼязково має бути прочитаним перед тим; resourceVersion не потрібно вказувати.
Для контролерів рекомендується завжди застосовувати конфлікти на обʼєктах, якими вони володіють і керують, оскільки вони можуть не мати можливості розвʼязати або подіяти на ці конфлікти.
Передача власності
Окрім контролю конкурентності, забезпеченого вирішенням конфліктів, Server-Side Apply надає можливості для виконання координованих переходів власності полів від користувачів до контролерів.
Це найкраще пояснюється на прикладі. Розглянемо, як безпечно перевести власність поля replicas від користувача до контролера, дозволяючи автоматичне горизонтальне масштабування для Deployment, використовуючи ресурс HorizontalPodAutoscaler та його супровідний контролер.
Скажімо, користувач визначив Deployment з replicas, встановленим на бажане значення:
Тепер користувач хоче видалити replicas з конфігурації, щоб вони випадково не конфліктували з HorizontalPodAutoscaler (HPA) та його контролером. Однак виникають перегони: може пройти деякий час, перш ніж HPA вирішить змінити .spec.replicas; якщо користувач видаляє .spec.replicas перед тим, як HPA запише в поле і стане його власником, тоді API-сервер встановить .spec.replicas на 1 (стандартна кількість реплік для Deployment). Це не те, що хоче користувач, ще й тимчасово — це може погіршити робоче навантаження.
Є два рішення:
(базовий) Залиште replicas в конфігурації; коли HPA нарешті запише в це поле, система сповістить користувачу про конфлікт при спробі зробити це. На цьому етапі безпечно видалити його з конфігурації.
(більш розширений) Однак, якщо користувач не хоче чекати, наприклад, через те що вони хочуть, щоб кластер був зрозумілим для їх колег, тоді вони можуть виконати наступні кроки, щоб зробити видалення replicas з їх конфігурації безпечним:
Спочатку користувач визначає новий маніфест, що містить лише поле replicas:
# Збережіть цей файл як 'nginx-deployment-replicas-only.yaml'.apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:replicas:3
Примітка:
Файл YAML для SSA у цьому випадку містить лише поля, які ви хочете змінити. Вам не слід надавати повністю сумісний з Deployment маніфест, якщо ви хочете змінити лише поле spec.replicas, використовуючи SSA.
Користувач застосовує цей маніфест, використовуючи приватне імʼя менеджера полів. У цьому прикладі користувач вибрав handover-to-hpa:
Якщо застосування призводить до конфлікту з контролером HPA, тоді нічого не робіть. Конфлікт вказує на те, що контролер вже вимагає поле на цьому етапі.
На цьому етапі користувач може видалити поле replicas з маніфесту:
Зауважте, що кожного разу, коли контролер HPA встановлює значення поля replicas на нове значення, тимчасовий менеджер полів більше не володіє жодними полями й буде автоматично видалений. Додаткового прибирання не потрібно.
Передача власності між менеджерами
Менеджери полів можуть передавати власність поля між собою, встановлюючи значення поля в тому самому значенні в обох їх застосованих конфігураціях, що призводить до того, що вони спільно володіють полем. Після цього менеджери можуть відмовитися від володіння полям та завершити передачу іншому менеджеру поля, видаливши поле з їх застосованої конфігурації.
Порівняння з Client-Side Apply
Server-Side Apply призначений як для заміни початкової реалізації команди kubectl apply на стороні клієнта, так і для забезпечення простого та ефективного механізму для контролерів, щоб впроваджувати свої зміни.
Порівняно з анотацією last-applied, якою керує kubectl, Server-Side Apply використовує більш декларативний підхід, що відстежує управління полями обʼєкта, а не останній стан, застосований користувачем. Це означає, що як побічний ефект використання Server-Side Apply, стає доступною інформація про те, який менеджер полів керує кожним полем в обʼєкті.
Наслідком виявлення та вирішення конфліктів, реалізованих у Server-Side Apply, є те, що аплікатор завжди має актуальні значення полів у своєму локальному стані. Якщо ні, то він отримає конфлікт під час наступного застосування. Будь-який з трьох варіантів розвʼязання конфліктів призводить до того, що застосована конфігурація стає актуальною підмножиною полів обʼєкта на сервері.
Це відрізняється від Client-Side Apply, де застарілі значення, які були перезаписані іншими користувачами, залишаються в локальній конфігурації аплікатора. Ці значення стають точними лише тоді, коли користувач оновлює конкретне поле, якщо взагалі оновлює, і аплікатор не має способу дізнатися, чи наступне застосування перезапише зміни інших користувачів.
Ще однією відмінністю є те, що аплікатор, використовуючи Client-Side Apply, не може змінити версію API, яку він використовує, тоді як Server-Side Apply підтримує цей випадок використання.
Міграція між client-side і server-side apply
Перехід з client-side apply на server-side apply
Користувачі client-side apply, які керують ресурсом за допомогою kubectl apply, можуть почати використовувати server-side apply з наступним прапорцем.
kubectl apply --server-side [--dry-run=server]
Стандартно, управління полями обʼєкта переходить з client-side apply на kubectl server-side apply без виникнення конфліктів.
Увага:
Тримайте анотацію last-applied-configuration в актуальному стані. Анотація визначає поля, якими керує client-side apply. Будь-які поля, якими не керує client-side apply, викликають конфлікти.
Наприклад, якщо ви використовували kubectl scale для оновлення поля replicas після client-side apply, тоді це поле не належить client-side apply і створює конфлікти при kubectl apply --server-side.
Ця поведінка стосується server-side apply з менеджером полів kubectl. Як виняток, ви можете відмовитися від цієї поведінки, вказавши іншого, не стандартного менеджера полів, як показано в наступному прикладі. Стандартним менеджером полів для kubectl server-side apply є kubectl.
Повернення з server-side apply на client-side apply
Якщо ви керуєте ресурсом за допомогою kubectl apply --server-side, ви можете перейти на client-side apply безпосередньо за допомогою kubectl apply.
Повернення працює тому, що kubectl Server-Side Apply тримає анотацію last-applied-configuration в актуальному стані, якщо ви використовуєте kubectl apply.
Ця поведінка стосується Server-Side Apply з менеджером полів kubectl. Як виняток, ви можете відмовитися від цієї поведінки, вказавши іншого, не стандартного менеджера полів, як показано в наступному прикладі. Стандартним менеджером полів для kubectl server-side apply є kubectl.
Дієслово PATCH для ресурсу, який підтримує Server-Side Apply, може приймати неофіційний тип контенту application/apply-patch+yaml. Користувачі Server-Side Apply можуть надіслати частково специфіковані обʼєкти у вигляді YAML як тіло запиту PATCH до URI ресурсу. При застосуванні конфігурації слід завжди включати всі поля, які є важливими для результату (наприклад, бажаний стан), який ви хочете визначити.
Усі повідомлення в форматі JSON є дійсним YAML. Деякі клієнти вказують запити Server-Side Apply, використовуючи тіла запитів у форматі YAML, які також є дійсним JSON.
Контроль доступу і дозволи
Оскільки Server-Side Apply є типом PATCH, субʼєкт (такий як Роль для Kubernetes RBAC) потребує дозволу patch для редагування наявних ресурсів, а також дозволу на дієслово create для створення нових ресурсів за допомогою Server-Side Apply.
Очищення managedFields
Можливо видалити всі managedFields з обʼєкта, переписавши їх за допомогою patch (JSON Merge Patch, Strategic Merge Patch, JSON Patch) або через update (HTTP PUT); іншими словами, через будь-яку операцію запису, окрім apply. Це можна зробити, переписавши поле managedFields порожнім записом. Два приклади:
Це перепише managedFields списком, що містить один порожній запис, що в результаті повністю видалить managedFields з обʼєкта. Зверніть увагу, що встановлення managedFields як порожнього списку не скине це поле. Це зроблено спеціально, щоб managedFields ніколи не видалялися клієнтами, які не знають про це поле.
У випадках, коли операція скидання комбінується зі змінами інших полів, крім managedFields, це призведе до того, що спочатку managedFields буде скинуто, а інші зміни будуть оброблені пізніше. У результаті аплікатор бере на себе відповідальність за будь-які поля, оновлені в тому ж запиті.
Примітка:
Server-Side Apply не правильно відстежує власність на субресурси, які не отримують тип обʼєкта ресурсу. Якщо ви використовуєте Server-Side Apply з таким субресурсом, змінені поля можуть не відслідковуватися.
Що далі
Ви можете прочитати про managedFields у довіднику API Kubernetes для верхнього рівня поля metadata.
2.3 - Бібліотеки клієнтів
Ця сторінка містить огляд бібліотек клієнтів для використання Kubernetes API різними мовами програмування.
Для написання застосунків, що використовують Kubernetes REST API, вам не потрібно самостійно реалізовувати виклики API та типи запитів/відповідей. Ви можете використовувати бібліотеку клієнтів для мови програмування, яку ви використовуєте.
Бібліотеки клієнтів часто виконують загальні завдання, такі як автентифікація. Більшість бібліотек клієнтів можуть знаходити та використовувати Kubernetes Service Account для автентифікації, якщо API клієнт працює всередині кластера Kubernetes, або можуть розуміти формат kubeconfig файлу для читання облікових даних та адреси API сервера.
Офіційно підтримувані бібліотеки клієнтів Kubernetes
Примітка: Цей розділ містить посилання на проєкти сторонніх розробників, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Проєкти вказано в алфавітному порядку. Щоб додати проєкт до цього списку, ознайомтеся з посібником з контенту перед надсиланням змін. Докладніше.
Наступні бібліотеки клієнтів Kubernetes надаються і підтримуються їх авторами, а не командою Kubernetes.
Вирази CEL оцінюються безпосередньо на сервері API, що робить CEL зручним альтернативним рішенням для зовнішніх механізмів, таких як вебхуки, для багатьох випадків розширення функціональності. Ваші вирази CEL продовжують виконуватись, поки компонент сервера API у складі панелі управління залишається доступним.
Огляд мови
Мова CEL має простий синтаксис, який схожий на вирази в C, C++, Java, JavaScript і Go.
CEL була розроблена для вбудовування в застосунки. Кожна "програма" CEL — це один вираз, який обраховується до одного значення. Вирази CEL зазвичай короткі "одноразові", що добре вбудовуються в строкові поля ресурсів API Kubernetes.
Вхідні дані для програми CEL — це "змінні". Кожне поле API Kubernetes, яке містить CEL, декларує в документації API, які змінні доступні для використання для цього поля. Наприклад, у полі x-kubernetes-validations[i].rules у CustomResourceDefinitions доступні змінні self і oldSelf, що відносяться до попереднього та поточного стану даних власного ресурсу користувача, які потрібно перевірити за допомогою виразу CEL. Інші поля API Kubernetes можуть оголошувати різні змінні. Дивіться документацію API для полів API, щоб дізнатися, які змінні доступні для цього поля.
Функції CEL, особливості та налаштування мови підтримують відкат панелі управління Kubernetes. Наприклад, опційні значення CEL були введені у Kubernetes 1.29, і лише сервери API цієї версії або новіші прийматимуть запити на запис виразів CEL, які використовують опційні значення CEL. Однак, коли кластер відкочується до версії Kubernetes 1.28, вирази CEL, що використовують "опційні значення CEL", які вже збережені в ресурсах API, продовжуватимуть правильно оцінюватись.
Бібліотеки CEL Kubernetes
Крім спільнотних бібліотек CEL, Kubernetes включає бібліотеки CEL, які доступні у всіх місцях використання CEL в Kubernetes.
Бібліотека списків Kubernetes
Бібліотека списків включає indexOf та lastIndexOf, які працюють аналогічно функціям рядків з такими самими назвами. Ці функції повертають перший або останній індекс елемента у списку.
Бібліотека списків також включає min, max та sum. Сума підтримується для всіх типів чисел, а також для типу тривалості. Мінімум та максимум підтримуються для всіх типів, що можна порівняти.
Також надається функція isSorted для зручності та підтримується для всіх типів, які можна порівняти.
Приклади:
Приклади виразів CEL, що використовують функції бібліотеки списків
Вираз CEL
Призначення
names.isSorted()
Перевірити, що список імен зберігається в алфавітному порядку
items.map(x, x.weight).sum() == 1.0
Перевірити, що "ваги" списку обʼєктів дорівнюють 1.0
Крім функції matches, наданої стандартною бібліотекою CEL, бібліотека регулярних виразів надає функції find та findAll, що дозволяють виконувати ширший спектр операцій з регулярними виразами.
Приклади:
Приклади виразів CEL, що використовують функції бібліотеки регулярних виразів
Для спрощення та безпечної обробки URL надані наступні функції:
isURL(string) перевіряє, чи є рядок рядком дійсним URL з пакетом Go net/url. Рядок повинен бути абсолютним URL.
url(string) URL конвертує рядок в URL або викликає помилку, якщо рядок не є дійсним URL.
Після розбору за допомогою функції url, отриманий обʼєкт URL має наступні методи доступу: getScheme, getHost, getHostname, getPort, getEscapedPath та getQuery.
Приклади:
Приклади виразів CEL, що використовують функції бібліотеки URL
Вираз CEL
Призначення
url('https://example.com:80/').getHost()
Отримати частину хосту 'example.com:80' URL.
url('https://example.com/path with spaces/').getEscapedPath()
Для виразів CEL в API, де доступна змінна типу Authorizer, авторизатор може використовуватися для виконання перевірок авторизації для принципала (автентифікованого користувача) запиту.
Перевірки ресурсів API виконуються наступним чином:
Вкажіть групу та ресурс для перевірки: Authorizer.group(string).resource(string) ResourceCheck.
Опційно викличте будь-яку комбінацію наступних функцій побудови для подальшого обмеження перевірки авторизації. Зверніть увагу, що ці функції повертають тип отримувача та можуть бути зʼєднані ланцюгом:
ResourceCheck.subresource(string) ResourceCheck
ResourceCheck.namespace(string) ResourceCheck
ResourceCheck.name(string) ResourceCheck
Викличте ResourceCheck.check(verb string) Decision, щоб виконати перевірку авторизації.
Викличте allowed() bool або reason() string, щоб переглянути результат перевірки авторизації.
Не-ресурсна авторизація виконується так:
Вкажіть лише шлях: Authorizer.path(string) PathCheck.
Викличте PathCheck.check(httpVerb string) Decision, щоб виконати перевірку авторизації.
Викличте allowed() bool або reason() string, щоб переглянути результат перевірки авторизації.
Для виконання перевірки авторизації для службового облікового запису:
Authorizer.serviceAccount(namespace string, name string) Authorizer
Приклади виразів CEL, що використовують функції бібліотеки авторизатора
quantity(string) Quantity конвертує рядок у кількість або викликає помилку, якщо рядок не є дійсною кількістю.
Після розбору за допомогою функції quantity, отриманий обʼєкт кількості має наступний набір методів:
Набір доступних методів для кількості
Метод
Повертає тип
Опис
isInteger()
bool
Повертає true, якщо asInteger може бути викликано без помилки.
asInteger()
int
Повертає представлення поточного значення як int64, якщо це можливо, або викликає помилку, якщо конвертація призводить до переповнення або втрати точності.
asApproximateFloat()
float
Повертає представлення кількості як float64, що може втратити точність.
sign()
int
Повертає 1, якщо кількість додатня, -1, якщо вона відʼємна, або 0, якщо вона нуль.
add(<Quantity>)
Quantity
Повертає суму двох кількостей.
add(<int>)
Quantity
Повертає суму кількості та цілого числа.
sub(<Quantity>)
Quantity
Повертає різницю між двома кількостями.
sub(<int>)
Quantity
Повертає різницю між кількістю та цілим числом.
isLessThan(<Quantity>)
bool
Повертає true, якщо отримувач менше операнта.
isGreaterThan(<Quantity>)
bool
Повертає true, якщо отримувач більше операнта.
compareTo(<Quantity>)
int
Порівнює отримувача з операндом та повертає 0, якщо вони рівні, 1, якщо отримувач більший або -1, якщо отримувач менший за операнд.
Приклади:
Приклади виразів CEL, що використовують функції бібліотеки кількості
Вираз CEL
Призначення
quantity("500000G").isInteger()
Перевірка, чи конвертація в ціле число викликає помилку.
Деякі поля API Kubernetes містять повністю перевірені типи CEL-виразів. Наприклад, Правила валідації власних ресурсів повністю перевірені за типом.
Деякі поля API Kubernetes містять частково перевірені типи CEL-виразів. Частково перевірений вираз — це вираз, в якому деякі змінні статично типізовані, а інші — динамічно типізовані. Наприклад, в CEL-виразах ValidatingAdmissionPolicies, змінна request має тип, але змінна object динамічно типізована. У звʼязку з цим вираз, що містить request.namex, не пройде перевірку типів, оскільки поле namex не визначене. Однак object.namex пройде перевірку типів навіть тоді, коли поле namex не визначене для типів ресурсів, на які посилається object, оскільки object динамічно типізований.
Макрос has() в CEL можна використовувати у виразах CEL для перевірки доступності поля динамічно типізованої змінної перед спробою доступу до значення поля. Наприклад:
Порівняння рівності для масивів з x-kubernetes-list-type типу set або map ігнорує порядок елементів. Наприклад, [1, 2] == [2, 1] якщо масиви представляють значення Kubernetes set.
Конкатенація для масивів з x-kubernetes-list-type використовує семантику типу списку:
set: X + Y виконує об'єднання, де позиції елементів у X зберігаються, а не перетинаючі елементи у Y додаються, зберігаючи їх частковий порядок.
map: X + Y виконує об'єднання, де позиції ключів у X зберігаються, але значення перезаписуються значеннями у Y, коли ключові множини X і Y перетинаються. Елементи у Y з неперетинаючими ключами додаються, зберігаючи їх частковий порядок.
Екранування
Тільки імена властивостей ресурсів Kubernetes форми [a-zA-Z_.-/][a-zA-Z0-9_.-/]* доступні з CEL. Доступні імена властивостей екрануються згідно з наступними правилами при доступі у виразі:
Коли ви екрануєте будь-яке з ЗАРЕЗЕРВОВАНИХ ключових слів CEL, збіг повинен точно відповідати імені властивості та використовувати екранування з підкресленням (наприклад, int у слові sprint не буде екрановано, і це не буде необхідно).
Приклади екранування:
Приклади екранованих ідентифікаторів CEL
імʼя властивості
правило з екранованим імʼям властивості
namespace
self.__namespace__ > 0
x-prop
self.x__dash__prop > 0
redact__d
self.redact__underscores__d > 0
string
self.startsWith('kube')
Обмеження ресурсів
CEL не є повноцінною мовою Тюрінга і пропонує різноманітні засоби безпеки для обмеження часу виконання. Функції обмеження ресурсів CEL забезпечують зворотний звʼязок розробникам щодо складності виразів та допомагають захистити сервер API від надмірного споживання ресурсів під час оцінювання. Ці функції використовуються для запобігання надмірного споживання ресурсів сервера API під час виконання CEL.
Ключовим елементом функцій обмеження ресурсів є одиниця вартості, яку CEL визначає як спосіб відстеження використання ЦП. Одиниці вартості незалежні від системного навантаження та апаратного забезпечення. Одиниці вартості також є детермінованими; для будь-якого заданого виразу CEL та вхідних даних, оцінка виразу інтерпретатором CEL завжди призведе до однакової вартості.
Багато з основних операцій CEL мають фіксовані витрати. Найпростіші операції, такі як порівняння (наприклад, <), мають вартість 1. Деякі мають вищу фіксовану вартість, наприклад, оголошення літералів списку мають фіксовану базову вартість 40 одиниць вартості.
Виклики функцій, реалізованих у рідному коді, оцінюються на основі часової складності операції. Наприклад, операції, що використовують регулярні вирази, такі як match та find, оцінюються з використанням приблизної вартості length(regexString)*length(inputString). Приблизна вартість відображає найгірший випадок часової складності реалізації RE2 в Go.
Бюджет вартості під час виконання
Усі вирази CEL, які оцінюються Kubernetes, обмежені бюджетом вартості під час виконання. Бюджет вартості під час виконання — це оцінка фактичного використання ЦП, що обчислюється шляхом інкрементування лічильника одиниць вартості під час інтерпретації виразу CEL. Якщо інтерпретатор CEL виконає занадто багато інструкцій, бюджет вартості під час виконання буде перевищено, виконання виразу буде зупинено і результатом стане помилка.
Деякі ресурси Kubernetes визначають додатковий бюджет вартості під час виконання, який обмежує виконання декількох виразів. Якщо загальна вартість виразів перевищує бюджет, виконання виразів буде зупинено і результатом стане помилка. Наприклад, валідація власного ресурсу користувача має бюджет вартості під час виконання за одну валідацію для всіх Правил Валідації, які оцінюються для валідації власного ресурсу.
Оцінювані обмеження вартості
Для деяких ресурсів Kubernetes, сервер API також може перевірити, чи не буде найгірший випадок оціненого часу виконання виразів CEL надто дорогим для виконання. Якщо так, сервер API запобігає записуванню виразу CEL у ресурсі API, відхиляючи операції створення або оновлення, що містять вираз CEL у ресурсі API. Ця функція пропонує сильнішу гарантію, що вирази CEL, записані у ресурс API, будуть оцінені під час виконання без перевищення бюджету вартості під час виконання.
2.5 - Політика застарівання Kubernetes
Цей документ описує політику застарівання для різних аспектів системи.
Kubernetes — це велика система з багатьма компонентами та багатьма учасниками. Як і в будь-якому такому програмному забезпеченні, набір функцій природно розвивається з часом, і іноді функцію може знадобитися видалити. Це може включати API, прапорець або навіть всю функцію. Щоб уникнути порушення роботи наявних користувачів, Kubernetes дотримується політики застарівання для аспектів системи, які підлягають видаленню.
Застарівання частин API
Оскільки Kubernetes є системою, що керується API, API еволюціонував з часом, віддзеркалюючи постійно змінюване розуміння проблемної області. API Kubernetes фактично є набором API, які називаються "групами API", і кожна група API має свою незалежну версію. Версії API поділяються на 3 основні треки, кожен з яких має різні політики застарівання:
Приклад
Трек
v1
GA (загальнодоступна, стабільна)
v1beta1
Beta (попередній випуск, перед GA)
v1alpha1
Alpha (експериментальна)
Конкретний випуск Kubernetes може підтримувати будь-яку кількість груп API та будь-яку кількість версій кожного з них.
Наступні правила регулюють застарівання елементів API. Це включає:
Ресурси REST (також відомі як обʼєкти API)
Поля ресурсів REST
Анотації на ресурсах REST, включаючи "бета" анотації, але не включаючи "альфа" анотації
Перелічувані або постійні значення
Структури конфігурації компонентів
Ці правила застосовуються між офіційними випусками, а не між довільними внесками коду в основну гілку або гілки випусків.
Правило №1: Елементи API можуть бути видалені лише шляхом інкрементування версії групи API.
Після того, як елемент API був доданий до групи API у певній версії, він не може бути видалений з цієї версії або суттєво змінений, незалежно від треку.
Примітка:
З історичних причин є 2 "монолітні" групи API — "core" (без назви групи) і "extensions". Ресурси будуть поступово переміщені з цих застарілих груп API до більш доменно-специфічних груп API.
Правило №2: Обʼєкти API повинні мати можливість переходу між версіями API в даному випуску без втрати інформації, за винятком випадків, коли цілі ресурси REST не існують у деяких версіях.
Наприклад, обʼєкт може бути записаний як v1, потім прочитаний як v2 і перетворений на v1, і отриманий ресурс v1 буде ідентичний оригіналу. Представлення у v2 може відрізнятися від v1, але система повинна вміти конвертувати між ними в обидва боки. Крім того, будь-яке нове поле, додане у v2, повинно мати можливість обміну на v1 і назад, що означає, що v1 можливо доведеться додати еквівалентне поле або представити його як анотацію.
Правило №3: Версія API в даному треку не може бути застарілою на користь менш стабільної версії API.
GA версії API можуть замінювати бета та альфа версії API.
Бета версії API можуть замінювати попередні бета та альфа версії API, але не можуть замінювати GA версії API.
Альфа версії API можуть замінювати попередні альфа версії API, але не можуть замінювати GA або бета версії API.
Правило №4а: Тривалість життя API визначається рівнем стабільності API
GA версії API можуть бути позначені як застарілі, але не можуть бути видалені в межах основної версії Kubernetes
Бета версії API застарівають не раніше ніж через 9 місяців або 3 мінорних випуски після впровадження (що довше), і більше не обслуговуються через 9 місяців або 3 мінорних випуски після застарівання (що довше)
Альфа версії API можуть бути видалені в будь-якому випуску без попереднього повідомлення про застарівання
Це гарантує, що підтримка бета API охоплює максимальний підтримуваний розрив версій у 2 випуски, і що API не застоюються на нестабільних бета версіях, накопичуючи продуктивне використання, яке буде порушене, коли підтримка бета API закінчиться.
Примітка:
Зараз немає планів щодо основної версії Kubernetes, що видаляє GA API.
Примітка:
До тих пір, поки #52185 не буде вирішено, жодні версії API, які були віднесені до зберігання, не можуть бути видалені. Обслуговування REST точок доступу для цих версій може бути відключено (відповідно до графіків застарівання в цьому документі), але API сервер повинен залишатися здатним декодувати/конвертувати раніше збережені дані зі сховища.
Правило №4б: "Бажана" версія API та "версія зберігання" для даної групи можуть не просуватися до того, як буде зроблено випуск, що підтримує як нову версію, так і попередню версію.
Користувачі повинні мати можливість оновитися до нової версії Kubernetes, а потім повернутися до попередньої версії, не конвертуючи нічого до нової версії API або уникаючи порушень (якщо вони явно не використовували функції, доступні лише в новішій версії). Це особливо очевидно у збереженому представленні обʼєктів.
Все це найкраще ілюструється прикладами. Уявіть собі випуск Kubernetes, версія X, який вводить нову групу API. Новий випуск Kubernetes виходить приблизно кожні 4 місяці (3 на рік). Наступна таблиця описує, які версії API підтримуються в ряді наступних випусків.
Випуск
Версії API
Бажана/Версія зберігання
Примітки
X
v1alpha1
v1alpha1
X+1
v1alpha2
v1alpha2
v1alpha1 видалено, "необхідна дія" інформація про випуск
X+2
v1beta1
v1beta1
v1alpha2 видалено, "необхідна дія" інформація про випуск
X+3
v1beta2, v1beta1 (застар
іла)
v1beta1
v1beta1 застаріла, "необхідна дія" інформація про випуск
X+4
v1beta2, v1beta1 (застаріла)
v1beta2
X+5
v1, v1beta1 (застаріла), v1beta2 (застаріла)
v1beta2
v1beta2 застаріла, "необхідна дія" інформація про випуск
X+6
v1, v1beta2 (застаріла)
v1
v1beta1 видалено, "необхідна дія" інформація про випуск
X+7
v1, v1beta2 (застаріла)
v1
X+8
v2alpha1, v1
v1
v1beta2 видалено, "необхідна дія" інформація про випуск
X+9
v2alpha2, v1
v1
v2alpha1 видалено, "необхідна дія" інформація про випуск
X+10
v2beta1, v1
v1
v2alpha2 видалено, "необхідна дія" інформація про випуск
X+11
v2beta2, v2beta1 (застаріла), v1
v1
v2beta1 застаріла, "необхідна дія" інформація про випуск
v2beta1 видалено, "необхідна дія" інформація про випуск
X+15
v2, v1 (застаріла)
v2
v2beta2 видалено, "необхідна дія" інформація про випуск
REST ресурси (або обʼєкти API)
Розглянемо гіпотетичний REST ресурс з назвою Widget, який був присутній у версії API v1 у наведеній вище хронології і який потрібно визнати застарілим. Ми документуємо та оголошуємо про його застарівання синхронно з випуском X+1. Ресурс Widget все ще існує у версії API v1 (застарілий), але не у v2alpha1. Ресурс Widget продовжує існувати та функціонувати у випусках до, та включно з, X+8. Лише у випуску X+9, коли API v1 виходить з використання, ресурс Widget перестає існувати та його віповідна поведінка видаляється.
Починаючи з Kubernetes v1.19, виконання запиту до застарілої точки доступу REST API:
Повертає заголовок Warning (як визначено у RFC7234, Розділ 5.5) у відповіді API.
Додає "k8s.io/deprecated":"true" анотацію до події аудиту, зареєстрованої для запиту.
Встановлює метрику apiserver_requested_deprecated_apis gauge у значення 1 у процесі kube-apiserver. Метрика має мітки group, version, resource, subresource, які можна поєднати з метрикою apiserver_request_total, і мітку removed_release, яка вказує випуск Kubernetes, в якому API більше не буде обслуговуватися. Наступний запит Prometheus повертає інформацію про запити, зроблені до застарілих API, які будуть видалені у версії v1.22:
Як і REST ресурси в цілому, так і окреме поле, яке було присутнє у версії API v1, має існувати та функціонувати до видалення API v1. На відміну від ресурсів в цілому, API v2 можуть вибрати інше представлення для поля, допоки є можливість виконувати перехід між версіями в обидва боки. Наприклад, поле v1 з назвою "magnitude", яке було застарілим, може називатися "deprecatedMagnitude" в API v2. Коли v1 врешті буде видалено, застаріле поле може бути видалене з v2.
Перераховані або константні значення
Як і для REST ресурсу в цілому, так і його полів, константне значення, яке підтримувалося в API v1, має існувати та функціонувати до видалення API v1.
Структури конфігурацій компонентів
Конфігурації компонентів версіонуються та керуються аналогічно до REST ресурсів.
Майбутні роботи
З часом Kubernetes запровадить більш детальні версії API, і тоді ці правила будуть скориговані за потреби.
Застарівання прапорця або CLI
Система Kubernetes складається з кількох різних програм, які співпрацюють між собою. Іноді випуск Kubernetes може видаляти прапорці або команди CLI (загалом "елементи CLI") у цих програмах. Програми природно діляться на дві основні групи — програми для користувачів і програми для адміністраторів, які трохи відрізняються своїми політиками застарівання. Якщо прапорець явно не позначено або задокументовано як "alpha" або "beta", він вважається стабільним (GA).
Елементи CLI фактично є частиною API до системи, але оскільки вони не версіонуються так само, як REST API, правила застарівання наступні:
Правило №5а: Елементи CLI компонентів для користувачів (наприклад, kubectl) повинні функціонувати після оголошення їх застарівання не менше ніж:
GA: 12 місяців або 2 випуски (залежно від того, що довше)
Beta: 3 місяці або 1 випуск (залежно від того, що довше)
Alpha: 0 випусків
Правило №5б: Елементи CLI компонентів для адміністраторів (наприклад, kubelet) повинні функціонувати після оголошення їх застарівання не менше ніж:
GA: 6 місяців або 1 випуск (залежно від того, що довше)
Beta: 3 місяці або 1 випуск (залежно від того, що довше)
Alpha: 0 випусків
Правило №5в: Елементи командного інтерфейсу (CLI) не можуть бути застарілими на користь менш стабільних елементів CLI.
Схоже на Правило №3 для API, якщо елемент інтерфейсу командного рядка замінюється альтернативною реалізацією, наприклад, перейменуванням наявного елемента або переходом на використання конфігурації, отриманої з файлу, замість аргументу командного рядка, ця рекомендована альтернатива повинна мати той самий або вищий рівень стабільності.
Правило №6: Застарілі елементи CLI повинні видавати попередження (можливо, такі, що відключаються) при використанні.
Застарівання функціонала або поведінки
Час від часу випуск Kubernetes потребує визнання застарілим певного функціонала або поведінки системи, яка не контролюється API або CLI. У цьому випадку правила застарівання такі:
Правило №7: Застарілі функції повинні функціонувати не менше 1 року після оголошеного застарівання.
Якщо функцію або поведінку замінює альтернативна реалізація, яка вимагає роботи для переходу, повинні бути зусилля спростити перехід, якщо це можливо. Якщо альтернативна реалізація контролюється організацією Kubernetes, застосовуються наступні правила:
Правило №8: Функцію або поведінку не можна визнати застарілою на користь альтернативної реалізації, яка менш стабільна.
Наприклад, загальнодоступну функцію не можна визнати застарілою на користь бета-заміщення. Проєкт Kubernetes, однак, закликає користувачів переходити на альтернативні реалізації навіть до досягнення ними того самого рівня зрілості. Це особливо важливо для дослідження нових використань функції або отримання раннього зворотного звʼязку щодо заміщення.
Альтернативні реалізації іноді можуть бути зовнішніми інструментами або продуктами, наприклад, функція може перейти від kubelet до середовища виконання контейнерів, яке не контролюється проєктом Kubernetes. У таких випадках правило не може бути застосоване, але повинні бути зусилля, щоб забезпечити наявність шляху переходу, який не компрометує рівень зрілості компонентів. У прикладі з середовищами виконання контейнерів, зусилля можуть включати спроби забезпечити те, що популярні середовища виконання контейнерів мають версії, які пропонують такий самий рівень стабільності під час впровадження цієї заміни.
Правила застарівання для функцій та поведінки не означають, що всі зміни в системі керуються цією політикою. Ці правила застосовуються тільки до значних, видимих для користувача поведінок, які впливають на правильність роботи програм, що працюють на Kubernetes або впливають на адміністрування кластерів Kubernetes, і які повністю видаляються.
Виняток з вищезазначеного правила — це функціональні можливості. Функціональні можливості — це пари ключ=значення, які дозволяють користувачам увімкнути/вимкнути експериментальні функції.
Функціональні можливості призначені для охоплення життєвого циклу розробки функції — вони не призначені для API, що мають існувати довгий час. Таким чином, очікується, що вони будуть застарілі та видалені після того, як функція стане GA або буде відкинута.
Під час руху функції через стадії, повʼязані функціональні можливості, змінюються. Життєвий цикл функції, збігається з їх відповідними функціональними можливостями, такий:
Alpha: функціональні можливості стандартно вимкнені та можуть бути увімкнені користувачем.
Beta: функціональні можливості стандартно увімкнені та можуть бути вимкнені користувачем.
GA: функціональні можливості застарілі (див. "Застарівання") і стають нечинними.
GA, вікно застарівання завершено: функціональні можливості видаляються, і виклики до них більше не приймаються.
Застарівання
Функції можуть бути видалені на будь-якому етапі життєвого циклу до GA. Коли функції видаляються перед виходом GA, їхні повʼязані функціональні можливості також застарівають.
Якщо виконується спроба вимкнути нечинні функціональні можливості, виклик не вдається, щоб уникнути непідтримуваних сценаріїв, які в іншому випадку можуть працювати мовчки.
У деяких випадках видалення функцій до виходу GA вимагає значного часу. Функціональні можливості можуть залишатися чинними до тих пір, поки повʼязана з ними функція не буде повністю видалена, після чого самі функціональні можливості можуть бути визнані застарілими.
Коли видалення функціональних можливостей для GA-функції також вимагає значного часу, виклики до функціональних можливостей можуть залишатися чинними, якщо функціональні можливості не впливають на функцію і не викликають помилок.
Функції, які мають бути вимкнені користувачами, повинні включати механізм для вимкнення функції в повʼязаних функціональних можливостях.
Версіонування для функціональних можливостей відрізняється від раніше обговорених компонентів, тому правила застарівання такі:
Правило №9: Функціональні можливості повинні бути визнані застарілими, коли відповідна функція, якою вони керують, переходить на етап життєвого циклу наступним чином. Функціональні можливості повинні функціонувати не менше ніж:
Від бета-функції до GA: 6 місяців або 2 випуски (залежно від того, що довше)
Від бета-функції до EOL: 3 місяці або 1 випуск (залежно від того, що довше)
Від альфа-функції до EOL: 0 випусків
Правило №10: Застарілі функціональні можливості повинні відповідати попередженням при використанні. Коли функціональні можливості застарівають, вони повинні бути задокументовані як в примітках про випуски, так і в відповідній довідці CLI. Як попередження, так і документація повинні вказувати, чи є функціональні можливості нечинними.
Застарівання метрики
Кожен компонент панелі управління Kubernetes використовує метрики (зазвичай за допомогою точки доступу /metrics), які зазвичай обробляються адміністраторами кластера. Не всі метрики однакові: деякі метрики широко використовуються як показники рівня сервісу (SLI) або для визначення SLO, тому вони мають більшу важливість. Інші метрики мають більш експериментальний характер або використовуються переважно у процесі розробки Kubernetes.
Відповідно, метрики поділяються на три класи стабільності (ALPHA, BETA, STABLE); це впливає на видалення метрики під час випуску Kubernetes. Ці класи визначаються важливістю метрики. Правила для застарівання та видалення метрики такі:
Правило №11а: Метрики для відповідного класу стабільності повинні функціонувати не менше ніж:
STABLE: 4 випуски або 12 місяців (що довше)
BETA: 2 випуски або 8 місяців (що довше)
ALPHA: 0 випусків
Правило №11б: Метрики, після їх оголошеного застарівання, повинні функціонувати не менше ніж:
STABLE: 3 випуски або 9 місяців (що довше)
BETA: 1 випуск або 4 місяці (що довше)
ALPHA: 0 випусків
Застарілі метрики будуть мати текст опису, у якому буде префікс з повідомленням про застарівання '(Застаріло з x.y)', і під час реєстрації метрики буде запис в лог з попередженням. Подібно до їх стабільних незастарілих аналогів, застарілі метрики будуть автоматично зареєстровані в точці доступу метрик і, отже, будуть видимими.
У наступному випуску (коли deprecatedVersion метрики дорівнює current_kubernetes_version - 3)), застаріла метрика стане прихованою метрикою. На відміну від їх застарілих аналогів, приховані метрики більше не будуть автоматично реєструватися в точці доступу метрик (таким чином, вони будуть приховані). Однак їх можна буде явно увімкнути через прапорець командного рядка (--show-hidden-metrics-for-version=). Це надає адміністраторам кластера можливість виходу зі складностей з міграцією від застарілої метрики, якщо вони не змогли відреагувати на раніше надані попередження щодо застарівання. Приховані метрики повинні бути видалені після одного випуску.
Винятки
Жодна політика не може охопити кожну можливу ситуацію. Ця політика є живим документом і буде розвиватися з часом. На практиці будуть ситуації, які не підпадають під цю політику чітко або для яких ця політика стає серйозною перешкодою. Такі ситуації слід обговорювати з SIGs та керівниками проєкту, щоб знайти найкращі рішення для конкретних випадків, завжди памʼятаючи, що Kubernetes прагне бути стабільною системою, яка, наскільки це можливо, ніколи не підводить користувачів. Винятки завжди будуть оголошені в усіх відповідних повідомленням про випуски.
2.6 - Посібник з міграції від застарілих API
Під час еволюції API Kubernetes періодично переглядаються або оновлюються. Коли API розвиваються, старий API стає застарілим і, зрештою, вилучається. Ця сторінка містить інформацію, яку вам потрібно знати у випадку міграції від застарілих версій API на новіші та стабільніші версії API.
Вилучені API в розрізі версій
v1.32
У випуску v1.32 перестануть обслуговуватися наступні застарілі версії API:
Ресурси контролю потоку
Версія API flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema та PriorityLevelConfiguration більше не буде обслуговуватися у v1.32.
Перенесіть маніфести та клієнти API на використання версії API flowcontrol.apiserver.k8s.io/v1, доступної з версії v1.29.
Усі наявні збережені обʼєкти доступні через новий API
Значні зміни у flowcontrol.apiserver.k8s.io/v1:
Поле spec.limited.nominalConcurrencyShares PriorityLevelConfiguration має стандартне значення 30, коли не вказане, і явне значення 0 не змінюється на 30.
v1.29
У випуску v1.29 перестали обслуговуватися наступні застарілі версії API:
Ресурси контролю потоку
Версія API flowcontrol.apiserver.k8s.io/v1beta2 FlowSchema та PriorityLevelConfiguration більше не обслуговується з версії v1.29.
Перенесіть маніфести та клієнти API на використання версії API flowcontrol.apiserver.k8s.io/v1, доступної з версії v1.29, або версії API flowcontrol.apiserver.k8s.io/v1beta3, доступної з версії v1.26.
Усі наявні збережені обʼєкти доступні через новий API
Значні зміни в flowcontrol.apiserver.k8s.io/v1:
Поле spec.limited.assuredConcurrencyShares PriorityLevelConfiguration перейменоване на spec.limited.nominalConcurrencyShares і має стандартне значення 30, коли не вказане, і явне значення 0 не змінюється на 30.
Значні зміни в flowcontrol.apiserver.k8s.io/v1beta3:
Поле spec.limited.assuredConcurrencyShares PriorityLevelConfiguration перейменоване на spec.limited.nominalConcurrencyShares
v1.27
Випуск v1.27 припинив обслуговування наступних застарілих версій API:
CSIStorageCapacity
Версія API CSIStorageCapacity storage.k8s.io/v1beta1 більше не обслуговується з версії v1.27.
Перенесіть маніфести та клієнти API на версію API storage.k8s.io/v1, доступну з версії v1.24.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Немає помітних змін
v1.26
Випуск v1.26 припинив обслуговування наступних застарілих версій API:
Ресурси керування потоком
Версія API FlowSchema та PriorityLevelConfiguration flowcontrol.apiserver.k8s.io/v1beta1 більше не обслуговується з версії v1.26.
Перенесіть маніфести та клієнти API на версію API flowcontrol.apiserver.k8s.io/v1beta2.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Немає помітних змін
HorizontalPodAutoscaler
Версія API HorizontalPodAutoscaler autoscaling/v2beta2 більше не обслуговується з версії v1.26.
Перенесіть маніфести та клієнти API на версію API autoscaling/v2, доступну з версії v1.23.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Випуск v1.25 припинив обслуговування наступних застарілих версій API:
CronJob
Версія API CronJob batch/v1beta1 більше не обслуговується з версії v1.25.
Перенесіть маніфести та клієнти API на версію API batch/v1, доступну з версії v1.21.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Немає помітних змін
EndpointSlice
Версія API EndpointSlice discovery.k8s.io/v1beta1 більше не обслуговується з версії v1.25.
Перенесіть маніфести та клієнти API на версію API discovery.k8s.io/v1, доступну з версії v1.21.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Помітні зміни в discovery.k8s.io/v1:
використовуйте поле nodeName для кожного Endpoint замість застарілого поля topology["kubernetes.io/hostname"]
використовуйте поле zone для кожного Endpoint замість застарілого поля topology["topology.kubernetes.io/zone"]
topology замінено полем deprecatedTopology, яке не доступне для запису у v1
Event
Версія API Event events.k8s.io/v1beta1 більше не обслуговується з версії v1.25.
Перенесіть маніфести та клієнти API на версію API events.k8s.io/v1, доступну з версії v1.19.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Помітні зміни в events.k8s.io/v1:
type обмежено до Normal та Warning
involvedObject перейменовано в regarding
action, reason, reportingController та reportingInstance є обовʼязковими при створенні нових events.k8s.io/v1 Events
використовуйте eventTime замість застарілого поля firstTimestamp (яке перейменовано в deprecatedFirstTimestamp та не допускається в нових events.k8s.io/v1 Events)
використовуйте series.lastObservedTime замість застарілого поля lastTimestamp (яке перейменовано в deprecatedLastTimestamp та не допускається в нових **events.k8ерсіях API events.k8s.io/v1 Events)
використовуйте series.count замість застарілого поля count (яке перейменовано в deprecatedCount та не допускається в нових events.k8s.io/v1 Events)
використовуйте reportingController замість застарілого поля source.component (яке перейменовано в deprecatedSource.component та не допускається в нових events.k8s.io/v1 Events)
використовуйте reportingInstance замість застарілого поля source.host (яке перейменовано в deprecatedSource.host та не допускається в нових events.k8s.io/v1 Events)
HorizontalPodAutoscaler
Версія API HorizontalPodAutoscaler autoscaling/v2beta1 більше не обслуговується з версії v1.25.
Перенесіть маніфести та клієнти API на версію API autoscaling/v2, доступну з версії v1.23.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Версія API PodDisruptionBudget policy/v1beta1 більше не обслуговується з версії v1.25.
Перенесіть маніфести та клієнти API на версію API policy/v1, доступну з версії v1.21.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Помітні зміни в policy/v1:
пустий spec.selector ({}), записаний до policy/v1 PodDisruptionBudget, вибирає всі теки в просторі імен (у policy/v1beta1 пустий spec.selector не вибирав жодні теки). Неустановлений spec.selector вибирає жодні теки в обох версіях API.
PodSecurityPolicy
PodSecurityPolicy в версії API policy/v1beta1 більше не обслуговується з версії v1.25, і контролер допуску PodSecurityPolicy буде видалено.
RuntimeClass в версії API node.k8s.io/v1beta1 більше не обслуговується з версії v1.25.
Перенесіть маніфести та клієнти API на версію API node.k8s.io/v1, доступну з версії v1.20.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Немає помітних змін
v1.22
Випуск v1.22 припинив обслуговування наступних застарілих версій API:
Ресурси вебхуків
Версія API admissionregistration.k8s.io/v1beta1 для MutatingWebhookConfiguration та ValidatingWebhookConfiguration більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API admissionregistration.k8s.io/v1, доступну з версії v1.16.
Усі наявні обʼєкти, які зберігаються, доступні через нові API
Помітні зміни:
стандартно webhooks[*].failurePolicy змінено з Ignore на Fail для v1
стандартно webhooks[*].matchPolicy змінено з Exact на Equivalent для v1
стандартно webhooks[*].timeoutSeconds змінено з 30s на 10s для v1
поле webhooks[*].sideEffects стандартно видалено, і тепер воно обовʼязкове,
і дозволяється лише None та NoneOnDryRun для v1
стандартно видалено значення поля webhooks[*].admissionReviewVersions та робиться обовʼязковим для v1 (підтримувані версії для AdmissionReview - v1 та v1beta1)
поле webhooks[*].name повинно бути унікальним в списку для обʼєктів, створених через admissionregistration.k8s.io/v1
CustomResourceDefinition
Версія API apiextensions.k8s.io/v1beta1 для CustomResourceDefinition більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API apiextensions.k8s.io/v1, доступну з версії v1.16.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Помітні зміни:
поле spec.scope тепер не має станадртного значення Namespaced і повинно бути явно вказано
поле spec.version вилучено в v1; використовуйте замість цього spec.versions
поле spec.validation вилучено в v1; використовуйте замість цього spec.versions[*].schema
поле spec.subresources вилучено в v1; використовуйте замість цього spec.versions[*].subresources
поле spec.additionalPrinterColumns вилучено в v1; використовуйте замість цього spec.versions[*].additionalPrinterColumns
spec.conversion.webhookClientConfig переміщено в spec.conversion.webhook.clientConfig в v1
spec.conversion.conversionReviewVersions переміщено в spec.conversion.webhook.conversionReviewVersions в v1
поле spec.versions[*].schema.openAPIV3Schema тепер обовʼязкове при створенні обʼєктів CustomResourceDefinition для v1, і повинно бути структурною схемою
spec.preserveUnknownFields: true заборонено при створенні обʼєктів CustomResourceDefinition для v1; воно повинно бути вказано у визначеннях схем як x-kubernetes-preserve-unknown-fields: true
В елементах additionalPrinterColumns поле JSONPath перейменовано в jsonPath в v1
(виправлення #66531)
APIService
Версія API apiregistration.k8s.io/v1beta1 для APIService більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API apiregistration.k8s.io/v1, доступну з версії v1.10.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Немає помітних змін
TokenReview
Версія API authentication.k8s.io/v1beta1 для TokenReview більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API authentication.k8s.io/v1, доступну з версії v1.6.
Немає помітних змін
Ресурси SubjectAccessReview
Версія API authorization.k8s.io/v1beta1 для LocalSubjectAccessReview, SelfSubjectAccessReview, SubjectAccessReview та SelfSubjectRulesReview більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API authorization.k8s.io/v1, доступну з версії v1.6.
Помітні зміни:
Поле spec.group перейменовано на spec.groups в v1 (виправляє #32709)
CertificateSigningRequest
Версія API certificates.k8s.io/v1beta1 для CertificateSigningRequest більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API certificates.k8s.io/v1, доступну з версії v1.19.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Помітні зміни в certificates.k8s.io/v1:
Для API-клієнтів, що запитують сертифікати:
Поле spec.signerName тепер обовʼязкове
(див. відомі підписувачи Kubernetes), і запити на kubernetes.io/legacy-unknown не дозволяються бути створеними через API certificates.k8s.io/v1
Поле spec.usages тепер обовʼязкове, не може містити дубльованих значень та повинно містити лише відомі використання
Для API-клієнтів, що схвалюють або підписують сертифікати:
status.conditions не може містити дублюються типи
status.conditions[*].status тепер обовʼязкове
status.certificate повинно бути в кодуванні PEM та містити лише блоки CERTIFICATE
Lease
Версія API coordination.k8s.io/v1beta1 для Lease більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API coordination.k8s.io/v1, доступну з версії v1.14.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Немає помітних змін
Ingress
Версії API extensions/v1beta1 та networking.k8s.io/v1beta1 для Ingress більше не обслуговуються з версії v1.22.
Перенесіть маніфести та клієнти API на версію API networking.k8s.io/v1, доступну з версії v1.19.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Помітні зміни:
Поле spec.backend перейменовано на spec.defaultBackend
Поле serviceName бекенду перейменовано на service.name
Числові поля servicePort бекенду перейменовані на service.port.number
Рядкові поля servicePort бекенду перейменовані на service.port.name
pathType тепер обовʼязковий для кожного вказаного шляху. Варіанти — Prefix, Exact, та ImplementationSpecific. Для відповідності невизначеній поведінці v1beta1 використовуйте ImplementationSpecific.
IngressClass
Версія API networking.k8s.io/v1beta1 для IngressClass більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API networking.k8s.io/v1, доступну з версії v1.19.
Усі наявні обʼєкти, які зберігаються, доступні через новий API
Немає помітних змін
Ресурси RBAC
Версія API rbac.authorization.k8s.io/v1beta1 для ClusterRole, ClusterRoleBinding,
Role та RoleBinding більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API rbac.authorization.k8s.io/v1, доступну з версії v1.8.
Усі наявні обʼєкти, які зберігаються, доступні через нові API
Немає помітних змін
PriorityClass
Версія API scheduling.k8s.io/v1beta1 для PriorityClass більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API scheduling.k8s.io/v1, доступну з версії v1.14.
Усі наявні обʼєкти, які зберігаються, доступні через новий API.
Немає помітних змін.
Ресурси зберігання
Версія API storage.k8s.io/v1beta1 для CSIDriver, CSINode, StorageClass та VolumeAttachment більше не обслуговується з версії v1.22.
Перенесіть маніфести та клієнти API на версію API storage.k8s.io/v1
CSIDriver доступний у storage.k8s.io/v1 починаючи з версії v1.19.
CSINode доступний у storage.k8s.io/v1 починаючи з версії v1.17.
StorageClass доступний у storage.k8s.io/v1 починаючи з версії v1.6.
VolumeAttachment доступний у storage.k8s.io/v1 з версії v1.13.
Усі наявні обʼєкти, які зберігаються, доступні через нові API.
Немає помітних змін.
v1.16
Випуск v1.16 припинив обслуговування наступних застарілих версій API:
Мережева політика
Версія API extensions/v1beta1 для NetworkPolicy більше не обслуговується з версії v1.16.
Перенесіть маніфести та клієнти API на версію API networking.k8s.io/v1, доступну з версії v1.8.
Усі наявні обʼєкти, які зберігаються, доступні через новий API.
DaemonSet
Версії API extensions/v1beta1 та apps/v1beta2 для DaemonSet більше не обслуговуються з версії v1.16.
Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
Усі наявні обʼєкти, які зберігаються, доступні через новий API.
Помітні зміни:
spec.templateGeneration видалено.
spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.
spec.updateStrategy.type тепер стандартно встановлено на RollingUpdate
(стандартно в extensions/v1beta1 було OnDelete).
Deployment
Версії API extensions/v1beta1, apps/v1beta1 та apps/v1beta2 для Deployment більше не обслуговуються з версії v1.16.
Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
Усі наявні обʼєкти, які зберігаються, доступні через новий API.
Помітні зміни:
spec.rollbackTo видалено.
spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.
spec.progressDeadlineSeconds тепер стандартно встановлено на 600 секунд
(стандартно в extensions/v1beta1 було без крайнього терміну).
spec.revisionHistoryLimit тепер стандартно встановлено на 10
(стандартно в apps/v1beta1 було 2, стандартно в extensions/v1beta1 було зберігати всі).
maxSurge та maxUnavailable тепер стандартно встановлено на 25%
(стандартно в extensions/v1beta1 було 1).
StatefulSet
Версії API apps/v1beta1 та apps/v1beta2 для StatefulSet більше не обслуговуються з версії v1.16.
Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
Усі наявні обʼєкти, які зберігаються, доступні через новий API.
Помітні зміни:
spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.
spec.updateStrategy.type тепер за замовчуванням встановлено на RollingUpdate
(стандартно в apps/v1beta1 було OnDelete).
ReplicaSet
Версії API extensions/v1beta1, apps/v1beta1 та apps/v1beta2 для ReplicaSet більше не обслуговуються з версії v1.16.
Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
Усі наявні обʼєкти, які зберігаються, доступні через новий API.
Помітні зміни:
spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.
PodSecurityPolicy
Версія API extensions/v1beta1 для PodSecurityPolicy більше не обслуговується з версії v1.16.
Перенесіть маніфести та клієнти API на версію API policy/v1beta1, доступну з версії v1.10.
Зауважте, що версія API policy/v1beta1 для PodSecurityPolicy буде видалена у версії v1.25.
Що робити
Тестування з вимкненими застарілими API
Ви можете протестувати свої кластери, запустивши API сервер зі конкретними вимкненими версіями API, щоб змоделювати майбутні видалення. Додайте наступний прапорець до аргументів запуску API сервера:
Це перетворення може використовувати не ідеальні стандартні значення. Щоб дізнатися більше про конкретний ресурс, зверніться до довідника API Kubernetes.
Примітка:
Інструмент kubectl convert не стандартно встановлюється, хоча раніше він був частиною самого kubectl. Для отримання додаткової інформації ви можете прочитати питання про застарілість та видалення для вбудованої підкоманди.
Щоб дізнатися, як налаштувати kubectl convert на вашому компʼютері, відвідайте сторінку, яка відповідає вашій операційній системі:
Linux,
macOS або
Windows.
2.7 - Точки доступу для моніторингу стану API Kubernetes
API сервер Kubernetes надає точки доступу API для індикації поточного стану API сервера. Ця сторінка описує ці точки доступу API та пояснює, як ви можете їх використовувати.
Точки доступу API для моніторингу стану
API сервер Kubernetes надає 3 точки доступу API (healthz, livez і readyz) для індикації поточного стану API сервера. Точка доступу healthz є застарілою (з Kubernetes v1.16), і ви повинні використовувати більш конкретні точки доступу livez та readyz. Точку доступу livez можна використовувати з прапорцем--livez-grace-period, щоб вказати тривалість запуску. Для належного завершення роботи ви можете вказати прапорець--shutdown-delay-duration з точкою доступу /readyz. Машини, що перевіряють healthz/livez/readyz API сервера, повинні покладатися на HTTP-код статусу. Код статусу 200 вказує, що API сервер є healthy/live/ready, залежно від викликаної точки доступу. Більш докладні опції, показані нижче, призначені для використання людьми-операторами для налагодження їх кластера або розуміння стану API сервера.
Наступні приклади покажуть, як ви можете взаємодіяти з точками доступу моніторингу стану API.
Для всіх точок доступу ви можете використовувати параметр verbose, щоб вивести перевірки та їхній стан. Це може бути корисно для оператора-людини для налагодження поточного стану API сервера, це не призначено для використання машинами:
curl -k https://localhost:6443/livez?verbose
або з віддаленого хосту з автентифікацією:
kubectl get --raw='/readyz?verbose'
Вивід буде виглядати наступним чином:
[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
healthz check passed
API сервер Kubernetes також підтримує виключення конкретних перевірок. Параметри запиту також можна комбінувати, як у цьому прикладі:
[+]ping ok
[+]log ok
[+]etcd excluded: ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]shutdown ok
healthz check passed
Індивідуальні перевірки стану
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.30 [alpha]
Кожна індивідуальна перевірка стану надає HTTP точку доступу і може бути перевірена індивідуально. Схема для індивідуальних перевірок стану — /livez/<healthcheck-name> або /readyz/<healthcheck-name>, де livez і readyz можуть бути використані для індикації, чи ви хочете перевірити liveness або readiness API сервера відповідно. Шлях <healthcheck-name> можна знайти, використовуючи прапорець verbose вище та шлях між [+] та ok. Ці індивідуальні перевірки стану не повинні використовуватися машинами, але можуть бути корисні для оператора-людини для налагодження системи:
У всіх кластерах Kubernetes є дві категорії користувачів: службові облікові записи, які керуються Kubernetes, і звичайні користувачі.
Припускається, що незалежна від кластера служба керує звичайними користувачами наступними способами:
адміністратор розповсюджує приватні ключі
сховище користувачів, таке як Keystone або Google Accounts
файл зі списком імен користувачів та паролів
У цьому відношенні Kubernetes не має обʼєктів, які представляють звичайні облікові записи користувачів. Звичайні користувачі не можуть бути додані до кластера через API виклик.
Хоча звичайного користувача не можна додати через API виклик, будь-який користувач, який предʼявляє дійсний сертифікат, підписаний центром сертифікації (CA) кластера, вважається автентифікованим. У цій конфігурації Kubernetes визначає імʼя користувача з поля загального імені (CN) у сертифікаті (наприклад, "/CN=bob"). Після цього підсистема контролю доступу на основі ролей (RBAC) визначає, чи авторизований користувач для виконання певної операції з ресурсом. Детальніше про це можна прочитати у темі про звичайних користувачів у запиті сертифікатів.
На відміну від цього, службові облікові записи є користувачами, якими керує Kubernetes API. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API виклики. Службові облікові записи привʼязані до набору облікових даних, збережених як Secrets, які монтуються в Podʼи, що дозволяє процесам всередині кластера взаємодіяти з Kubernetes API.
API запити привʼязані або до звичайного користувача, або до службово облікового запису, або обробляються як анонімні запити. Це означає, що кожен процес всередині або поза кластером, від користувача, який вводить kubectl на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен автентифікуватися при виконанні запитів до API сервера, або бути обробленим як анонімний користувач.
Стратегії автентифікації
Kubernetes використовує клієнтські сертифікати, токени на предʼявника (bearer tokens) або проксі для автентифікації (authenticating proxy) для автентифікації API запитів через втулки автентифікації. Під час виконання HTTP запитів до API сервера втулки намагаються асоціювати наступні атрибути із запитом:
Імʼя користувача: рядок, який ідентифікує кінцевого користувача. Загальноприйняті значення можуть бути kube-admin або jane@example.com.
UID: рядок, який ідентифікує кінцевого користувача та намагається бути більш стабільним і унікальним, ніж імʼя користувача.
Групи: набір рядків, кожен з яких вказує на членство користувача в певній логічній групі користувачів. Загальноприйняті значення можуть бути system:masters або devops-team.
Додаткові поля: елемент map рядків для отримання переліку рядків, що містить додаткову інформацію, яку авторизатори можуть вважати корисною.
Усі значення є непрозорими для системи автентифікації та мають значення лише при інтерпретації авторизатором.
Ви можете одночасно ввімкнути кілька методів автентифікації. Зазвичай вам слід використовувати принаймні два методи:
токени службових облікових записів
принаймні один інший метод для автентифікації користувачів.
Коли увімкнено кілька модулів автентифікаторів, перший модуль, який успішно автентифікує запит, перериває подальшу оцінку. API сервер не гарантує порядок виконання автентифікаторів.
Група system:authenticated включена до списку груп для всіх автентифікованих користувачів.
Інтеграції з іншими протоколами автентифікації (LDAP, SAML, Kerberos, альтернативні схеми x509 тощо) можуть бути здійснені за допомогою проксі автентифікації або вебхука автентифікації.
X509 клієнтські сертифікати
Автентифікація за допомогою клієнтських сертифікатів увімкнена шляхом передачі опції --client-ca-file=SOMEFILE до API сервера. Вказаний файл повинен містити один або більше центрів сертифікації для використання у валідації клієнтських сертифікатів, представлених API серверу. Якщо представлено клієнтський сертифікат і він підтверджений, загальне імʼя субʼєкта використовується як імʼя користувача для запиту. Починаючи з Kubernetes 1.4, клієнтські сертифікати також можуть вказувати на членство користувача в групах, використовуючи поля організації сертифіката. Щоб включити кілька членств у групах для користувача, включіть кілька полів організації в сертифікат.
Наприклад, використовуючи командний рядок openssl для генерації запиту на підпис сертифіката:
Це створить CSR для імені користувача "jbeda", який належить до двох груп, "app1" і "app2".
Дивіться Керування сертифікатами для отримання інформації про те, як створити клієнтський сертифікат.
Статичний файл токенів
API сервер читає токени на предʼявника (bearer tokens) з файлу при використанні опції --token-auth-file=SOMEFILE у командному рядку. Наразі токени діють безстроково, і список токенів не можна змінити без перезавантаження API сервера.
Файл токенів є csv-файлом з мінімум 3 стовпцями: токен, імʼя користувача, uid користувача, а також необовʼязкові імена груп.
Примітка:
Якщо у вас є більше однієї групи, стовпець має бути взятий у подвійні лапки, наприклад:
token,user,uid,"group1,group2,group3"
Використання токена на предʼявника у запиті
При використанні автентифікації за допомогою токенів з HTTP клієнта, API сервер очікує заголовок Authorization зі значенням Bearer <token>. Маркер має бути послідовністю символів, яку можна помістити в значення HTTP заголовка, використовуючи лише можливості кодування та цитування HTTP. Наприклад, якщо токен — 31ada4fd-adec-460c-809a-9e56ceb75269, тоді він буде виглядати у заголовку HTTP, як показано нижче.
Для спрощення початкового налаштування нових кластерів, Kubernetes включає тип токена на предʼявника (bearer token), який керується динамічно, так званий Bootstrap Token. Ці токени зберігаються як Secrets у просторі імен kube-system, де ними можна динамічно керувати та створювати. Менеджер контролерів містить контролер TokenCleaner, який видаляє bootstrap токени в міру їх завершення.
Токени мають форму [a-z0-9]{6}.[a-z0-9]{16}. Перший компонент є ID токена, а другий компонент є Secret токена. Ви вказуєте токен у HTTP заголовку наступним чином:
Authorization: Bearer 781292.db7bc3a58fc5f07e
Ви повинні увімкнути Bootstrap Token Authenticator з прапорцем --enable-bootstrap-token-auth на API сервері. Ви повинні увімкнути контролер TokenCleaner за допомогою прапорця --controllers у Controller Manager. Це робиться за допомогою чогось типу --controllers=*,tokencleaner. kubeadm зробить це за вас, якщо ви використовуєте його для початкового налаштування кластера.
Автентифікатор автентифікує як system:bootstrap:<Token ID>. Він включений у групу system:bootstrappers. Імена користувачів та групи навмисно обмежені, щоб перешкоджати користувачам використовувати ці токени після початкового налаштування. Імена користувачів та групи можна використовувати (і використовуються kubeadm) для створення відповідних політик авторизації для підтримки початкового налаштування кластера.
Детальнішу інформацію про автентифікатор Bootstrap Token та контролери, а також про керування цими токенами за допомогою kubeadm, дивіться у Bootstrap Tokens.
Токени службових облікових записів
Службовий обліковий запис є автоматично увімкненим автентифікатором, який використовує підписані токени на предʼявника (bearer tokens) для перевірки запитів. Втулок приймає два необовʼязкові прапорці:
--service-account-key-file Файл, що містить PEM-кодовані x509 RSA або ECDSA приватні або публічні ключі, що використовуються для перевірки токенів службових облікових записів. Вказаний файл може містити кілька ключів, і прапорець може бути вказаний кілька разів з різними файлами. Якщо не вказано, використовується --tls-private-key-file.
--service-account-lookup Якщо увімкнено, токени, які видаляються з API, будуть відкликані.
Службові облікові записи зазвичай створюються автоматично API сервером та асоціюються з Podʼами, які працюють у кластері через ServiceAccountКонтролер допуску. Токени на предʼявника (bearer tokens) монтуються в Podʼи у відомих місцях, що дозволяє процесам всередині кластера взаємодіяти з API сервером. Облікові записи можуть бути явно асоційовані з Podʼами, використовуючи поле serviceAccountName у PodSpec.
Примітка:
serviceAccountName зазвичай опускається, оскільки це робиться автоматично.
apiVersion:apps/v1# ця apiVersion актуальна станом з Kubernetes 1.9kind:Deploymentmetadata:name:nginx-deploymentnamespace:defaultspec:replicas:3template:metadata:# ...spec:serviceAccountName:bob-the-botcontainers:- name:nginximage:nginx:1.14.2
Токени на предʼявника службових облікових записів (bearer tokens) є цілком дійсними для використання за межами кластера і можуть бути використані для створення ідентичностей для тривалих завдань, які бажають взаємодіяти з API Kubernetes. Щоб вручну створити службовий обліковий запис, використовуйте команду kubectl create serviceaccount (NAME). Це створює службовий обліковий запис у поточному просторі імен.
kubectl create serviceaccount jenkins
serviceaccount/jenkins created
Створіть асоційований токен:
kubectl create token jenkins
eyJhbGciOiJSUzI1NiIsImtp...
Створений токен є підписаним JSON Web Token (JWT).
Підписаний JWT може бути використаний як токен на предʼявника (bearer token) для автентифікації як вказаний службовий обліковий запис. Дивіться вище для інформації про те, як токен включається у запит. Зазвичай ці токени монтуються в Podʼи для доступу до API сервера всередині кластера, але можуть бути використані й ззовні кластера.
Службові облікові записи автентифікуються з імʼям користувача system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT), і належать групам system:serviceaccounts та system:serviceaccounts:(NAMESPACE).
Попередження:
Оскільки токени службових облікових записів також можуть зберігатися в обʼєктах Secret API, будь-який користувач з правами на запис до Secrets може запитати токен, і будь-який користувач з правами на читання до тих Secrets може автентифікуватися як службовий обліковий запис. Будьте обережні при наданні дозволів на службові облікові записи та можливості читання або запису для Secrets.
Токени OpenID Connect
OpenID Connect — це варіант OAuth2, підтримуваний деякими провайдерами OAuth2, зокрема Microsoft Entra ID, Salesforce та Google. Головне розширення протоколу OAuth2 полягає в додатковому полі, яке повертається разом із токеном доступу, називається ID Token. Цей токен є JSON Web Token (JWT) з добре відомими полями, такими як електронна пошта користувача, підписаними сервером.
Для ідентифікації користувача автентифікатор використовує id_token (а не access_token) з відповіді токена OAuth2 як токен носія. Дивіться вище для того, як токен включається у запит.
sequenceDiagram
participant user as Користувач
participant idp as Провайдер ідентичності
participant kube as kubectl
participant api as Сервер API
user ->> idp: 1. Вхід до Провайдера ідентичності
activate idp
idp -->> user: 2. Надання access_token, id_token та refresh_token
deactivate idp
activate user
user ->> kube: 3. Виклик kubectl з --token, що є id_token АБО додавання токенів до .kube/config
deactivate user
activate kube
kube ->> api: 4. Authorization: Bearer...
deactivate kube
activate api
api ->> api: 5. Чи є підпис JWT дійсним?
api ->> api: 6. Чи не минув термін дії JWT? (iat+exp)
api ->> api: 7. Чи авторизований користувач?
api -->> kube: 8. Авторизовано: Виконання дії та повернення результату
deactivate api
activate kube
kube --x user: 9. Повернення результату
deactivate kube
Увійдіть до свого провайдера ідентичності.
Ваш провайдер ідентичності надасть вам access_token, id_token та refresh_token.
Використовуючи kubectl, використовуйте свій id_token із прапорцем --token або додайте його безпосередньо до вашого kubeconfig.
kubectl надсилає ваш id_token у заголовку Authorization до сервера API.
Сервер API перевіряє, чи є підпис JWT дійсним.
Перевіряє, чи не минув термін дії id_token.
Виконує перевірку вимог та/або користувача, якщо з AuthenticationConfiguration налаштовані вирази CEL.
Переконується, що користувач авторизований.
Після авторизації сервер API повертає відповідь kubectl.
kubectl надає зворотній звʼязок користувачу.
Оскільки всі дані, необхідні для верифікації вашої особи, містяться в id_token, Kubernetes не потрібно "дзвонити додому" до провайдера ідентичності. У моделі, де кожен запит є stateless, це забезпечує дуже масштабоване рішення для автентифікації. Це має кілька викликів:
Kubernetes не має "вебінтерфейсу" для ініціювання процесу автентифікації. Немає оглядача або інтерфейсу для збору облікових даних, тому вам потрібно спочатку автентифікуватися у свого провайдера ідентичності.
id_token не можна відкликати, він схожий на сертифікат, тому він повинен бути короткостроковим (лише кілька хвилин), що може бути дуже незручним, оскільки потрібно отримувати новий токен кожні кілька хвилин.
Для автентифікації в панелі управління Kubernetes, ви повинні використовувати команду kubectl proxy або зворотний проксі, який вставляє id_token.
Налаштування сервера API
Використання прапорців
Щоб увімкнути втулок, налаштуйте наступні прапорці на сервері API:
Параметр
Опис
Приклад
Обовʼязковий
--oidc-issuer-url
URL провайдера, який дозволяє серверу API знаходити публічні ключі підпису. Приймаються лише URL-адреси, що використовують схему https://. Це зазвичай URL виявлення провайдера, змінений на порожній шлях
Якщо URL виявлення OIDC провайдера https://accounts.provider.example/.well-known/openid-configuration, значення повинно бути https://accounts.provider.example
Так
--oidc-client-id
Ідентифікатор клієнта, для якого мають бути видані всі токени.
kubernetes
Так
--oidc-username-claim
JWT вимога для використання як імені користувача. Стандартно sub, яке очікується що має бути унікальним ідентифікатором кінцевого користувача. Адміністратори можуть вибрати інші вимоги, такі як email або name, залежно від свого провайдера. Однак, вимоги, відмінні від email, будуть мати префікс URL провайдера, щоб уникнути зіткнень назв з іншими втулками.
sub
Ні
--oidc-username-prefix
Префікс, доданий до вимог імені користувача, щоб уникнути зіткнень з наявними іменами (наприклад, користувачами system:). Наприклад, значення oidc: створить імена користувачів, такі як oidc:jane.doe. Якщо цей прапорець не вказано, і значення --oidc-username-claim відрізняється від email, стандартний префікс ( Issuer URL )#, де ( Issuer URL ) — це значення --oidc-issuer-url. Значення - можна використовувати для відключення всіх префіксів.
oidc:
Ні
--oidc-groups-claim
JWT вимога для використання як групи користувача. Якщо вимога присутня, вона повинна бути масивом рядків.
groups
Ні
--oidc-groups-prefix
Префікс, доданий до вимог груп, щоб уникнути зіткнень з наявними назвами (наприклад, групами system:). Наприклад, значення oidc: створить назви груп, такі як oidc:engineering та oidc:infra.
oidc:
Ні
--oidc-required-claim
Пара ключ=значення, яка описує обовʼязкову вимогу в ID Token. Якщо встановлено, вимога перевіряється на наявність в ID Token з відповідним значенням. Повторіть цей прапорець, щоб вказати кілька вимог.
claim=value
Ні
--oidc-ca-file
Шлях до сертифіката для ЦС, який підписав вебсертифікат вашого провайдера ідентичності. Стандартно використовується кореневий ЦС хосту.
/etc/kubernetes/ssl/kc-ca.pem
Ні
--oidc-signing-algs
Прийняті алгоритми підпису. Стандартно "RS256".
RS512
Ні
Налаштування автентифікації з файлу
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.30 [beta]
JWT Автентифікатор є автентифікатором для автентифікації користувачів Kubernetes за допомогою токенів, що відповідають стандарту JWT. Автентифікатор спробує розібрати необроблений ID токен, перевірити, чи він підписаний налаштованим видавцем. Публічний ключ для перевірки підпису перевіряється на публічній точці доступу видавця за допомогою OIDC discovery.
Мінімальний допустимий JWT повинен містити наступні твердження:
{
"iss": "https://example.com", // має збігатися з issuer.url
"aud": ["my-app"], // принаймні один з елементів в issuer.audiences повинен збігатися з твердженням "aud" в наданих JWT.
"exp": 1234567890, // закінчення терміну дії токена у вигляді часу Unix (кількість секунд, що минули з 1 січня 1970 року UTC)
"<username-claim>": "user"// це твердження для імені користувача, налаштоване в claimMappings.username.claim або claimMappings.username.expression
}
Підхід з використанням конфігураційного файлу дозволяє налаштовувати декілька JWT автентифікаторів, кожен з унікальними issuer.url та issuer.discoveryURL. Конфігураційний файл навіть дозволяє використовувати CEL вирази для зіставлення тверджень на атрибути користувача, а також для перевірки тверджень та інформації про користувача. API сервер також автоматично перезавантажує автентифікатори при зміні конфігураційного файлу. Ви можете використовувати метрику apiserver_authentication_config_controller_automatic_reload_last_timestamp_seconds для моніторингу часу останнього перезавантаження конфігурації сервером API.
Необхідно вказати шлях до конфігураційного файлу автентифікації за допомогою прапорця --authentication-config на сервері API. Якщо ви хочете використовувати командні прапорці замість конфігураційного файлу, вони продовжать працювати як раніше. Щоб отримати нові можливості, такі як налаштування декількох автентифікаторів, встановлення декількох аудиторій для одного видавця, перейдіть на використання конфігураційного файлу.
Для Kubernetes версії v1.30, формат файлу структурованої конфігурації автентифікації є на рівні бета-версії, і механізм використання цієї конфігурації також є на рівні бета-версії. За умови, що ви не вимкнули спеціально функційну можливістьStructuredAuthenticationConfiguration для вашого кластера, ви можете увімкнути структуровану автентифікацію, вказавши аргумент командного рядка --authentication-config для kube-apiserver. Приклад файлу конфігурації структурованої автентифікації наведено нижче.
Примітка:
Якщо ви вкажете --authentication-config разом з будь-якими аргументами командного рядка --oidc-*, це є некоректною конфігурацією. У цій ситуації сервер API повідомить про помилку й одразу завершить роботу. Якщо ви хочете перейти на використання структурованої конфігурації автентифікації, вам потрібно видалити аргументи командного рядка --oidc-* і використовувати конфігураційний файл замість них.
---## УВАГА: це приклад конфігурації.# Не використовуйте це для вашого кластера!#apiVersion:apiserver.config.k8s.io/v1beta1kind:AuthenticationConfiguration# список автентифікаторів для автентифікації користувачів Kubernetes за допомогою токенів, що відповідають стандарту JWT.# максимальна кількість дозволених автентифікаторів – 64.jwt:- issuer:# URL має бути унікальним для всіх автентифікаторів.# URL не повинен конфліктувати з видавцем, налаштованим у --service-account-issuer.url:https://example.com# Те ж саме, що і --oidc-issuer-url.# discoveryURL, якщо вказано, замінює URL, що використовується для отримання інформації про виявлення,# замість використання "{url}/.well-known/openid-configuration".# Точно вказане значення використовується, тому "/.well-known/openid-configuration"# має бути включено у discoveryURL, якщо це потрібно.## Поле "issuer" у отриманій інформації про виявлення має збігатися з полем "issuer.url"# в AuthenticationConfiguration і буде використовуватися для перевірки твердження "iss" у наданих JWT.# Це для сценаріїв, коли точки доступу well-known та jwks розміщені в іншому# місці, ніж видавець (наприклад, локально в кластері).# discoveryURL має відрізнятися від URL, якщо вказано, і має бути унікальним для всіх автентифікаторів.discoveryURL:https://discovery.example.com/.well-known/openid-configuration# PEM-кодовані сертифікати CA, які використовуються для перевірки підключення при отриманні# інформації про виявлення. Якщо не вказано, буде використовуватися системний перевіряючий.# Те саме значення, що і вміст файлу, на який посилається прапорець --oidc-ca-file.certificateAuthority:<PEM-кодовані сертифікати CA> # audiences – це набір прийнятних аудиторій, для яких повинен бути виданий JWT.# Принаймні один з елементів повинен збігатися з твердженням "aud" у наданих JWT.audiences:- my-app# Те ж саме, що і --oidc-client-id.- my-other-app# це повинно бути встановлено на "MatchAny", коли вказано кілька аудиторій.audienceMatchPolicy:MatchAny# правила, що застосовуються для перевірки тверджень токена для автентифікації користувачів.claimValidationRules:# Те ж саме, що і --oidc-required-claim key=value.- claim:hdrequiredValue:example.com# Замість claim та requiredValue, ви можете використовувати expression для перевірки твердження.# expression – це вираз CEL, який оцінюється до булевого значення.# всі вирази повинні бути true для успішної перевірки.- expression:'claims.hd == "example.com"'# Повідомлення налаштовує повідомлення про помилку, яке відображається в логах сервера API, коли перевірка не вдається.message:твердження hd повинно бути встановлено у example.com- expression:'claims.exp - claims.nbf <= 86400'message:загальний час життя токена не повинен перевищувати 24 годиниclaimMappings:# username представляє опцію для атрибута імені користувача.# Це єдиний обовʼязковий атрибут.username:# Те ж саме, що і --oidc-username-claim. Взаємовиключно з username.expression.claim:"sub"# Те ж саме, що і --oidc-username-prefix. Взаємовиключно з username.expression.# якщо username.claim встановлено, username.prefix обовʼязково має бути встановлено.# Встановіть значення "" явно, якщо префікс не потрібен.prefix:""# Взаємовиключно з username.claim і username.prefix.# expression – це вираз CEL, який оцінюється як рядок.## 1. Якщо у виразі username.expression використовується 'claims.email', то 'claims.email_verified' має бути використано у# username.expression або extra[*].valueExpression або claimValidationRules[*].expression.# Приклад виразу правила валідації заявки, який автоматично збігається з валідацією# застосовується, коли username.claim має значення 'email' - 'claims.?email_verified.orValue(true)'.# 2. Якщо імʼя користувача, що оцінюється на основі виразу username.expression, є порожнім рядком, запит на автентифікацію# запит не буде виконано.expression:'claims.username + ":external-user"'# groups представляє опцію для атрибута групи.groups:# Те ж саме, що і --oidc-groups-claim. Взаємовиключно з groups.expression.claim:"sub"# Те ж саме, що і --oidc-groups-prefix. Взаємовиключно з groups.expression.# якщо groups.claim встановлено, groups.prefix обовʼязково має бути встановлено.# Встановіть значення "" явно, якщо префікс не потрібен.prefix:""# Взаємовиключно з groups.claim і groups.prefix.# expression – це вираз CEL, який оцінюється як рядок або список рядків.expression:'claims.roles.split(",")'# uid представляє опцію для атрибута унікального ідентифікатора.uid:# Взаємовиключно з uid.expression.claim:"sub"# Взаємовиключно з uid.claim.# expression – це вираз CEL, який оцінюється як рядок.expression:'claims.uid'# екстра атрибути для додавання до обʼєктв UserInfo. Ключі мають бути у вигляді шляху з префіксом домену та бути унікальними.extra:- key:"example.com/tenant"# valueExpression – це вираз CEL, який оцінюється як рядок або список рядків.valueExpression:'claims.tenant'# правила валідації, що застосовуються до фінального обʼєкта користувача.userValidationRules:# expression – це вираз CEL, який оцінюється до булевого значення.# всі вирази повинні бути true для успішної перевірки.- expression:"!user.username.startsWith('system:')"# message налаштовує повідомлення про помилку, яке відображається в логах сервера API, коли перевірка не вдається.message:'неможна використовувате це імʼя користувача, зарезервовано префіксом system:'- expression:"user.groups.all(group, !group.startsWith('system:'))"message:'неможна використовувате цю назву групи, зарезервовано префіксом system:'
Вираз правил валідації твердження (claim)
jwt.claimValidationRules[i].expression представляє вираз, який буде оцінений CEL. Вирази CEL мають доступ до вмісту корисного навантаження токена, організованого у змінну CEL claims.
claims - це карта імен тверджень (як рядків) до значень тверджень (будь-якого типу).
Вираз правила валідації користувача
jwt.userValidationRules[i].expression представляє вираз, який буде оцінений CEL. Вирази CEL мають доступ до вмісту userInfo, організованого у змінну CEL user. Зверніться до UserInfo API документації для отримання схеми user.
Вираз зіставлення твердження
jwt.claimMappings.username.expression, jwt.claimMappings.groups.expression, jwt.claimMappings.uid.expressionjwt.claimMappings.extra[i].valueExpression представляє вираз, який буде оцінений CEL. Вирази CEL мають доступ до вмісту корисного навантаження токена, організованого у змінну CEL claims. claims — зіствлення імен тверджень (як рядків) до значень тверджень (будь-якого типу).
apiVersion:apiserver.config.k8s.io/v1beta1kind:AuthenticationConfigurationjwt:- issuer:url:https://example.comaudiences:- my-appclaimValidationRules:- expression:'claims.hd == "example.com"'# маркер нижче не має цього твердження, тому перевірка не вдасться.message:the hd claim must be set to example.comclaimMappings:username:expression:'claims.username + ":external-user"'groups:expression:'claims.roles.split(",")'uid:expression:'claims.sub'extra:- key:'example.com/tenant'valueExpression:'claims.tenant'userValidationRules:- expression:"!user.username.startsWith('system:')"# tвибарз буде оцінений як true, тоож валідація пройде успішно.message: 'username cannot used reserved system:prefix'
Токен із зазначеною вище AuthenticationConfiguration не зможе автентифікуватись, оскільки твердження hd не має значення example.com. Сервер API поверне помилку 401 Unauthorized.
apiVersion:apiserver.config.k8s.io/v1beta1kind:AuthenticationConfigurationjwt:- issuer:url:https://example.comaudiences:- my-appclaimValidationRules:- expression:'claims.hd == "example.com"'message:the hd claim must be set to example.comclaimMappings:username:expression:'"system:" + claims.username'# це призведе до додавання префіксу "system:" до імені користувача і не пройде перевірку.groups:expression:'claims.roles.split(",")'uid:expression:'claims.sub'extra:- key:'example.com/tenant'valueExpression:'claims.tenant'userValidationRules:- expression:"!user.username.startsWith('system:')"# імʼя користувача буде system:foo, а вираз матиме значення false, тому перевірка не вдасться.message: 'username cannot used reserved system:prefix'
який не пройде перевірку користувача, оскільки ім’я користувача починається з system:. Сервер API поверне помилку 401 Unauthorized.
Обмеження
Розподілені твердження не працюють через вирази CEL.
Конфігурація селектора вихідного трафіку не підтримується для викликів до issuer.url та issuer.discoveryURL.
Kubernetes не надає провайдера ідентифікації OpenID Connect. Ви можете використовувати наявного публічного провайдера ідентифікації OpenID Connect (наприклад, Google або інші). Або ж ви можете запустити власного провайдера ідентифікації, такого як dex,
Keycloak, CloudFoundry UAA, або Tremolo Security's OpenUnison.
Для того, щоб провайдер ідентифікації працював з Kubernetes, він повинен:
Публічний ключ для перевірки підпису отримується з публічної точки доступу видавця за допомогою OIDC discovery. Якщо ви використовуєте файл конфігурації автентифікації, провайдер ідентифікації не обовʼязково має публічно відкривати точку доступу discovery. Ви можете розмістити точку доступу discovery в іншому місці, ніж видавець (наприклад, локально в кластері) і вказати issuer.discoveryURL у файлі конфігурації.
Працювати через TLS з не застарілими шифрами
Мати сертифікат, підписаний ЦС (навіть якщо ЦС не комерційний або самопідписаний)
Примітка щодо вимоги №3 вище, що потреби в сертифікаті, підписаного ЦС. Якщо ви розгортаєте власного провайдера ідентифікації (на відміну від одного з хмарних провайдерів, таких як Google або Microsoft), ви ПОВИІННІ мати сертифікат вебсервера провайдера ідентифікації, підписаний сертифікатом з прапорцем CA, встановленим на TRUE, навіть якщо він самопідписаний. Це повʼязано з тим, що реалізація клієнта TLS в GoLang дуже сувора до стандартів перевірки сертифікатів. Якщо у вас немає під рукою ЦС, ви можете використовувати скрипт gencert від команди Dex для створення простого ЦС і пари підписаного сертифіката та ключа. Або ви можете використовувати цей подібний скрипт, який генерує сертифікати SHA256 з довшим терміном дії та більшим розміром ключа.
Перший варіант — використання автентифікатора kubectl oidc, який встановлює id_token як токен на предʼявника для всіх запитів і оновлює токен після закінчення його терміну дії. Після того, як ви увійшли до свого провайдера, використовуйте kubectl, щоб додати ваші id_token, refresh_token, client_id та client_secret для налаштування втулка.
Провайдери, які не повертають id_token як частину відповіді на оновлення токена, не підтримуються цим втулком і повинні використовувати "Варіант 2" нижче.
kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url )\
--auth-provider-arg=client-id=( your client id )\
--auth-provider-arg=client-secret=( your client secret )\
--auth-provider-arg=refresh-token=( your refresh token )\
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate )\
--auth-provider-arg=id-token=( your id_token )
Як приклад, запустіть наведену нижче команду після автентифікації у постачальника ідентифікаційної інформації:
Після закінчення терміну дії вашого id_tokenkubectl спробує оновити ваш id_token за допомогою ваших refresh_token і client_secret, зберігаючи нові значення для refresh_token і id_token у вашому .kube/config.
Варіант 2 — Використання опції --token
Команда kubectl дозволяє передати токен за допомогою параметра --token. Скопіюйте та вставте id_token у цей параметр:
kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes
Автентифікація за допомогою вебхука
Автентифікація за допомогою вебхука — це механізм перевірки маркерів носіїв.
--authentication-token-webhook-config-file — файл конфігурації, який описує, як отримати доступ до віддаленого сервісу вебхука.
--authentication-token-webhook-cache-ttl — як довго кешувати рішення щодо автентифікації. Стандартно дві хвилини.
--authentication-token-webhook-version визначає, чи використовувати authentication.k8s.io/v1beta1 або authentication.k8s.io/v1
обʼєкти TokenReview для надсилання/отримання інформації від вебхука. Стандартно v1beta1.
Файл конфігурації використовує формат файлу kubeconfig. У файлі clusters посилається на віддалений сервіс, а
users посилається на вебхук API-сервера. Приклад:
# Версія API KubernetesapiVersion:v1# Тип обʼєкта APIkind:Config# clusters посилається на віддалений сервіс.clusters:- name:name-of-remote-authn-servicecluster:certificate-authority:/path/to/ca.pem # ЦС для перевірки віддаленого сервісу.server:https://authn.example.com/authenticate# URL віддаленого сервісу для запиту. 'https' рекомендовано для промислового застосування.# users посилається на конфігурацію вебхука API-сервера.users:- name:name-of-api-serveruser:client-certificate:/path/to/cert.pem# сертифікат для використання втулком вебхукаclient-key:/path/to/key.pem # ключ, що відповідає сертифікату# файли kubeconfig потребують контексту. Надати один для API-сервера.current-context:webhookcontexts:- context:cluster:name-of-remote-authn-serviceuser:name-of-api-servername:webhook
Коли клієнт намагається автентифікуватись на API-сервері за допомогою токена на предʼявника, як розглядалось вище, вебхук автентифікації надсилає POST-запит з JSON-серіалізованим обʼєктом TokenReview, що містить токен для віддаленого сервісу.
Зверніть увагу, що обʼєкти API вебхука підпадають під ті ж правила сумісності версій, що й інші обʼєкти API Kubernetes. Виконавці повинні перевірити поле apiVersion запиту, щоб забезпечити правильну десеріалізацію, і повинні відповідати обʼєктом TokenReview тієї ж версії, що й запит.
API-сервер Kubernetes типово надсилає запити authentication.k8s.io/v1beta1 для зворотної сумісності. Щоб отримувати запити authentication.k8s.io/v1, API-сервер повинен бути запущений з параметром --authentication-token-webhook-version=v1.
{"apiVersion": "authentication.k8s.io/v1","kind": "TokenReview","spec": {# Непрозорий токен на прежʼявника носія, надісланий на API-сервер"token": "014fbff9a07c...",# Необовʼязковий список ідентифікаторів аудиторії для сервера, якому був представлений токен.# Автентифікатори токенів, що враховують аудиторію (наприклад, OIDC автентифікатори токенів)# повинні перевірити, що токен був призначений для принаймні однієї з аудиторій у цьому списку,# і повернути перетин цього списку та дійсних аудиторій для токена в статусі відповіді.# Це гарантує, що токен дійсний для автентифікації на сервері, якому він був представлений.# Якщо аудиторії не надані, токен повинен бути перевірений для автентифікації на API-сервері Kubernetes."audiences": ["https://myserver.example.com","https://myserver.internal.example.com"]}}
{"apiVersion": "authentication.k8s.io/v1beta1","kind": "TokenReview","spec": {# Непрозорий токен на предʼявника, надісланий на API-сервер"token": "014fbff9a07c...",# Необовʼязковий список ідентифікаторів аудиторії для сервера, якому був представлений токен.# Автентифікатори токенів, що враховують аудиторію (наприклад, OIDC автентифікатори токенів)# повинні перевірити, що токен був призначений для принаймні однієї з аудиторій у цьому списку,# і повернути перетин цього списку та дійсних аудиторій для токена в статусі відповіді.# Це гарантує, що токен дійсний для автентифікації на сервері, якому він був представлений.# Якщо аудиторії не надані, токен повинен бути перевірений для автентифікації на API-сервері Kubernetes."audiences": ["https://myserver.example.com","https://myserver.internal.example.com"]}}
Віддалений сервіс повинен заповнити поле status запиту, щоб вказати на успішність входу. Поле spec тіла відповіді ігнорується та може бути опущене. Віддалений сервіс повинен повернути відповідь, використовуючи ту ж версію API TokenReview, яку він отримав. Успішна перевірка маркера носія буде виглядати так:
{"apiVersion": "authentication.k8s.io/v1","kind": "TokenReview","status": {"authenticated": true,"user": {# Обовʼязково"username": "janedoe@example.com",# Необовʼязково"uid": "42",# Необовʼязкові членства у групах"groups": ["developers","qa"],# Необовʼязкова додаткова інформація, надана автентифікатором.# Це не повинно містити конфіденційних даних, оскільки це може бути записано в логах# або обʼєктах API та доступно для вебхуків допуску."extra": {"extrafield1": ["extravalue1","extravalue2"]}},# Необовʼязковий список, який можуть повернути автентифікатори токенів, що враховують аудиторію,# містить аудиторії зі списку `spec.audiences`, для яких токен був дійсним.# Якщо це опущено, токен вважається дійсним для автентифікації на API-сервері Kubernetes."audiences": ["https://myserver.example.com"]}}
{"apiVersion": "authentication.k8s.io/v1beta1","kind": "TokenReview","status": {"authenticated": true,"user": {# Обовʼязково"username": "janedoe@example.com",# Необовʼязково"uid": "42",# Необовʼязкові членства у групах"groups": ["developers","qa"],# Необовʼязкова додаткова інформація, надана автентифікатором.# Це не повинно містити конфіденційних даних, оскільки це може бути записано в логах# або обʼєктах API та доступно для вебхуків допуску."extra": {"extrafield1": ["extravalue1","extravalue2"]}},# Необовʼязковий список, який можуть повернути автентифікатори токенів, що враховують аудиторію,# містить аудиторії зі списку `spec.audiences`, для яких токен був дійсним.# Якщо це опущено, токен вважається дійсним для автентифікації на API-сервері Kubernetes."audiences": ["https://myserver.example.com"]}}
{"apiVersion": "authentication.k8s.io/v1","kind": "TokenReview","status": {"authenticated": false,# Необовʼязково включати деталі, чому автентифікація не вдалася.# Якщо помилка не вказана, API поверне загальне повідомлення Unauthorized.# Поле error ігнорується, коли authenticated=true."error": "Credentials are expired"}}
{"apiVersion": "authentication.k8s.io/v1beta1","kind": "TokenReview","status": {"authenticated": false,# Необовʼязково включати деталі, чому автентифікація не вдалася.# Якщо помилка не вказана, API поверне загальне повідомлення Unauthorized.# Поле error ігнорується, коли authenticated=true."error": "Credentials are expired"}}
Проксі автентифікації
API-сервер може бути налаштований для ідентифікації користувачів на основі значень заголовків запиту, таких як X-Remote-User. Цей механізм призначений для використання в комбінації з проксі-сервером автентифікації, який встановлює значення заголовка запиту.
--requestheader-username-headers Обовʼязково, нечутливий до регістру. Імена заголовків для перевірки, у порядку, для ідентифікації користувача. Перший заголовок, який містить значення, використовується як імʼя користувача.
--requestheader-group-headers Версія 1.6+. Необовʼязково, нечутливий до регістру. Пропонується використовувати "X-Remote-Group". Імена заголовків для перевірки, у порядку, для визначення груп користувача. Усі значення в усіх зазначених заголовках використовуються як імена груп.
--requestheader-extra-headers-prefix Версія 1.6+. Необовʼязково, нечутливий до регістру. Пропонується використовувати "X-Remote-Extra-". Префікси заголовків для перевірки додаткової інформації про користувача (зазвичай використовується налаштованим втулком авторизації). У всіх заголовків, які починаються з будь-якого з зазначених префіксів, префікси вилучаються. Решта імені заголовка перетворюється на нижній регістр і декодується у відповідності з RFC 3986, і стає додатковим ключем, а значення заголовка — додатковим значенням.
Для запобігання підробці заголовків, проксі-сервер автентифікації повинен представити дійсний клієнтський сертифікат на API-сервер для перевірки за допомогою вказаного CA перед тим, як заголовки запиту будуть перевірені. ПОПЕРЕДЖЕННЯ: не використовуйте CA, який використовується в іншому контексті, якщо ви не розумієте ризики та механізми захисту використання CA.
--requestheader-client-ca-file Обовʼязково. Файл з сертифікатами у форматі PEM. Дійсний клієнтський сертифікат повинен бути представлений і перевірений за допомогою сертифікатів у вказаному файлі перед перевіркою заголовків запиту для імен користувачів.
--requestheader-allowed-names Необовʼязково. Список значень Common Name (CN). Якщо встановлено, дійсний клієнтський сертифікат з CN з вказаного списку повинен бути представлений перед перевіркою заголовків запиту для імен користувачів. Якщо порожній, дозволений будь-який CN.
Анонімні запити
Коли увімкнено, запити, які не відхиляються іншими налаштованими методами автентифікації, розглядаються як анонімні запити та отримують імʼя користувача system:anonymous і групу system:unauthenticated.
Наприклад, на сервері з налаштованою автентифікацією за допомогою токенів та увімкненим анонімним доступом, запит із недійсним токеном автентифікації отримає помилку 401 Unauthorized. Запит без токена автентифікації буде розглядатися як анонімний запит.
У версіях 1.5.1-1.5.x анонімний доступ типово вимкнено і може бути увімкнено шляхом додавання опції --anonymous-auth=true до API-сервера.
У версіях 1.6+ анонімний доступ типово увімкнено, якщо використовується режим авторизації, відмінний від AlwaysAllow, і може бути вимкнено шляхом додавання опції --anonymous-auth=false до API-сервера. Починаючи з версії 1.6, авторизатори ABAC і RBAC вимагають явної авторизації користувача system:anonymous або групи system:unauthenticated, тому застарілі правила політики, які надають доступ користувачеві * або групі *, не включають анонімних користувачів.
Імперсонізація користувачів
Користувач може діяти від імені іншого користувача через заголовки імперсонізації. Це дозволяє вручну перевизначити інформацію про користувача, який виконує запит. Наприклад, адміністратор може використовувати цю функцію для налагодження політики авторизації, тимчасово імперсонуючи іншого користувача та перевіряючи, чи запит відхилено.
Запити з імперсонізацією спочатку автентифікуються як запити від імені запитувача, потім переключаються на імперсоновану інформацію про користувача.
Користувач робить API-запит зі своїми обліковими даними і заголовками імперсонізації.
API-сервер автентифікує користувача.
API-сервер переконується, що автентифіковані користувачі мають права імперсонізації.
Інформація про користувача замінюється значеннями імперсонізації.
Запит оцінюється, авторизація діє на основі імперсонованої інформації про користувача.
Для здійснення запиту на імперсонізацію можна використовувати такі заголовки HTTP:
Impersonate-User: Імʼя користувача, від імені якого потрібно діяти.
Impersonate-Group: Імʼя групи, від імені якої потрібно діяти. Може надаватися кілька разів для встановлення кількох груп. Опціонально. Потрібен Impersonate-User.
Impersonate-Extra-( extra name ): Динамічний заголовок для звʼязування додаткових полів з користувачем. Опціонально. Потрібен Impersonate-User. Для збереження послідовності ( extra name ) повинно бути малими літерами, а будь-які символи, які не є допустимими в HTTP-заголовках, МАЮТЬ бути у форматі utf8 та процентно-кодовані.
Impersonate-Uid: Унікальний ідентифікатор, який представляє імперсонованого користувача. Опціонально. Потрібен Impersonate-User. Kubernetes не накладає жодних вимог щодо формату цього рядка.
Примітка:
До версії 1.11.3 (та 1.10.7, 1.9.11), ( extra name ) міг містити лише символи, які були допустимими в HTTP-заголовках.
Примітка:
Impersonate-Uid доступний лише у версіях 1.22.0 і вище.
Приклад заголовків імперсонізації при імперсонуванні користувача з групами:
Для використання kubectl встановіть прапорець --as для налаштування заголовка Impersonate-User, встановіть прапорець --as-group для налаштування заголовка Impersonate-Group.
kubectl drain mynode
Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)
kubectl не може імперсонувати додаткові поля або UID.
Для імперсонізації користувача, групи, ідентифікатора користувача (UID) або додаткових полів, користувач, який виконує імперсонізацію, повинен мати можливість виконувати дію "impersonate" з типом атрибута, який імперсонується ("user", "group", "uid" і т.д.). Для кластерів, що використовують втулок авторизації RBAC, наступна роль ClusterRole охоплює правила, необхідні для налаштування заголовків імперсонізації користувачів і груп:
Для імперсонізації, додаткові поля та імперсоновані UID належать до групи apiGroup "authentication.k8s.io". Додаткові поля оцінюються як субресурси ресурсу "userextras". Щоб дозволити користувачеві використовувати заголовки імперсонізації для додаткового поля "scopes" та для UID, користувачеві слід надати таку роль:
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:scopes-and-uid-impersonatorrules:# Може встановлювати заголовок "Impersonate-Extra-scopes" та заголовок "Impersonate-Uid".- apiGroups:["authentication.k8s.io"]resources:["userextras/scopes","uids"]verbs:["impersonate"]
Значення заголовків імперсонізації також можна обмежити, обмеживши набір resourceNames, які ресурс може приймати.
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:limited-impersonatorrules:# Може імперсонувати користувача "jane.doe@example.com"- apiGroups:[""]resources:["users"]verbs:["impersonate"]resourceNames:["jane.doe@example.com"]# Може імперсонувати групи "developers" та "admins"- apiGroups:[""]resources:["groups"]verbs:["impersonate"]resourceNames:["developers","admins"]# Може імперсонувати додаткове поле "scopes" зі значеннями "view" і "development"- apiGroups:["authentication.k8s.io"]resources:["userextras/scopes"]verbs:["impersonate"]resourceNames:["view","development"]# Може імперсонувати UID "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"- apiGroups:["authentication.k8s.io"]resources:["uids"]verbs:["impersonate"]resourceNames:["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"]
Примітка:
Імперсонізація користувача або групи дозволяє вам виконувати будь-які дії, якби ви були цим користувачем або групою; з цієї причини імперсонізація не є обмеженою областю.
Якщо ви хочете дозволити імперсонізацію за допомогою Kubernetes RBAC, це вимагає використання ClusterRole та ClusterRoleBinding, а не Role та RoleBinding.
Втулки облікових даних client-go
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.22 [stable]
k8s.io/client-go та інструменти, які використовують його, такі як kubectl та kubelet, можуть виконувати зовнішню команду для отримання облікових даних користувача.
Ця функція призначена для клієнтських інтеграцій з протоколами автентифікації, які не підтримуються на рівні k8s.io/client-go (LDAP, Kerberos, OAuth2, SAML та ін.). Вутулок реалізує логіку, специфічну для протоколу, а потім повертає непрозорі облікові дані для використання. Майже всі випадки використання втулків автентифікації потребують наявності компоненту на стороні сервера з підтримкою автентифікації токенів webhook, щоб інтерпретувати формат облікових даних, який генерується клієнтським втулком.
Примітка:
У попередніх версіях kubectl вбудовано підтримувалися автентифікація в AKS та GKE, але це більше не актуально.
Приклад використання
У гіпотетичному сценарії використання організація запускає зовнішню службу, яка обмінює облікові дані LDAP на підписані токени, специфічні для користувача. Служба також може відповідати на запити автентифікатора токенів webhook, щоб перевірити токени. Користувачам буде потрібно встановити втулок автентифікації на своїй робочій станції.
Для автентифікації в API:
Користувач видає команду kubectl.
Вутулок облікових даних запитує користувача облікові дані LDAP, обмінює облікові дані зовнішньою службою на токен.
Вутулок облікових даних повертає токен client-go, який використовує його як токен власника на сервері API.
apiVersion:v1kind:Configusers:- name:my-useruser:exec:# Команда для виконання. Обовʼязково.command:"example-client-go-exec-plugin"# Версія API, яку слід використовувати при декодуванні ресурсу ExecCredentials. Обовʼязково.## Версія API, що повертається втулком, ПОВИННА відповідати версії, вказаній тут.## Щоб інтегруватися з інструментами, які підтримують кілька версій (наприклад, client.authentication.k8s.io/v1beta1),# встановіть змінну середовища, передайте аргумент інструменту, що вказує, яку версію очікує втулка виконання,# або прочитайте версію з обʼєкта ExecCredential у змінній середовища KUBERNETES_EXEC_INFO.apiVersion:"client.authentication.k8s.io/v1"# Змінні середовища, що встановлюються під час виконання втулку. Необовʼязково.env:- name:"FOO"value:"bar"# Аргументи, які передаються під час виконання втулку. Необовʼязково.args:- "arg1"- "arg2"# Текст, який показуєтсья користувачу, коли виконуваний файл не знайдено. Необовʼязково.installHint:| example-client-go-exec-plugin потрібно для автентифікації
в поточному кластері. Його можна встановити:
На macOS: brew install example-client-go-exec-plugin
На Ubuntu: apt-get install example-client-go-exec-plugin
На Fedora: dnf install example-client-go-exec-plugin
...# Чи надавати інформацію про кластер, яка може містити# дуже великі дані сертифікату CA, цьому втулка виконання як частину KUBERNETES_EXEC_INFO# змінної середовища.provideClusterInfo:true# Угода між втулком виконання та стандартним введенням/виведенням. Якщо# угода не може бути виконана, цей втулок виконання не буде запущено, та буде# повернено помилку. Допустимі значення: "Never" (цей втулок виконання ніколи не використовує стандартний ввід),# "IfAvailable" (цей втулок виконання хоче використовувати стандартний ввід, якщо він доступний),# або "Always" (цей втулок виконання вимагає стандартний ввід для роботи). Обовʼязково.interactiveMode:Neverclusters:- name:my-clustercluster:server:"https://172.17.4.100:6443"certificate-authority:"/etc/kubernetes/ca.pem"extensions:- name:client.authentication.k8s.io/exec# зарезервоване імʼя розширення для кожної конфігурації виконання кластераextension:arbitrary:configthis:може бути надано через змінну середовища KUBERNETES_EXEC_INFO при встановленні provideClusterInfoyou:["можете","покласти","будь-що","тут"]contexts:- name:my-clustercontext:cluster:my-clusteruser:my-usercurrent-context:my-cluster
apiVersion:v1kind:Configusers:- name:my-useruser:exec:# Команда для виконання. Обовʼязково.command:"example-client-go-exec-plugin"# Версія API, яку слід використовувати при декодуванні ресурсу ExecCredentials. Обовʼязково.## Версія API, повернута втулком, ПОВИННА відповідати версії, вказаній тут.## Щоб інтегруватися з інструментами, які підтримують кілька версій (наприклад, client.authentication.k8s.io/v1),# встановіть змінну середовища, перед ```yamlapiVersion:"client.authentication.k8s.io/v1beta1"# Змінні середовища, що встановлюються під час виконання втулку. Необовʼязково.env:- name:"FOO"value:"bar"# Аргументи, які передаються під час виконання втулку. Необовʼязково.args:- "arg1"- "arg2"# Текст, який показується користувачу, коли виконуваний файл не знайдено. Необовʼязково.installHint:| example-client-go-exec-plugin потрібно для автентифікації
в поточному кластері. Його можна встановити:
На macOS: brew install example-client-go-exec-plugin
На Ubuntu: apt-get install example-client-go-exec-plugin
На Fedora: dnf install example-client-go-exec-plugin
...# Чи надавати інформацію про кластер, яка може містити# дуже великі дані сертифікату CA, цьому втулку виконання як частину KUBERNETES_EXEC_INFO# змінної середовища.provideClusterInfo:true# Угода між втулком виконання та стандартним введенням/виведенням. Якщо# угода не може бути виконана, цей втулок виконання не буде запущено, а буде# повернено помилку. Допустимі значення: "Never" (цей втулок виконання ніколи не використовує стандартний ввід),# "IfAvailable" (цей втулок виконання хоче використовувати стандартний ввід, якщо він доступний),# або "Always" (цей втулок виконання вимагає стандартний ввід для роботи). Необовʼязково.# За замовчуванням - "IfAvailable".interactiveMode:Neverclusters:- name:my-clustercluster:server:"https://172.17.4.100:6443"certificate-authority:"/etc/kubernetes/ca.pem"extensions:- name:client.authentication.k8s.io/exec# зарезервоване імʼя розширення для кожної конфігурації виконання кластераextension:arbitrary:configthis:може бути надано через змінну середовища KUBERNETES_EXEC_INFO при встановленні provideClusterInfoyou:["можете","покласти","будь-що","тут"]contexts:- name:my-clustercontext:cluster:my-clusteruser:my-usercurrent-context:my-cluster
Відносні шляхи до команд інтерпретуються відносно теки файлу конфігурації. Якщо KUBECONFIG встановлено на /home/jane/kubeconfig, а команда виконання — ./bin/example-client-go-exec-plugin, то виконується бінарний файл /home/jane/bin/example-client-go-exec-plugin.
- name:my-useruser:exec:# Шлях відносно теки kubeconfigcommand:"./bin/example-client-go-exec-plugin"apiVersion:"client.authentication.k8s.io/v1"interactiveMode:Never
Формати вводу та виводу
Виконана команда виводить обʼєкт ExecCredential у stdout. k8s.io/client-go автентифікується в Kubernetes API, використовуючи отримані облікові дані в status. Виконана команда отримує обʼєкт ExecCredential на вхід через змінну середовища KUBERNETES_EXEC_INFO. Цей вхід містить корисну інформацію, таку як очікувана версія API поверненого обʼєкта ExecCredential та чи може втулок використовувати stdin для взаємодії з користувачем.
Під час запуску з інтерактивної сесії (тобто термінал), stdin може бути наданий прямо втулку. Втулки повинні використовувати поле spec.interactive вхідного обʼєкта ExecCredential зі змінної середовища KUBERNETES_EXEC_INFO для визначення, чи був наданий stdin. Вимоги втулка до stdin (тобто чи stdin є необовʼязковим, строго обовʼязковим або ніколи не використовується для успішного запуску втулка) вказується за допомогою поля user.exec.interactiveMode у kubeconfig (див. таблицю нижче для дійсних значень). Поле user.exec.interactiveMode є необовʼязковим у client.authentication.k8s.io/v1beta1 і обовʼязковим у client.authentication.k8s.io/v1.
Значення interactiveMode
Значення interactiveMode
Значення
Never
Цей втулок виконання ніколи не потребує використання стандартного вводу, і тому втулок виконання буде запущений незалежно від того, чи доступний стандартний ввід для введення користувача.
IfAvailable
Цей втулок виконання хоче використовувати стандартний ввід, якщо він доступний, але може працювати, якщо стандартний ввід недоступний. Тому втулок виконання буде запущений незалежно від наявності введення з стандартного вводу. Якщо стандартний ввід доступний для введення користувача, він буде наданий цьому втулку виконання.
Always
Цей втулок виконання потребує стандартний ввід для роботи, і тому втулок виконання буде запущений лише тоді, коли стандартний ввід доступний для введення користувача. Якщо стандартний ввід недоступний для введення користувача, втулок виконання не буде запущений, і виконавець втулку поверне помилку.
Для використання облікових даних токена власника, втулок повертає токен у статусі ExecCredential
Альтративно, можна повернути PEM-кодований сертифікат клієнта та ключ для використання TLS-автентифікації клієнта. Якщо втулок повертає різний сертифікат та ключ при наступному виклику, k8s.io/client-go закриє існуючі зʼєднання з сервером, щоб змусити новий TLS-обмін.
Якщо вказано, що clientKeyData та clientCertificateData повинні бути присутніми.
clientCertificateData може містити додаткові проміжні сертифікати для відправки на сервер.
Додатково відповідь може включати термін дії облікового запису, форматований як
RFC 3339 мітка часу.
Наявність або відсутність терміну дії має такий вплив:
Якщо термін дії включений, токен власника та TLS-облікові дані кешуються до
моменту закінчення строку дії, або якщо сервер відповідає з кодом стану HTTP 401,
або при завершенні процесу.
Якщо термін дії відсутній, токен власника та TLS-облікові дані кешуються до
моменту, коли сервер відповідає з кодом стану HTTP 401 або до моменту завершення процесу.
Щоб дозволити втулку виконання отримувати інформацію, що специфічна для кластера, встановіть provideClusterInfo у поле user.exec в kubeconfig. Втулок потім отримає цю інформацію, специфічну для кластера, у змінній середовища KUBERNETES_EXEC_INFO. Інформацію з цієї змінної середовища можна використовувати для виконання логіки отримання облікових даних, специфічних для кластера. Наступний маніфест ExecCredential описує зразок інформації для кластера.
{
"apiVersion": "client.authentication.k8s.io/v1",
"kind": "ExecCredential",
"spec": {
"cluster": {
"server": "https://172.17.4.100:6443",
"certificate-authority-data": "LS0t...",
"config": {
"arbitrary": "config",
"this": "can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo",
"you": ["can", "put", "anything here"]
},
"interactive": true }
}
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
"kind": "ExecCredential",
"spec": {
"cluster": {
"server": "https://172.17.4.100:6443",
"certificate-authority-data": "LS0t...",
"config": {
"arbitrary": "config",
"this": "can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo",
"you": ["can", "put", "anything", "here"]
}
},
"interactive": true }
}
Доступ API до інформації про автентифікацію для клієнта
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.28 [stable]
Якщо ваш кластер має включений API, ви можете використовувати API SelfSubjectReview, щоб дізнатися, як ваш кластер Kubernetes показує вашу інформацію про автентифікацію, щоб ідентифікувати вас як клієнта. Це працює незалежно від того, чи автентифікуєтеся ви як користувач (зазвичай представляючи реальну особу), чи як обліковий запис ServiceAccount.
Обʼєкти SelfSubjectReview не мають полів, які конфігуруються. При отриманні запиту API-сервер Kubernetes заповнює статус атрибутами користувача та повертає його користувачеві.
Приклад запиту (тіло буде SelfSubjectReview):
POST /apis/authentication.k8s.io/v1/selfsubjectreviews
Для зручності доступний також запит kubectl auth whoami. Виконання цієї команди призведе до
наступного виводу (але різні атрибути користувача будуть показані):
Простий приклад виводу
ATTRIBUTE VALUE
Username jane.doe
Groups [system:authenticated]
Складний приклад, який включає додаткові атрибути
ATTRIBUTE VALUE
Username jane.doe
UID b79dbf30-0c6a-11ed-861d-0242ac120002
Groups [students teachers system:authenticated]
Extra: skills [reading learning]
Extra: subjects [math sports]
За допомогою прапорця виводу також можна надрукувати JSON- або YAML-представлення результату:
API-сервер Kubernetes заповнює userInfo після застосування всіх механізмів автентифікації,
включаючи імперсонізаацію. Якщо ви, або автентифікаційний проксі, робите SelfSubjectReview за допомогою імперсонізації, ви побачите деталі та властивості користувача, який був імперсонований.
Стандартно всі автентифіковані користувачі можуть створювати обʼєкти SelfSubjectReview, коли функція APISelfSubjectReview включена. Це дозволено за допомогою кластерної ролі system:basic-user.
Примітка:
Ви можете робити запити SelfSubjectReview тільки якщо:
включено функціоналAPISelfSubjectReview для вашого кластера (не потрібно для Kubernetes 1.30, але більш старі версії Kubernetes можуть не надавати цю функцію або за стандартно вимикати її)
(якщо ви запускаєте версію Kubernetes старішу за v1.28) API-сервер для вашого кластера має увімкнений API-групи authentication.k8s.io/v1alpha1 або authentication.k8s.io/v1beta1.
3.2 - Автентифікація за допомогою Bootstrap-токенів
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.18 [stable]
Bootstrap-токени — це простий токен на предʼявника, який призначений для використання під час створення нових кластерів або приєднання нових вузлів до наявного кластера. Він був створений для підтримки kubeadm, але може використовуватися в інших контекстах для користувачів, які бажають створювати кластери без kubeadm. Також він призначений для роботи, через політику RBAC, з системою Kubelet TLS Bootstrapping.
Огляд Bootstrap-токенів
Bootstrap-токени визначені як певний тип secretʼів (bootstrap.kubernetes.io/token), що знаходяться в просторі імен kube-system. Ці secret читаються Bootstrap Authenticator з API Server. Протерміновані токени видаляються контролером TokenCleaner у Controller Manager. Токени також використовуються для створення підпису для конкретного ConfigMap, який використовується у процесі "виявлення" через контролер BootstrapSigner.
Формат токена
Bootstrap-токени мають форму abcdef.0123456789abcdef. Більш формально, вони повинні відповідати регулярному виразу [a-z0-9]{6}\.[a-z0-9]{16}.
Перша частина токена — це "ID токена" і вважається публічною інформацією. Вона використовується, коли потрібно посилатися на токен без розкриття секретної частини, яка використовується для автентифікації. Друга частина — це "Секрет токена" і нею треба ділитися тільки з довіреними сторонами.
Увімкнення автентифікації за допомогою Bootstrap-токенів
Автентифікатор Bootstrap Token можна увімкнути за допомогою наступного прапорця на API-сервері:
--enable-bootstrap-token-auth
Після увімкнення, токени для завантаження можуть використовуватися як облікові дані токена на предʼявника для автентифікації запитів до API-сервера.
Authorization: Bearer 07401b.f395accd246ae52d
Токени автентифікуються як імʼя користувача system:bootstrap:<token id> і є членами групи system:bootstrappers. Додаткові групи можуть бути вказані в секреті токена.
Протерміновані токени можуть бути автоматично видалені шляхом увімкнення контролера tokencleaner у Controller Manager.
--controllers=*,tokencleaner
Формат Secretʼу Bootstrap-токена
Кожен дійсний токен підтримується секретом у просторі імен kube-system. Повний документ проєктування можна знайти тут.
Ось як виглядає цей Secret.
apiVersion:v1kind:Secretmetadata:# Назва МАЄ бути у формі "bootstrap-token-<token id>"name:bootstrap-token-07401bnamespace:kube-system# Тип МАЄ бути 'bootstrap.kubernetes.io/token'type:bootstrap.kubernetes.io/tokenstringData:# Опис, зрозумілий людині. Необовʼязково.description:"Стандартний bootstrap-токен, згенерований 'kubeadm init'."# ID та секрет токена. Обовʼязково.token-id:07401btoken-secret:f395accd246ae52d# Термін дії. Необовʼязково.expiration:2017-03-10T03:22:11Z# Дозволені використання.usage-bootstrap-authentication:"true"usage-bootstrap-signing:"true"# Додаткові групи для автентифікації токена. Мають починатися з "system:bootstrappers:"auth-extra-groups:system:bootstrappers:worker,system:bootstrappers:ingress
Тип секрету має бути bootstrap.kubernetes.io/token, а назва має бути bootstrap-token-<token id>. Він також повинен знаходитися в просторі імен kube-system.
Члени usage-bootstrap-* вказують, для чого цей секрет призначений. Значення має бути встановлено в true, щоб увімкнути відповідне використання.
usage-bootstrap-authentication вказує, що токен може використовуватися для автентифікації до API-сервера як токен-носій.
usage-bootstrap-signing вказує, що токен може використовуватися для підпису ConfigMap cluster-info, як описано нижче.
Поле expiration контролює термін дії токена. Протерміновані токени відхиляються при спробі автентифікації та ігноруються під час підпису ConfigMap. Значення терміну дії кодується як абсолютний UTC-час за стандартом RFC3339. Увімкніть контролер tokencleaner, щоб автоматично видаляти протерміновані токени.
Управління токенами за допомогою kubeadm
Ви можете використовувати інструмент kubeadm для управління токенами на запущеному кластері. Деталі дивіться в документації kubeadm token.
Підпис ConfigMap
Окрім автентифікації, токени можуть використовуватися для підпису ConfigMap. Це використовується на ранніх етапах процесу завантаження кластера до того, як клієнт довіряє API-серверу. Підписаний ConfigMap може бути автентифікований спільним токеном.
Увімкніть підпис ConfigMap, увімкнувши контролер bootstrapsigner у Controller Manager.
--controllers=*,bootstrapsigner
ConfigMap, який підписується, це cluster-info у просторі імен kube-public. Типовий процес полягає в тому, що клієнт читає цей ConfigMap без автентифікації та ігноруючи помилки TLS. Потім він перевіряє коректність ConfigMap, переглядаючи підпис, вбудований у ConfigMap.
Елемент kubeconfig у ConfigMap є конфігураційним файлом, який містить лише інформацію про кластер. Ключовим моментом, що передається, є certificate-authority-data. Це може бути розширено в майбутньому.
Підпис є підписом JWS, що використовує "відокремлений" режим. Щоб перевірити підпис, користувач має закодувати вміст kubeconfig відповідно до правил JWS (закодовано base64, відкидаючи будь-які кінцеві =). Цей закодований вміст потім використовується для формування повного JWS шляхом вставки його між 2 крапками. Ви можете перевірити JWS, використовуючи схему HS256 (HMAC-SHA256) з повним токеном (наприклад, 07401b.f395accd246ae52d) як спільний секрет. Користувачі повинні перевірити, що використовується HS256.
Попередження:
Будь-яка сторона з токеном завантаження може створити дійсний підпис для цього токена. Коли використовується підпис ConfigMap, не рекомендується ділитися одним токеном з багатьма клієнтами, оскільки скомпрометований клієнт може потенційно провести атаку "людина посередині" на іншого клієнта, який покладається на підпис для завантаження довіри TLS.
Деталі механізмів авторизації Kubernetes і підтримувані режими авторизації.
Авторизація в Kubernetes відбувається після автентифікації. Зазвичай клієнт, що робить запит, має бути автентифікований (увійти в систему), перш ніж його запит може бути дозволений; однак, Kubernetes також дозволяє анонімні запити за деяких обставин.
Авторизація запитів до API в Kubernetes відбувається всередині API-сервера. API-сервер оцінює всі атрибути запиту щодо всіх політик, потенційно також звертаючись до зовнішніх сервісів, і потім дозволяє або відхиляє запит.
Усі частини запиту до API повинні бути дозволені деяким механізмом авторизації, щоб він міг продовжити виконання. Іншими словами: стандартно доступ заборонений.
Примітка:
Контроль доступу і політики, що залежать від конкретних полів конкретних видів обʼєктів, обробляються контролерами допуску.
Контроль допуску в Kubernetes відбувається після завершення авторизації (і, отже, тільки коли рішення про авторизацію було дозволити запит).
Коли налаштовано кілька модулів авторизації, кожен перевіряється по черзі. Якщо будь-який авторизатор схвалює або відхиляє запит, це рішення негайно повертається і жоден інший авторизатор не перевіряється. Якщо всі модулі не мають думки щодо запиту, то запит відхиляється. Загальний вердикт "відхилено" означає, що API-сервер відхиляє запит і відповідає зі статусом HTTP 403 (Forbidden).
Атрибути запиту, що використовуються для авторизації
Kubernetes розглядає тільки наступні атрибути запиту до API:
user — Рядок user, наданий під час автентифікації.
group — Список імен груп, до яких належить автентифікований користувач.
extra — Map довільних рядкових ключів з рядковими значеннями, надана шаром автентифікації.
API — Вказує, чи є запит запитом на ресурс API.
Request path — Шлях до різних нересурсних точок доступу, таких як /api або /healthz.
API request verb — Дієслова API, такі як get, list, create, update, patch, watch, delete і deletecollection, використовуються для запитів до ресурсів. Щоб визначити дієслово запиту для точки доступу API ресурсу, дивіться дієслова запитів та авторизація.
HTTP request verb — Методи HTTP в нижньому регістрі, такі як get, post, put і delete, використовуються для нересурсних запитів.
Resource — Ідентифікатор або імʼя ресурсу, до якого здійснюється доступ (тільки для запитів до ресурсів). Для запитів до ресурсів, що використовують дієслова get, update, patch і delete, ви повинні надати імʼя ресурсу.
Subresource — Субесурс, до якого здійснюється доступ (тільки для запитів до ресурсів).
Namespace — Простір імен обʼєкта, до якого здійснюється доступ (тільки для запитів до ресурсів у просторі імен).
API group — Група API, до якої здійснюється доступ (тільки для запитів до ресурсів). Порожній рядок позначає основнугрупу API.
Дієслова запиту та авторизація
Нересурсні запити
Запити до точок доступу, відмінних від /api/v1/... або /apis/<group>/<version>/..., вважаються нересурсними запитами та використовують метод HTTP як дієслово в нижньому регістрі. Наприклад, виконання запиту GET за допомогою HTTP до точок доступу, таких як /api або /healthz, буде використовувати get як дієслово.
Ресурсні запити
Щоб визначити дієслово запиту для точки доступу API ресурсу, Kubernetes показує використаний HTTP метод і розглядає, чи діє запит на індивідуальний ресурс чи на колекцію ресурсів:
HTTP метод
дієслово запиту
POST
create
GET, HEAD
get (для індивідуальних ресурсів), list (для колекцій, включаючи повний вміст обʼєктів), watch (для спостереження за індивідуальним ресурсом або колекцією ресурсів)
PUT
update
PATCH
patch
DELETE
delete (для індивідуальних ресурсів), deletecollection (для колекцій)
Увага:
Дієслова get, list та watch можуть повертати повні деталі ресурсу. В плані доступу до повернених даних вони є еквівалентними. Наприклад, list для secrets розкриє атрибути data будь-яких повернених ресурсів.
Іноді Kubernetes перевіряє авторизацію для додаткових дозволів, використовуючи спеціалізовані дієслова. Наприклад:
Дієслова bind та escalate для ресурсів roles та clusterroles у групі API rbac.authorization.k8s.io.
Контекст авторизації
Kubernetes очікує атрибути, які є загальними для запитів до REST API. Це означає, що авторизація в Kubernetes працює з наявними системами контролю доступу на рівні організації або
хмарного провайдера, які можуть обробляти інші API крім Kubernetes API.
Режими авторизації
API-сервер Kubernetes може авторизувати запит, використовуючи один з декількох режимів авторизації:
AlwaysAllow
Цей режим дозволяє всі запити, що несе ризики для безпеки. Використовуйте цей режим авторизації тільки якщо вам не потрібна авторизація для ваших запитів до API (наприклад, для тестування).
AlwaysDeny
Цей режим блокує всі запити. Використовуйте цей режим авторизації тільки для тестування.
Режим ABAC в Kubernetes визначає парадигму управління доступом, згідно з якою права доступу надаються користувачам за допомогою політик, які обʼєднують атрибути разом. Політики можуть використовувати будь-який тип атрибутів (атрибути користувача, атрибути ресурсу, обʼєкта, середовища тощо).
Kubernetes RBAC — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів в організації. У цьому контексті доступ — це можливість окремого користувача виконувати певне завдання, наприклад, переглядати, створювати або змінювати файл. В цьому режимі Kubernetes використовує групу API rbac.authorization.k8s.io для прийняття рішень щодо авторизації, що дозволяє вам динамічно налаштовувати політики дозволів через API Kubernetes.
Node
Спеціальний режим авторизації, який надає дозволи для kubeletʼів на основі запланованих до запуску Podʼів. Щоб дізнатися більше про режим авторизації вузла, див. Авторизація вузла.
Webhook
Kubernetes режим webhook для авторизації робить синхронний HTTP-виклик, блокуючи запит до тих пір, поки віддалений HTTP-сервіс не відповість на нього. Ви можете написати власне програмне забезпечення для обробки виклику або використовувати рішення з екосистеми.
Ви повинні вибрати один з двох підходів до конфігурації: задати обидва шляхи --authorization-config і налаштувати вебхук авторизації за допомогою аргументів командного рядка --authorization-mode та --authorization-webhook-* не допускається. Якщо ви спробуєте це зробити, API сервер повідомить про помилку під час запуску та одразу завершить роботу.
Конфігурація режиму авторизації через командний рядок
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.8 [stable]
Ви можете використовувати наступні режими:
--authorization-mode=ABAC (режим контролю доступу на основі атрибутів)
--authorization-mode=RBAC (режим контролю доступу на основі ролей)
Ви можете вибрати більше одного режиму авторизації; наприклад: --authorization-mode=Node,Webhook
Kubernetes перевіряє модулі авторизації на основі порядку, який ви вказуєте в командному рядку API сервера, тому раніше зазначений модуль має вищий пріоритет для дозволу або відмови в запиті.
Ви вказуєте шлях до конфігурації авторизації за допомогою аргументу командного рядка --authorization-config.
Якщо ви хочете використовувати параметри командного рядка замість конфігураційного файлу, це також є дійсним і підтримуваним підходом. Деякі можливості авторизації (наприклад: кілька вебхуків, політика відмови вебхука та правила попередньої фільтрації) доступні тільки при використанні конфігураційного файлу авторизації.
Приклад конфігурації
---## НЕ ВИКОРИСТОВУЙТЕ КОНФІГУРАЦІЮ ТАК, ЯК ВОНА Є. ЦЕ ПРИКЛАД.#apiVersion:apiserver.config.k8s.io/v1beta1kind:AuthorizationConfigurationauthorizers:* type:Webhook# Назва, що використовується для опису авторизатора# Це явно використовується в механізмі моніторингу для метрик# Примітка:# - Перевірка цього поля схожа на перевірку міток K8s на сьогодні.# Обовʼязково, немає стандартного значенняname:webhookwebhook:# Тривалість кешування відповідей 'authorized' від вебхука# авторизатора.# Те саме, що і встановлення прапорця `--authorization-webhook-cache-authorized-ttl`.# Стандартно: 5m0sauthorizedTTL:30s# Тривалість кешування відповідей 'unauthorized' від вебхука# авторизатора.# Те саме, що і встановлення прапорця `--authorization-webhook-cache-unauthorized-ttl`.# Стандартно: 30 сunauthorizedTTL:30s# Тайм-аут для запиту вебхука# Максимально допустимий: 30 с# Обовʼязково, немає стандартного значенняtimeout:3s# Версія API для SubjectAccessReview в authorization.k8s.io, яка# надсилається до вебхука та очікується від нього.# Те саме, що і встановлення прапорця `--authorization-webhook-version`.# Обовʼязково, немає стандартного значення# Допустимі значення: v1beta1, v1subjectAccessReviewVersion:v1# MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview# за якою оцінюються вирази CEL# Допустимі значення: v1# Обовʼязково, немає стандартного значенняmatchConditionSubjectAccessReviewVersion:v1# Керує рішенням авторизації, коли запит вебхука не вдалося# виконати або отримано некоректну відповідь або помилки під час оцінки# виразів matchConditions.# Допустимі значення:# - NoOpinion: продовжувати до наступних авторизаторів, щоб перевірити, чи дозволяє один з них запит# - Deny: відхиляти запит без консультації з наступними авторизаторами# Обовʼязково, немає стандартного значенняfailurePolicy:DenyconnectionInfo:# Керує тим, як вебхук повинен спілкуватися з сервером.# Допустимі значення:# - KubeConfig: використовуйте файл, вказаний у kubeConfigFile для пошуку сервера.# - InClusterConfig: використовуйте конфігурацію внутрішнього кластера для виклику API SubjectAccessReview,# що розміщується kube-apiserver. Цей режим не дозволяється для kube-apiserver.type:KubeConfig# Шлях до файлу KubeConfig для інформації про підключення# Обовʼязково, якщо connectionInfo.Type = KubeConfigkubeConfigFile:/kube-system-authz-webhook.yaml# matchConditions - це список умов, які повинні бути виконані для того, щоб запит було відправлено на цей# вебхук. Порожній список matchConditions підходить для всіх запитів.# Є максимально допустимі 64 умови відповідності.## Логіка точного порівняння така (в порядку):# 1. Якщо принаймні одна matchCondition оцінюється як FALSE, тоді вебхук пропускається.# 2. Якщо ВСІ matchConditions оцінюються як TRUE, тоді вебхук викликається.# 3. Якщо принаймні одна matchCondition оцінюється як помилка (але ні одна не є FALSE):# - Якщо failurePolicy=Deny, тоді вебхук відхиляє запит.# - Якщо failurePolicy=NoOpinion, тоді помилка ігнорується, а вебхук пропускається.matchConditions:# expression - це вираз CEL, який оцінюється для кожного запиту. Повертає булеве значення.# CEL вираз має доступ до вмісту SubjectAccessReview у версії v1.# Якщо версія у SubjectAccessReview в запиті змінної є v1beta1, # вміст буде конвертовано у v1 перед оцінкою виразу CEL.## Документація CEL: https://kubernetes.io/docs/reference/using-api/cel/## лише надсилати запити ресурсівв до вебхука* expression:has(request.resourceAttributes)# лише перехоплювати запити до kube-system* expression:request.resourceAttributes.namespace == 'kube-system'# не перехоплювати запити від облікових записів служб kube-system* expression:!('system:serviceaccounts:kube-system' in request.user.groups)* type:Nodename:node* type:RBACname:rbac* type:Webhookname:in-cluster-authorizerwebhook:authorizedTTL:5хвunauthorizedTTL:30сtimeout:3сsubjectAccessReviewVersion:v1failurePolicy:NoOpinionconnectionInfo:type:InClusterConfig
Під час налаштування ланцюжка авторизації за допомогою файлу конфігурації переконайтеся, що всі вузли панелі управління мають однаковий вміст файлу. Зверніть увагу на конфігурацію API сервера при оновленні / зниженні версії вашого кластера. Наприклад, якщо ви оновлюєтеся з Kubernetes 1.29 до Kubernetes 1.30, вам потрібно переконатися, що файл конфігурації має формат, який розуміє Kubernetes 1.30, перш ніж ви оновите кластер. Якщо ви знижуєте версію до 1.29, вам потрібно відповідно налаштувати конфігурацію.
Конфігурація авторизації та перезавантаження
Kubernetes перезавантажує файл конфігурації авторизації, коли API сервер виявляє зміну у файлі, а також за 60-секундним графіком, якщо події змін не спостерігаються.
Примітка:
Ви повинні забезпечити, щоб всі типи авторизаторів, крім вебхука, залишалися незмінними у файлі під час перезавантаження.
Перезавантаження не повинно додавати або видаляти авторизаторів вузла або RBAC (їх можна перевпорядкувати, але не можна додавати або видаляти).
Підвищення привілеїв через створення або редагування робочих навантажень
Користувачі, які можуть створювати/редагувати Podʼи в просторі імен, або безпосередньо, або через обʼєкт, що дозволяє опосередковане управління робочими навантаженнями, можуть мати можливість підвищити свої привілеї в цьому просторі імен. Потенційні шляхи до підвищення привілеїв включають розширення API Kubernetes та повʼязані з ними контролери.
Увага:
Як адміністратор кластера, будьте обережні, надаючи доступ до створення або редагування робочих навантажень. Деякі деталі того, як вони можуть бути використані не за призначенням, задокументовані в шляхах підвищення привілеїв.
Шляхи підвищення привілеїв
Існують різні способи, за якими зловмисник або ненадійний користувач може отримати додаткові привілеї в межах простору імен, якщо ви дозволяєте їм запускати довільні Podʼи в цьому просторі імен:
Монтування довільних Secretʼів в цьому просторі імен
Може бути використано для доступу до конфіденційної інформації, призначеної для інших робочих навантажень
Може бути використано для отримання токена службового облікового запису більш привілейованого ServiceAccount
Використання довільних службових облікових записів в цьому просторі імен
Може виконувати дії Kubernetes API як інше робоче навантаження (імперсонізація)
Може виконувати будь-які привілейовані дії, які має цей ServiceAccount
Монтування або використання ConfigMaps, призначених для інших робочих навантажень в цьому просторі імен
Може бути використано для отримання інформації, призначеної для інших робочих навантажень, таких як імена хостів баз даних.
Монтування томів, призначених для інших робочих навантажень в цьому просторі імен
Може бути використано для отримання інформації, призначеної для інших робочих навантажень, та її зміни.
Увага:
Як системному адміністратору, вам слід бути обережними при впровадженні власних визначень ресурсів, що дозволяють користувачам вносити зміни у вищезазначених областях. Це може відкрити шляхи до підвищення привілеїв. Розгляньте наслідки цього виду змін при виборі контролю за авторизацією.
Перевірка доступу до API
kubectl надає підкоманду auth can-i для швидкого запиту до рівня авторизації API. Команда використовує API SelfSubjectAccessReview, щоб визначити, чи може поточний користувач виконати
вказану дію, і працює незалежно від режиму авторизації, який використовується.
kubectl auth can-i create deployments --namespace dev
SelfSubjectAccessReview є частиною групи API authorization.k8s.io, яка викладає авторизацію сервера API для зовнішніх служб. Інші ресурси у цій групі включають:
SubjectAccessReview
Перегляд доступу для будь-якого користувача, не лише поточного. Корисно для делегування рішень про авторизацію серверу API. Наприклад, kubelet та API розширень сервери використовують це для визначення доступу користувача до своїх власних API.
LocalSubjectAccessReview
Подібно до SubjectAccessReview, але обмежено для конкретного простору імен.
SelfSubjectRulesReview
Перегляд, який повертає набір дій, які користувач може виконати в межах простору імен. Корисно для користувачів для швидкого узагальнення їх власного доступу, або для інтерфейсів користувача для приховування/відображення дій.
Ці API можна опитати, створивши звичайні ресурси Kubernetes, де поле відповіді status
поверненого обʼєкта є результатом запиту. Наприклад:
Контроль доступу на основі ролей (RBAC) — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів у вашій організації.
RBAC авторизація використовує групу API rbac.authorization.k8s.ioгрупа API для прийняття рішень щодо авторизації, дозволяючи вам динамічно налаштовувати політики через Kubernetes API.
Щоб увімкнути RBAC, запустіть API сервер з прапорцем --authorization-mode, встановленим на список, розділений комами, що включає RBAC; наприклад:
RBAC API визначає чотири типи обʼєктів Kubernetes: Role, ClusterRole, RoleBinding та ClusterRoleBinding. Ви можете описувати або змінювати обʼєкти RBAC за допомогою таких інструментів, як kubectl, так само як і будь-який інший обʼєкт Kubernetes.
Увага:
Ці обʼєкти за своєю конструкцією накладають обмеження на доступ. Якщо ви вносите зміни до кластера під час навчання, перегляньте розділ запобігання підвищенню привілеїв та початкове налаштування, щоб зрозуміти, як ці обмеження можуть завадити вам вносити деякі зміни.
Role та ClusterRole
RBAC Role або ClusterRole містять правила, які представляють набір дозволів. Дозволи є виключно адитивними (немає правил "заборони").
Role завжди встановлює дозволи в межах певного простору імен; коли ви створюєте Role, ви повинні вказати простір імен, до якого вона належить.
ClusterRole, на відміну, є ресурсом, який не належить до простору імен. Ресурси мають різні назви (Role і ClusterRole), оскільки обʼєкт Kubernetes завжди повинен бути або привʼязаним до простору імен, або не привʼязаним до простору імен; він не може бути одночасно і тим, і іншим.
ClusterRole мають кілька використань. Ви можете використовувати ClusterRole для:
визначення дозволів на ресурси, що належать до простору імен, і надання доступу в межах окремих просторів імен
визначення дозволів на ресурси, що належать до простору імен, і надання доступу до всіх просторів імен
визначення дозволів на ресурси, що належать до кластера
Якщо ви хочете визначити роль в межах простору імен, використовуйте Role; якщо ви хочете визначити роль для всього кластера, використовуйте ClusterRole.
Приклад Role
Ось приклад Role в просторі імен "default", яку можна використовувати для надання доступу на читання до Podʼів:
apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:pod-readerrules:- apiGroups:[""]# "" означає основну групу APIresources:["pods"]verbs:["get","watch","list"]
Приклад ClusterRole
ClusterRole може бути використана для надання тих самих дозволів, що й Role. Оскільки ClusterRole стосуються всього кластера, ви також можете використовувати їх для надання доступу до:
ресурсів, що належать до кластера (наприклад, вузли)
точок доступу, що не є ресурсами (наприклад, /healthz)
ресурсів, що належать до простору імен (наприклад, контейнерів), в усіх просторах імен
Наприклад: ви можете використовувати ClusterRole для дозволу конкретному користувачу виконувати kubectl get pods --all-namespaces.
Ось приклад ClusterRole, яку можна використовувати для надання доступу на читання Secretʼів в будь-якому просторі імен або в усіх просторах імен (залежно від того, як вона звʼязана):
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:# "namespace" пропущено, оскільки ClusterRole не привʼязані до простору іменname:secret-readerrules:- apiGroups:[""]## на рівні HTTP, назва ресурсу для доступу до обʼєктів Secret# це "secrets"resources:["secrets"]verbs:["get","watch","list"]
RoleBinding надає дозволи, визначені в ролі, користувачу або групі користувачів та містить список субʼєктів (користувачів, груп або облікових записів сервісів) і посилання на роль, що надається. RoleBinding надає дозволи в межах конкретного простору імен, тоді як ClusterRoleBinding надає доступ на рівні всього кластера.
RoleBinding може посилатися на будь-яку Role в тому ж просторі імен. Альтернативно, RoleBinding може посилатися на ClusterRole і звʼязувати цю ClusterRole з простором імен RoleBinding. Якщо ви хочете звʼязати ClusterRole з усіма просторами імен у вашому кластері, використовуйте ClusterRoleBinding.
Назва обʼєкта RoleBinding або ClusterRoleBinding повинна бути дійсною назвою сегмента шляху.
Приклади RoleBinding
Ось приклад RoleBinding, який надає роль "pod-reader" користувачу "jane" в межах простору імен "default". Це дозволяє "jane" читати Podʼи в просторі імен "default".
apiVersion:rbac.authorization.k8s.io/v1# Це рольове звʼязування дозволяє "jane" читати Podʼи в просторі імен "default".# Ви повинні вже мати роль з назвою "pod-reader" в цьому просторі імен.kind:RoleBindingmetadata:name:read-podsnamespace:defaultsubjects:# Ви можете вказати більше одного "субʼєкта"- kind:Username:jane# "name" чутливе до регіструapiGroup:rbac.authorization.k8s.ioroleRef:# "roleRef" вказує на звʼязування з Role / ClusterRolekind:Role# має бути Role або ClusterRolename:pod-reader# має збігатися з назвою Role або ClusterRole, з якою ви хочете звʼязатиapiGroup:rbac.authorization.k8s.io
RoleBinding також може посилатися на ClusterRole для надання дозволів, визначених у цій ClusterRole, на ресурси в межах простору імен RoleBinding. Такий вид посилання дозволяє визначати набір загальних ролей для всього вашого кластера, а потім використовувати їх у декількох просторах імен.
Наприклад, хоча наступний RoleBinding посилається на ClusterRole, "dave" (субʼєкт, чутливий до регістру) зможе читати Secretʼи лише в просторі імен "development", оскільки простір імен RoleBinding (у його метаданих) — "development".
apiVersion:rbac.authorization.k8s.io/v1# Це рольове звʼязування дозволяє "dave" читати Secretʼи в просторі імен "development".# Ви повинні вже мати ClusterRole з назвою "secret-reader".kind:RoleBindingmetadata:name:read-secrets## Простір імен RoleBinding визначає, де надаються дозволи.# Це надає дозволи лише в просторі імен "development".namespace:developmentsubjects:- kind:Username:dave# Name чутливе до регіструapiGroup:rbac.authorization.k8s.ioroleRef:kind:ClusterRolename:secret-readerapiGroup:rbac.authorization.k8s.io
Приклад ClusterRoleBinding
Щоб надати дозволи на рівні всього кластера, ви можете використовувати ClusterRoleBinding. Наступний ClusterRoleBinding дозволяє будь-якому користувачу з групи "manager" читати Secretʼи в будь-якому просторі імен.
apiVersion:rbac.authorization.k8s.io/v1# Це звʼязування кластерної ролі дозволяє будь-якому користувачу з групи "manager" читати Secretʼи в будь-якому просторі імен.kind:ClusterRoleBindingmetadata:name:read-secrets-globalsubjects:- kind:Groupname:manager# Name чутливе до регіструapiGroup:rbac.authorization.k8s.ioroleRef:kind:ClusterRolename:secret-readerapiGroup:rbac.authorization.k8s.io
Після створення звʼязування ви не можете змінити Role або ClusterRole, на які вони посилаються. Якщо ви спробуєте змінити roleRef звʼязування, ви отримаєте помилку валідації. Якщо ви дійсно хочете змінити roleRef для звʼязування, вам потрібно видалити обʼєкт звʼязування і створити новий.
Існує дві причини для цього обмеження:
Роблячи roleRef незмінним, можна надати комусь дозвіл update на наявний обʼєкт звʼязування, щоб він міг керувати списком субʼєктів, без можливості змінити роль, яка надається цим субʼєктам.
Звʼязування з іншою роллю є принципово іншим звʼязуванням. Вимога видалення/створення нового звʼязування для зміни roleRef гарантує, що весь список субʼєктів у звʼязуванні має намір отримати нову роль (на відміну від можливості випадково змінити лише roleRef без перевірки того, чи всі наявні субʼєкти повинні отримати дозволи нової ролі).
Команда kubectl auth reconcile створює або оновлює файл маніфесту, що містить обʼєкти RBAC, і обробляє видалення та відновлення обʼєктів звʼязування, якщо необхідно змінити роль, на яку вони посилаються. Дивіться використання команд та приклади для отримання додаткової інформації.
Посилання на ресурси
У Kubernetes API більшість ресурсів представлені та доступні за допомогою рядкового представлення їхнього імені обʼєкта, наприклад, pods для Pod. RBAC посилається на ресурси, використовуючи точно таку ж назву, яка зʼявляється в URL для відповідної точки доступу API. Деякі Kubernetes API включають субресурс, такий як логи для Pod. Запит на логи Pod виглядає так:
GET /api/v1/namespaces/{namespace}/pods/{name}/log
У цьому випадку pods є ресурсом простору імен для Pod, а log є субресурсом pods. Щоб представити це в ролі RBAC, використовуйте слеш (/) для розділення ресурсу та субресурсу. Щоб дозволити субʼєкту читати pods і також отримувати доступ до субресурсу log для кожного з цих Pod, напишіть:
Ви також можете посилатися на ресурси за назвою для певних запитів через список resourceNames. Коли зазначено, запити можуть бути обмежені окремими екземплярами ресурсу. Ось приклад, що обмежує субʼєкт лише до get або updateConfigMap з назвою my-configmap:
apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:configmap-updaterrules:- apiGroups:[""]## на рівні HTTP, назва ресурсу для доступу до обʼєктів ConfigMap є "configmaps"resources:["configmaps"]resourceNames:["my-configmap"]verbs:["update","get"]
Примітка:
Ви не можете обмежити запити create або deletecollection за назвою ресурсу. Для create це обмеження виникає через те, що назва нового обʼєкта може бути невідомою на момент авторизації. Якщо ви обмежуєте list або watch за resourceName, клієнти повинні включати селектор поля metadata.name у свої запити list або watch, що відповідає зазначеному resourceName, щоб отримати авторизацію. Наприклад, kubectl get configmaps --field-selector=metadata.name=my-configmap
Замість того, щоб посилатися на окремі resources, apiGroups і verbs, ви можете використовувати символ підстановки *, щоб посилатися на всі такі обʼєкти. Для nonResourceURLs ви можете використовувати символ підстановки * як суфікс для глобального збігу. Для resourceNames порожній набір означає, що все дозволено. Ось приклад, що дозволяє виконувати будь-яку поточну і майбутню дію для всіх поточних та майбутніх ресурсів в API групі example.com. Це схоже на вбудовану роль cluster-admin.
apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:example.com-superuser# НЕ ВИКОРИСТОВУЙТЕ ЦЮ РОЛЬ, ЦЕ ЛИШЕ ПРИКЛАДrules:- apiGroups:["example.com"]resources:["*"]verbs:["*"]
Увага:
Використання символів підстановки в записах ресурсів і дій може призвести до надмірно широкого доступу до чутливих ресурсів. Наприклад, якщо додано новий тип ресурсу або новий субресурс, або перевірено нову спеціальну дію, запис символу підстановки автоматично надає доступ, що може бути небажаним. Слід застосовувати принцип мінімальних привілеїв, використовуючи конкретні ресурси та дії, щоб забезпечити лише ті дозволи, які необхідні для правильного функціонування робочого навантаження.
Агреговані ClusterRole
Ви можете агрегувати декілька ClusterRole в одну комбіновану ClusterRole. Контролер, який працює як частина панелі управління кластера, слідкує за обʼєктами ClusterRole з встановленим aggregationRule. aggregationRule визначає мітку селектора, яку використовує контролер для вибору інших обʼєктів ClusterRole, що мають бути обʼєднані у поле rules цього обʼєкта.
Увага:
Панель управління перезаписує будь-які значення, які ви вручну вказуєте в полі rules агрегованої ClusterRole. Якщо ви хочете змінити або додати правила, робіть це в обʼєктах ClusterRole, вибраних за допомогою aggregationRule.
Ось приклад агрегованої ClusterRole:
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:monitoringaggregationRule:clusterRoleSelectors:- matchLabels:rbac.example.com/aggregate-to-monitoring:"true"rules:[]# Панель управління автоматично заповнює правила
Якщо ви створюєте нову ClusterRole, що відповідає селектору міток поточної агрегованої ClusterRole, це зміна ініціює додавання нових правил до агрегованої ClusterRole. Ось приклад, що додає правила до ClusterRole "monitoring" шляхом створення іншої ClusterRole з міткою rbac.example.com/aggregate-to-monitoring: true.
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:monitoring-endpointslabels:rbac.example.com/aggregate-to-monitoring:"true"# При створенні ClusterRole "monitoring-endpoints",# правила нижче будуть додані до ClusterRole "monitoring".rules:- apiGroups:[""]resources:["services","endpointslices","pods"]verbs:["get","list","watch"]
Стандартні ролі для користувачів використовують агрегацію ClusterRole. Це дозволяє вам, як адміністратору кластера, включати правила для спеціальних ресурсів, таких як ті, що надаються CustomResourceDefinitions або агрегованими API серверами, щоб розширити стандартні ролі.
Наприклад: наступні ClusterRole дозволяють стандартним ролям "admin" і "edit" керувати спеціальним ресурсом з назвою CronTab, тоді як роль "view" може виконувати лише читання ресурсів CronTab. Ви можете припустити, що обʼєкти CronTab називаються "crontabs" в URL, як це бачить API сервер.
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:aggregate-cron-tabs-editlabels:# Додайте ці дозволи до стандартних ролей "admin" і "edit".rbac.authorization.k8s.io/aggregate-to-admin:"true"rbac.authorization.k8s.io/aggregate-to-edit:"true"rules:- apiGroups:["stable.example.com"]resources:["crontabs"]verbs:["get","list","watch","create","update","patch","delete"]---kind:ClusterRoleapiVersion:rbac.authorization.k8s.io/v1metadata:name:aggregate-cron-tabs-viewlabels:# Додайте ці дозволи до стандартної ролі "view".rbac.authorization.k8s.io/aggregate-to-view:"true"rules:- apiGroups:["stable.example.com"]resources:["crontabs"]verbs:["get","list","watch"]
Приклади ролей
Наступні приклади є фрагментами обʼєктів Role або ClusterRole, що показують лише секцію rules.
Дозволити читання ресурсів "pods" у базовій API Group:
rules:- apiGroups:[""]## на рівні HTTP, назва ресурсу для доступу до обʼєктів Pod# є "pods"resources:["pods"]verbs:["get","list","watch"]
Дозволити читання/запис обʼєктів Deployment (на рівні HTTP: обʼєкти з "deployments" у частині ресурсу їх URL) в групах API "apps":
rules:- apiGroups:["apps"]## на рівні HTTP, назва ресурсу для доступу до обʼєктів Deployment# є "deployments"resources:["deployments"]verbs:["get","list","watch","create","update","patch","delete"]
Дозволити читання Podʼів у базовій групі API, а також читання або запис ресурсів Job у групі API "batch":
rules:- apiGroups:[""]## на рівні HTTP, назва ресурсу для доступу до обʼєктів Pod# є "pods"resources:["pods"]verbs:["get","list","watch"]- apiGroups:["batch"]## на рівні HTTP, назва ресурсу для доступу до обʼєктів Job# є "jobs"resources:["jobs"]verbs:["get","list","watch","create","update","patch","delete"]
Дозволити читання ConfigMap з назвою "my-config" (повинно бути повʼязано з RoleBinding, щоб обмежити до одного ConfigMap в одному просторі імен):
rules:- apiGroups:[""]## на рівні HTTP, назва ресурсу для доступу до обʼєктів ConfigMap# є "configmaps"resources:["configmaps"]resourceNames:["my-config"]verbs:["get"]
Дозволити читання ресурсу "nodes" у базовій групі (оскільки Node є кластерним ресурсом, це повинно бути у ClusterRole, повʼязаної з ClusterRoleBinding, щоб бути ефективним):
rules:- apiGroups:[""]## на рівні HTTP, назва ресурсу для доступу до обʼєктів Node# є "nodes"resources:["nodes"]verbs:["get","list","watch"]
Дозволити GET і POST запити до не-ресурсної точки доступу /healthz та всіх субшляхів (повинно бути в ClusterRole, повʼязаній з ClusterRoleBinding, щоб бути ефективним):
rules:- nonResourceURLs:["/healthz","/healthz/*"]# '*' у nonResourceURL є суфіксом для глобального збігуverbs:["get","post"]
Посилання на субʼєктів
RoleBinding або ClusterRoleBinding привʼязує роль до субʼєктів. Субʼєктами можуть бути групи, користувачі або ServiceAccounts.
Kubernetes представляє імена користувачів у вигляді рядків. Це можуть бути: звичайні імена, такі як "alice"; імена в стилі електронної пошти, як "bob@example.com"; або числові ідентифікатори користувачів, представлені у вигляді рядків. Вам, як адміністратору кластера, належить налаштувати модулі автентифікації, щоб автентифікація генерувала імена користувачів у бажаному форматі.
Увага:
Префікс system: зарезервований для використання системою Kubernetes, тому переконайтеся, що випадково не маєте користувачів або груп з іменами, що починаються з system:. Окрім цього спеціального префікса, система авторизації RBAC не вимагає жодного формату для імен користувачів.
У Kubernetes модулі Автентифікатора надають інформацію про групи. Групи, як і користувачі, представлені у вигляді рядків, і цей рядок не має жодних вимог до формату, крім того, що префікс system: зарезервований.
ServiceAccounts мають імена з префіксом system:serviceaccount:, і належать до груп, що мають імена з префіксом system:serviceaccounts:.
Примітка:
system:serviceaccount: (однина) є префіксом для імен користувачів службових облікових записів.
system:serviceaccounts: (множина) є префіксом для імен груп службових облікових записів.
Приклади RoleBinding
Наступні приклади є фрагментами RoleBinding, що показують лише секцію subjects.
API-сервери створюють набір стандартних обʼєктів ClusterRole і ClusterRoleBinding. Багато з них мають префікс system:, що вказує на те, що ресурс безпосередньо керується панеллю управління кластера. Усі стандартні ролі та привʼязки ролей мають мітку kubernetes.io/bootstrapping=rbac-defaults.
Увага:
Будьте обережні при зміні ClusterRole і ClusterRoleBinding з іменами, що мають префікс system:. Зміни цих ресурсів можуть призвести до несправних кластерів.
Автоматичне узгодження
При кожному запуску API-сервер оновлює стандартні ролі кластера, додаючи будь-які відсутні дозволи, та оновлює стандартні привʼязки ролей, додаючи будь-які відсутні субʼєкти. Це дозволяє кластеру виправляти випадкові зміни та допомагає підтримувати ролі та привʼязки ролей в актуальному стані, оскільки дозволи та субʼєкти змінюються у нових випусках Kubernetes.
Щоб відмовитися від цього відновлення, встановіть анотацію rbac.authorization.kubernetes.io/autoupdate на стандартну роль або привʼязку ролі у значення false. Зверніть увагу, що відсутні стандартні дозволи та субʼєкти можуть призвести до несправних кластерів.
Автоматичне узгодження стандартно увімкнено, якщо авторизатор RBAC активний.
Ролі виявлення API
Стандартні привʼязки ролей дозволяють неавторизованим і авторизованим користувачам читати інформацію про API, яка вважається безпечною для публічного доступу (включаючи CustomResourceDefinitions). Щоб вимкнути анонімний неавторизований доступ, додайте --anonymous-auth=false до конфігурації API-сервера.
Щоб переглянути конфігурацію цих ролей через kubectl, запустіть:
kubectl get clusterroles system:discovery -o yaml
Примітка:
Якщо ви зміните цю ClusterRole, ваші зміни будуть перезаписані при перезапуску API-сервера через Автоматичне узгодження. Щоб уникнути цього перезапису, або не редагуйте роль вручну, або вимкніть Автоматичне узгодження.
Ролі виявлення API Kubernetes RBAC
Стандартна ClusterRole
Стандартна ClusterRoleBinding
Опис
system:basic-user
Група system:authenticated
Дозволяє користувачеві доступ лише для читання базової інформації про себе. До v1.14 ця роль також була стандартно повʼязана з system:unauthenticated.
system:discovery
Група system:authenticated
Дозволяє доступ лише для читання точок доступу виявлення API, необхідних для виявлення та узгодження рівня API. До v1.14 ця роль також була стандартно повʼязана з system:unauthenticated.
system:public-info-viewer
Групи system:authenticated і system:unauthenticated
Дозволяє доступ лише для читання несекретної інформації про кластер. Представлено у Kubernetes v1.14.
Ролі для користувачів
Деякі зі стандартних ClusterRoles не мають префікса system:. Вони включають ролі суперкористувача (cluster-admin), ролі, призначені для надання у всьому кластері за допомогою ClusterRoleBindings, а також ролі, призначені для надання у певних просторах імен простору імен за допомогою RoleBindings (admin, edit, view).
Ролі для користувачів використовують агрегацію ClusterRole, щоб дозволити адміністраторам включати правила для спеціальних ресурсів у ці ClusterRole. Щоб додати правила до ролей admin, edit або view, створіть ClusterRole з однією або кількома з наступних міток:
Дозволяє доступ суперкористувача для виконання будь-якої дії на будь-якому ресурсі. При використанні в ClusterRoleBinding, надає повний контроль над кожним ресурсом у кластері та у всіх просторах імен. При використанні в RoleBinding, надає повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен.
admin
Немає
Дозволяє доступ адміністратора, призначений для надання в межах простору імен за допомогою RoleBinding.
Якщо використовується в RoleBinding, дозволяє доступ для читання/запису до більшості ресурсів у просторі імен, включаючи можливість створювати ролі та привʼязки ролей у просторі імен. Ця роль не дозволяє доступу для запису до квоти ресурсів або до самого простору імен. Ця роль також не дозволяє доступу для запису до EndpointSlices (або Endpoints) у кластерах, створених за допомогою Kubernetes v1.22+. Більше інформації доступно у розділі
"Достпу на запису у EndpointSlices та Endpoints".
edit
Немає
Дозволяє доступ для читання/запису до більшості обʼєктів у просторі імен.
Ця роль не дозволяє переглядати або змінювати ролі або привʼязки ролей. Однак ця роль дозволяє доступ до Secretʼів і запуску Podʼів як будь-який ServiceAccount у просторі імен, тому вона може бути використана для отримання рівня доступу API будь-якого ServiceAccount у просторі імен. Ця роль також не дозволяє доступу для запису до EndpointSlices (або Endpoints) у кластерах, створених за допомогою Kubernetes v1.22+. Більше інформації доступно у розділі "Достпу на запису у EndpointSlices та Endpoints".
view
Немає
Дозволяє доступ лише для читання до більшості обʼєктів у просторі імен. Ця роль не дозволяє переглядати ролі або привʼязки ролей. Ця роль не дозволяє переглядати Secretʼи, оскільки читання вмісту секретів дозволяє доступ до облікових даних ServiceAccount у просторі імен, що дозволило б доступ до API як будь-який ServiceAccount у просторі імен (форма ескалації привілеїв).
Ролі основних компонентів
Стандартна ClusterRole
Стандартна ClusterRoleBinding
Опис
system:kube-scheduler
system:kube-scheduler користувач
Дозволяє доступ до ресурсів, необхідних компоненту планувальника.
system:volume-scheduler
system:kube-scheduler користувач
Дозволяє доступ до ресурсів обʼєму, необхідних компоненту kube-scheduler.
Дозволяє доступ до ресурсів, необхідних для kubelet, включаючи доступ на читання до всіх секретів та доступ на запис до всіх обʼєктів стану Podʼів.
Ви повинні використовувати Node authorizer та втулок допуску NodeRestriction замість ролі system:node та дозволяти надання доступу до API для kubelet на основі Podʼів, які заплановано для запуску на них.
Роль system:node існує лише для сумісності з кластерами Kubernetes, оновленими з версій до v1.8.
system:node-proxier
system:kube-proxy користувач
Дозволяє доступ до ресурсів, необхідних компоненту kube-proxy.
Ролі інших компонентів
Стандартна ClusterRole
Стандартна ClusterRoleBinding
Опис
system:auth-delegator
Немає
Дозволяє делеговані перевірки автентифікації та авторизації. Це зазвичай використовується серверами надбудов API для уніфікованої автентифікації та авторизації.
Дозволяє доступ на читання до точок доступу моніторингу панелі управління (тобто kube-apiserver точки доступу придатності та готовності (/healthz, /livez, /readyz), індивідуальні точки доступу перевірки стану (/healthz/*, /livez/*, /readyz/*) та /metrics). Зверніть увагу, що індивідуальні точки доступу перевірки стану та точка доступу метрик можуть розкривати конфіденційну інформацію.
Ролі для вбудованих контролерів
Менеджер контролерів Kubernetes запускає контролери, які вбудовані в панель управління Kubernetes. Коли його викликають з --use-service-account-credentials, kube-controller-manager запускає кожен контролер використовуючи окремий службовий обліковий запис. Для кожного вбудованого контролера існують відповідні ролі з префіксом system:controller:. Якщо менеджер контролерів не запускається з --use-service-account-credentials, він виконує всі контрольні цикли використовуючи власні облікові дані, які повинні мати всі відповідні ролі. Ці ролі включають:
Запобігання ескалації привілеїв і початкове налаштування
API RBAC запобігає ескалації привілеїв користувачами шляхом редагування ролей або привʼязок ролей. Оскільки це реалізується на рівні API, це застосовується навіть коли авторизатор RBAC не використовується.
Обмеження на створення або оновлення ролей
Ви можете створити/оновити роль, тільки якщо виконується хоча б одна з наступних умов:
Ви вже маєте всі дозволи, що містяться в ролі, в тій же області, що й обʼєкт, який модифікується (кластерний рівень для ClusterRole, у тому ж просторі імен або кластерний рівень для Role).
Вам надано явний дозвіл виконувати дієслово escalate для ресурсу roles або clusterroles в групі API rbac.authorization.k8s.io.
Наприклад, якщо user-1 не має можливості отриамння переліку Secrets на кластерному рівні, він не може створити ClusterRole, що містить цей дозвіл. Щоб дозволити користувачу створювати/оновлювати ролі:
Надайте йому роль, що дозволяє створювати/оновлювати обʼєкти Role або ClusterRole, те що треба.
Надати йому дозвіл включати конкретні дозволи в ролі, які він створює/оновлює:
неявно, надаючи йому ці дозволи (якщо він спробує створити або модифікувати Role або ClusterRole з дозволами, які йому самому не надані, запит до API буде заборонений)
або явно дозволити вказувати будь-які дозволи в Role або ClusterRole, надаючи йому дозвіл виконувати дієслово escalate для ресурсів roles або clusterroles в групі API rbac.authorization.k8s.io.
Обмеження на створення або оновлення привʼязок ролей
Ви можете створити/оновити привʼязку ролі, тільки якщо вже маєте всі дозволи, що містяться в згаданій ролі (в тій же області, що й привʼязка ролі) або якщо вам надано дозвіл виконувати дієслово bind для згаданої ролі. Наприклад, якщо user-1 не має можливості отримувати перелік Secrets на кластерному рівні, він не може створити ClusterRoleBinding для ролі, яка надає цей дозвіл. Щоб дозволити користувачу створювати/оновлювати привʼязки ролей:
Надати йому роль, що дозволяє створювати/оновлювати обʼєкти RoleBinding або ClusterRoleBinding, як необхідно.
Надати йому дозволи, необхідні для привʼязки певної ролі:
неявно, надаючи йому дозволи, що м стяться в ролі.
явно, надаючи йому дозвіл виконувати дієслово bind для певної Role (або ClusterRole).
Наприклад, цей ClusterRole і RoleBinding дозволять user-1 надавати іншим користувачам ролі admin, edit і view у просторі імен user-1-namespace:
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:role-grantorrules:- apiGroups:["rbac.authorization.k8s.io"]resources:["rolebindings"]verbs:["create"]- apiGroups:["rbac.authorization.k8s.io"]resources:["clusterroles"]verbs:["bind"]# пропустіть resourceNames, щоб дозволити привʼязку будь-якої ClusterRoleresourceNames:["admin","edit","view"]---apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:role-grantor-bindingnamespace:user-1-namespaceroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:role-grantorsubjects:- apiGroup:rbac.authorization.k8s.iokind:Username:user-1
Коли початково налаштовуються перші ролі та привʼязки ролей, необхідно, щоб початковий користувач надав дозволи, які він ще не має. Щоб початково налаштувати ролі та привʼязки ролей:
Використовуйте облікові дані з групою "system:masters", яка стандартно привʼязана до ролі суперкористувача "cluster-admin".
Утиліти командного рядка
kubectl create role
Створює обʼєкт Role, що визначає дозволи в межах одного простору імен. Приклади:
Створити Role з назвою "pod-reader", яка дозволяє користувачам виконувати get, watch і list для pods:
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
Створити Role з назвою "pod-reader" зі специфікованими resourceNames:
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
Створити Role з назвою "foo" зі специфікованими apiGroups:
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
Створити Role з назвою "foo" з дозволами на підресурси:
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
Створити Role з назвою "my-component-lease-holder" з дозволами на отримання/оновлення ресурсу зі специфічною назвою:
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
kubectl create clusterrole
Створює ClusterRole. Приклади:
Створити ClusterRole з назвою "pod-reader", яка дозволяє користувачам виконувати get, watch і list для pods:
Типові політики RBAC надають обмежені права компонентам панелі управління, вузлам і контролерам, але не надають жодних дозволів службовим обліковим записам за межами простору імен kube-system (поза межами дозволів, наданих ролями виявлення API).
Це дозволяє надавати конкретні ролі конкретним ServiceAccounts за необхідності. Тонке налаштування привʼязок ролей забезпечує більшу безпеку, але вимагає більше зусиль для адміністрування. Ширші привʼязки можуть надати зайвий (і потенційно ескалуючий) доступ до API ServiceAccounts, але їх легше адмініструвати.
Підходи від найбезпечніших до найменш безпечних:
Надання ролі для службового облікового запису для конкретного застосунку (найкращий варіант)
Це вимагає від застосунку зазначення serviceAccountName в його специфікації Pod, і створення службового облікового запису (через API, маніфест програми, kubectl create serviceaccount, тощо).
Наприклад, надати права лише на читання в межах "my-namespace" службовому обліковому запису "my-sa":
Багато надбудов працюють від імені службового облікового запису "default" у просторі імен kube-system. Щоб дозволити цим надбудовам працювати з правами суперкористувача, надайте права cluster-admin службовому обліковому запису "default" у просторі імен kube-system.
Увага:
Включення цього означає, що в просторі імен kube-system знаходяться Secretʼи, які надають доступ суперкористувача до API вашого кластера.
Надання ролі всім службовим обліковим записам у просторі імен
Якщо ви хочете, щоб усі програми в просторі імен мали роль, незалежно від того, який службовий обліковий запис вони використовують, ви можете надати роль групі службових облікових записів для цього простору імен.
Наприклад, надати права лише на читання в межах "my-namespace" усім службовим обліковим записам у цьому просторі імен:
Надання прав суперкористувача всім службовим обліковим записам у кластері (категорично не рекомендується)
Якщо вам не важливо розподіляти дозволи взагалі, ви можете надати права суперкористувача всім службовим обліковим записам.
Попередження:
Це надає будь-якому застосунку повний доступ до вашого кластера, а також надає будь-якому користувачеві з правами читання Secretʼів (або здатності створювати будь-які Pod) повний доступ до вашого кластера.
Кластери Kubernetes, створені до версії Kubernetes v1.22, включають права запису для EndpointSlices (і Endpoints) у ролях "edit" і "admin". У рамках помʼякшення наслідків CVE-2021-25740, цей доступ не є частиною агрегованих ролей у кластерах, створених із використанням Kubernetes v1.22 або пізніших версій.
Кластери, які були оновлені до Kubernetes v1.22, не підпадають під цю зміну. Оголошення CVE включає вказівки щодо обмеження цього доступу в поточних кластерах.
Якщо ви хочете, щоб нові кластери зберігали цей рівень доступу в агрегованих ролях, ви можете створити наступну ClusterRole:
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:annotations:kubernetes.io/description:|- Add endpoints write permissions to the edit and admin roles. This was
removed by default in 1.22 because of CVE-2021-25740. See
https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer
or Ingress implementations to expose backend IPs that would not otherwise
be accessible, and can circumvent network policies or security controls
intended to prevent/isolate access to those backends.
EndpointSlices were never included in the edit or admin roles, so there
is nothing to restore for the EndpointSlice API.labels:rbac.authorization.k8s.io/aggregate-to-edit:"true"name:custom:aggregate-to-edit:endpoints# виможете змінити це поле, за бажаннямrules:- apiGroups:[""]resources:["endpoints"]verbs:["create","delete","deletecollection","patch","update"]
Оновлення з ABAC
Кластери, що спочатку працювали на старіших версіях Kubernetes, часто використовували дозвільні політики ABAC, включаючи надання повного доступу до API всім службовим обліковим записам.
Типові політики RBAC надають обмежені права компонентам панелі управління, вузлам і контролерам, але не надають жодних дозволів службовим обліковим записам за межами простору імен kube-system (поза межами дозволів, наданих ролями виявлення API).
Хоча це набагато безпечніше, це може бути руйнівним для поточних робочих навантажень, які очікують автоматичного отримання дозволів API. Ось два підходи для управління цим переходом:
Паралельні авторизатори
Запускайте як RBAC, так і ABAC авторизатори, і вкажіть файл політики, що містить стару політику ABAC:
Щоб детально пояснити цей перший параметр командного рядка: якщо раніші авторизатори, такі як Node, відхиляють запит, тоді авторизатор RBAC намагається авторизувати запит до API. Якщо RBAC також відхиляє цей запит до API, тоді запускається авторизатор ABAC. Це означає, що будь-який запит, дозволений будь-якою політикою RBAC або ABAC, буде дозволений.
Коли kube-apiserver запускається з рівнем логування 5 або вище для компонента RBAC (--vmodule=rbac*=5 або --v=5), ви можете побачити відмови RBAC у лозі сервера API (позначені як RBAC). Ви можете використовувати цю інформацію для визначення, які ролі потрібно надати яким користувачам, групам або службовим обліковим записам.
Після того, як ви надали ролі службовим обліковим записам і робочі навантаження працюють без повідомлень про відмову RBAC у логах сервера, ви можете видалити авторизатор ABAC.
Дозвільні права RBAC
Ви можете відтворити дозвільну політику ABAC, використовуючи привʼязки ролей RBAC.
Попередження:
Наступна політика дозволяє ВСІМ службовим обліковим записам діяти як адміністратори кластера. Будь-який застосунок, що працює в контейнері, автоматично отримує облікові дані службового облікового запису і може виконувати будь-яку дію з API, включаючи перегляд секретів і зміну дозволів. Це не рекомендована політика.
Після переходу на використання RBAC, ви повинні налаштувати контроль доступу для вашого кластера, щоб забезпечити відповідність вашим інформаційним вимогам безпеки.
3.5 - Використання авторизації вузлів
Авторизація вузлів — це режим авторизації спеціального призначення, який спеціально авторизує запити API, зроблені kubelet-ами.
Огляд
Авторизатор вузлів дозволяє kubelet-ам виконувати операції з API. Це включає:
Операції читання:
services
endpoints
nodes
pods
secrets, configmaps, persistent volume claims та persistent volumes, що стосуються
Podʼів, привʼязаних до вузла kubelet-а
Операції запису:
вузли та статус вузлів (увімкніть втулок допуску NodeRestriction, щоб обмежити
kubelet у зміні свого власного вузла)
поди та статус подів (увімкніть втулок допуску NodeRestriction, щоб обмежити
kubelet у зміні подів, прив'язаних до себе)
можливість створювати TokenReview та SubjectAccessReview для делегованої
автентифікації/авторизації
У майбутніх випусках авторизатор вузлів може додавати або видаляти дозволи, щоб забезпечити kubelet-и мінімальним набором дозволів, необхідних для правильної роботи.
Для того, щоб бути авторизованими авторизатором вузлів, kubelet-и повинні використовувати облікові дані, які ідентифікують їх як членів групи system:nodes, з іменем користувача system:node:<nodeName>. Цей формат групи та імені користувача відповідає ідентичності, створеній для кожного kubelet-а в рамках TLS початкового запуску kubelet-а.
Значення <nodeName>має точно відповідати імені вузла, як зареєстровано kubelet-ом. Стандартно це імʼя хосту, надане hostname, або замінене за допомогою опції kubelet--hostname-override. Однак, при використанні опції kubelet --cloud-provider, конкретне імʼя хосту може бути визначено постачальником хмарних послуг, ігноруючи локальний hostname та опцію --hostname-override. Для деталей щодо визначення імені хосту kubelet-ом, дивіться довідник з опцій kubelet.
Щоб увімкнути авторизатор вузлів, запустіть apiserver з --authorization-mode=Node.
Щоб обмежити обʼєкти API, які можуть писати kubelet-и, увімкніть втулок допуску NodeRestriction
шляхом запуску apiserver з --enable-admission-plugins=...,NodeRestriction,....
Міркування щодо міграції
Kubelet-и поза групою system:nodes
Kubelet-и, що знаходяться поза групою system:nodes, не будуть авторизовані режимом авторизації Node, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує. Вутлок допуску вузлів не буде обмежувати запити від цих kubelet-ів.
Kubelet-и з недиференційованими іменами користувачів
У деяких розгортаннях kubelet-и мають облікові дані, що розміщують їх у групі system:nodes, але не ідентифікують конкретний вузол, з яким вони повʼязані, оскільки вони не мають імені користувача у форматі system:node:.... Ці kubelet-и не будуть авторизовані режимом авторизації Node, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує.
Втулок допуску NodeRestriction буде ігнорувати запити від цих kubelet-ів, оскільки стандартна реалізація ідентифікатора вузла не вважатиме це ідентичністю вузла.
3.6 - Режим Webhook
Webhook — це зворотний виклик HTTP: HTTP POST, який відбувається, коли щось стається; просте сповіщення про подію через HTTP POST. Вебзастосунок, що реалізує Webhook, буде надсилати POST повідомлення на URL, коли відбуваються певні події.
Коли вказано режим Webhook, Kubernetes звертається до зовнішнього REST сервісу для визначення привілеїв користувача.
Формат файлу конфігурації
Режим Webhook потребує файл для HTTP конфігурації, що вказується за допомогою прапорця --authorization-webhook-config-file=SOME_FILENAME.
Файл конфігурації використовує формат файлу kubeconfig. У файлі "users" стосується конфігурації webhook API сервера, а "clusters" — до віддаленого сервісу.
Приклад конфігурації, що використовує клієнтську автентифікацію HTTPS:
# Версія Kubernetes APIapiVersion:v1# тип API обʼєктаkind:Config# кластери відносяться до віддаленого сервісуclusters:- name:name-of-remote-authz-servicecluster:# CA для перевірки віддаленого сервісуcertificate-authority:/path/to/ca.pem# URL віддаленого сервісу для запитів. Має використовувати 'https'. Не може включати параметри.server:https://authz.example.com/authorize# користувачі відносяться до конфігурації webhook API сервераusers:- name:name-of-api-serveruser:client-certificate:/path/to/cert.pem# сертифікат для використання webhook втулкомclient-key:/path/to/key.pem # ключ, що відповідає сертифікату# файли kubeconfig вимагають контекст. Вкажіть один для API сервера.current-context:webhookcontexts:- context:cluster:name-of-remote-authz-serviceuser:name-of-api-servername:webhook
Запити корисного навантаження
При ухваленні рішення про авторизацію, API сервер надсилає JSON- серіалізований обʼєкт authorization.k8s.io/v1beta1SubjectAccessReview, що описує дію. Цей обʼєкт містить поля, що описують користувача, який намагається зробити запит, та деталі про ресурс, до якого здійснюється доступ, або атрибути запиту.
Зверніть увагу, що обʼєкти API webhook підлягають тим самим правилам сумісності версій, що й інші обʼєкти API Kubernetes. Імплементатори повинні бути обізнані з менш суворими обіцянками сумісності для бета-обʼєктів і перевіряти поле "apiVersion" запиту для забезпечення правильної десеріалізації. Додатково, API сервер повинен увімкнути групу розширень API authorization.k8s.io/v1beta1 (--runtime-config=authorization.k8s.io/v1beta1=true).
Віддалений сервіс має заповнити поле status запиту і відповісти, дозволяючи або забороняючи доступ. Поле spec у відповіді ігнорується і може бути пропущене. Дозвільна відповідь виглядатиме так:
Перший метод є кращим у більшості випадків і вказує, що webhook авторизації не дозволяє або не має "думки" ("no opinion") щодо запиту, але якщо інші авторизатори налаштовані, вони отримують шанс дозволити запит. Якщо немає інших авторизаторів або жоден з них не дозволяє запит, запит забороняється. Webhook поверне:
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": false,
"reason": "user does not have read access to the namespace" }
}
Другий метод негайно відмовляє, перериваючи оцінку іншими налаштованими авторизаторами. Це слід використовувати лише вебхуками, які мають детальні знання про повну конфігурацію авторизатора кластера. Webhook поверне:
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": false,
"denied": true,
"reason": "user does not have read access to the namespace" }
}
Нересурсні шляхи включають: /api, /apis, /metrics, /logs, /debug, /healthz, /livez, /openapi/v2, /readyz та /version. Клієнти потребують доступу до /api, /api/*, /apis, /apis/*, та /version для визначення, які ресурси та версії присутні на сервері. Доступ до інших нересурсних шляхів може бути заборонений без обмеження доступу до REST API.
За подальшою документацією звертайтеся до обʼєктів API authorization.v1beta1 та webhook.go.
3.7 - Використання ABAC авторизації
Авторизація на основі атрибутів (ABAC) визначає парадигму контролю доступу, за якою права доступу надаються користувачам за допомогою політик, які комбінують атрибути.
Формат файлу політики
Для увімкнення режиму ABAC вказуйте --authorization-policy-file=SOME_FILENAME та --authorization-mode=ABAC при запуску.
Формат файлу — один обʼєкт JSON на рядок. Не повинно бути жодного вкладеного списку або map, тільки один map на рядок.
Кожний рядок — "обʼєкт політики", де такий обʼєкт є map із такими властивостями:
Властивості версіювання:
apiVersion, типу string; допустимі значення "abac.authorization.kubernetes.io/v1beta1". Дозволяє версіювання та конвертацію формату політики.
kind, типу string: допустимі значення "Policy". Дозволяє версіювання та конвертацію формату політики.
Властивість spec встановлена на мапу з такими властивостями:
Властивості зіставлення субʼєкта:
user, типу string; рядок користувача з --token-auth-file. Якщо ви вказуєте user, він повинен збігатися з імʼям користувача автентифікованого користувача.
group, типу string; якщо ви вказуєте group, він повинен збігатися з однією з груп автентифікованого користувача. system:authenticated збігається з усіма автентифікованими запитами. system:unauthenticated збігається з усіма неавтентифікованими запитами.
Властивості зіставлення ресурсу:
apiGroup, типу string; група API.
Наприклад: apps, networking.k8s.io
Маска: * збігається з усіма групами API.
namespace, типу string; простір імен.
Наприклад: kube-system
Маска: * збігається з усіма запитами ресурсів.
resource, типу string; тип ресурсу
Наприклад: pods, deployments
Маска: * збігається з усіма запитами ресурсів.
Властивості зіставлення нересурсів:
nonResourcePath, типу string; шляхи запитів нересурсів.
Наприклад: /version або /apis
Маска:
* збігається з усіма запитами нересурсів.
/foo/* збігається з усіма підшляхами /foo/.
readonly, типу boolean, якщо true, означає, що політика, що зіставляється з ресурсом, застосовується тільки до операцій get, list, та watch, а політика, що зіставляється з нересурсами, застосовується тільки до операції get.
Примітка:
Невстановлена властивість є такою самою, як властивість, що встановлена на нульове значення для свого типу (наприклад, порожній рядок, 0, false). Проте невстановлена властивість має перевагу для зручності читання.
У майбутньому політики можна буде виражати у форматі JSON і керувати ними через REST-інтерфейс.
Алгоритм авторизації
У запиту є атрибути, які відповідають властивостям обʼєкта політики.
Коли отримано запит, визначаються атрибути. Невідомі атрибути встановлюються на нульове значення свого типу (наприклад, порожній рядок, 0, false).
Властивість, встановлена на "*", буде збігатися з будь-яким значенням відповідного атрибута.
Кортеж атрибутів перевіряється на відповідність кожній політиці в файлі політики. Якщо принаймні один рядок відповідає атрибутам запиту, тоді запит авторизований (але може зазнати невдачі під час подальшої перевірки).
Щоб дозволити будь-якому автентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:authenticated".
Щоб дозволити будь-якому неавтентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:unauthenticated".
Щоб дозволити користувачеві зробити все, створіть політику з властивостями apiGroup, namespace, resource та nonResourcePath, встановленими на "*".
Kubectl
Kubectl використовує точки доступу /api та /apis apiserver для виявлення сервісів, які обслуговують типи ресурсів, і перевіряє обʼєкти, надіслані до API за допомогою операцій create/update, використовуючи інформацію про схему, розташовану в /openapi/v2.
При використанні авторизації на основі атрибутів, ці спеціальні ресурси мають бути явно відкриті за допомогою властивості nonResourcePath в політиці (див. приклади нижче):
/api, /api/*, /apis та /apis/* для вибору версії API.
/version для отримання версії сервера через kubectl version.
/swaggerapi/* для операцій create/update.
Щоб перевірити HTTP-виклики, повʼязані з певною операцією kubectl, ви можете збільшити рівень деталізації:
Кожен службовий обліковий запис має відповідне імʼя користувача ABAC, і імʼя цього службового облікового запису генерується згідно з конвенцією щодо найменування:
Створюючи новий простір імен, створюється новий службовий обліковий запис у наступному форматі:
system:serviceaccount:<namespace>:default
Наприклад, якщо ви хочете надати стандартному службовому обліковому запису (у просторі імен kube-system) повні привілеї в API за допомогою ABAC, ви додаєте цей рядок до файлу політики:
apiserver повинен бути перезапущений, щоб використати нові рядки.
3.8 - Контролери допуску
Ця сторінка надає огляд контролерів допуску.
Що це таке?
Контролер допуску — це фрагмент коду, який перехоплює запити до сервера API Kubernetes перед збереженням обʼєкта, але після того, як запит був автентифікований та авторизований.
Контролери допуску можуть бути валідаційними, модифікуючими або обома. Модифікуючі контролери можуть змінювати обʼєкти, повʼязані з запитами, які вони допускають; валідаційні контролери не можуть цього робити.
Контролери допуску обмежують запити на створення, видалення, зміну обʼєктів. Контролери допуску також можуть блокувати нестандартні дієслова, такі як запити на підключення до Podʼу через проксі сервера API. Контролери допуску не блокують (і не можуть) запити на читання (get, watch або list) обʼєктів.
Контролери допуску в Kubernetes 1.30 складаються зі списку нижче, вбудовані у двійковий файл kube-apiserver і можуть бути налаштовані тільки адміністратором кластера. У цьому списку є два спеціальні контролери: MutatingAdmissionWebhook і ValidatingAdmissionWebhook. Вони виконують модифікуючі та валідаційні (відповідно) вебхуки контролю допуску,
які налаштовуються в API.
Етапи контролю допуску
Процес контролю допуску проходить у два етапи. На першому етапі виконуються модифікуючі контролери допуску. На другому етапі виконуються валідаційні контролери допуску. Знову ж таки, деякі контролери є обома.
Якщо будь-який з контролерів на будь-якому етапі відхиляє запит, весь запит негайно відхиляється, і користувачу повертається помилка.
Нарешті, окрім іноді модифікації обʼєкта, про який йдеться, контролери допуску можуть іноді мати побічні ефекти, тобто змінювати повʼязані ресурси в процесі обробки запиту. Збільшення використання квоти є класичним прикладом того, чому це необхідно. Будь-який такий побічний ефект потребує відповідного процесу рекламації або узгодження, оскільки даний контролер допуску не знає напевно, що даний запит пройде через всі інші контролери допуску.
Чому вони потрібні?
Кілька важливих функцій Kubernetes вимагають увімкнення контролера допуску для належної підтримки функції. Як результат, сервер API Kubernetes, який неправильно налаштований з необхідним набором контролерів допуску, є неповним сервером і не підтримуватиме всі функції, які ви очікуєте.
Як увімкнути контролер допуску?
Прапорець сервера API Kubernetes enable-admission-plugins приймає через кому список втулків контролю допуску, які слід викликати перед зміною обʼєктів у кластері. Наприклад, наступна команда увімкне втулки контролю допуску NamespaceLifecycle та LimitRanger:
Залежно від того, як ваш кластер Kubernetes розгорнутий і як запускається сервер API, вам може знадобитися застосувати налаштування різними способами. Наприклад, вам може знадобитися змінити файл системного блоку systemd, якщо сервер API розгорнуто як службу systemd ви можете змінити файл маніфесту для сервера API, якщо Kubernetes розгорнуто як самостійний хостинг.
Як вимкнути контролер допуску?
Прапорець сервера API Kubernetes disable-admission-plugins приймає через кому список втулків контролю допуску, які слід вимкнути, навіть якщо вони є у списку втулків, що є стандартно увімкненими.
Втулок допуску ValidatingAdmissionPolicy стандартно увімкнений, але активний тільки, якщо ви увімкнете функціональні можливостіValidatingAdmissionPolicyта API admissionregistration.k8s.io/v1alpha1.
Що робить кожен контролер допуску?
AlwaysAdmit
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.13 [deprecated]
Тип: Валідаційний.
Цей контролер допуску дозволяє запуск всіх Podʼів в кластер. Він застарілий, оскільки його поведінка така ж, якби не було ніякого контролера допуску взагалі.
AlwaysDeny
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.13 [deprecated]
Тип: Валідаційний.
Відхиляє всі запити. AlwaysDeny застарілий, оскільки не має реального значення.
AlwaysPullImages
Тип: Модифікуючий та Валідаційний.
Цей контролер допуску модифікує кожен новий Pod, щоб примусити використовувати політику завантаження образів Always. Це корисно в багатокористувацькому кластері, щоб користувачі могли бути впевнені, що їхні приватні образи можуть використовувати лише ті, хто має відповідні облікові дані для їх завантаження. Без цього контролера допуску, після того, як образи було завантажено на вузол, будь-який Pod будь-якого користувача може використовувати його, знаючи імʼя образу (за умови, що Pod розміщений на правильному вузлі), без жодної перевірки вторизації для образу. Коли цей контролер допуску увімкнений, образи завжди завантажуються перед запуском контейнерів, що означає, що потрібні дійсні облікові дані.
CertificateApproval
Тип: Валідаційний.
Цей контролер допуску спостерігає за запитами на затвердження ресурсів CertificateSigningRequest і виконує додаткові перевірки авторизації, щоб переконатися, що користувач, який затверджує, має дозвіл на затвердження запитів сертифікатів із запитаним spec.signerName у ресурсі CertificateSigningRequest.
Дивіться Запити на підписання сертифікатів для отримання додаткової інформації про дозволи, необхідні для виконання різних дій з ресурсами CertificateSigningRequest.
CertificateSigning
Тип: Валідаційний.
Цей контролер допуску спостерігає за оновленнями поля status.certificate ресурсів CertificateSigningRequest і виконує додаткові перевірки авторизації, щоб переконатися, що користувач, який підписує, має дозвіл на підписання запитів сертифікатів із запитаним spec.signerName у ресурсі CertificateSigningRequest.
Дивіться Запити на підписання сертифікатів для отримання додаткової інформації про дозволи, необхідні для виконання різних дій з ресурсами CertificateSigningRequest.
CertificateSubjectRestriction
Тип: Валідаційний.
Цей контролер допуску спостерігає за створенням ресурсів CertificateSigningRequest, які мають spec.signerName значення kubernetes.io/kube-apiserver-client. Він відхиляє будь-який запит, який вказує групу (або атрибут організації) system:masters.
DefaultIngressClass
Тип: Модифікуючий.
Цей контролер допуску спостерігає за створенням обʼєктів Ingress, які не запитують жодного конкретного класу ingress, і автоматично додає до них стандартний клас ingress. Таким чином, користувачі, які не запитують жодного спеціального класу ingress, не повинні про це турбуватися та отримають стандартний клас.
Цей контролер допуску нічого не робить, коли не налаштований жоден стандартний клас ingress. Коли більше одного класу ingress позначено як стандартний клас, він відхиляє будь-яке створення Ingress з помилкою, і адміністратор повинен переглянути свої обʼєкти IngressClass та позначити лише один як стандартний клас (з анотацією "ingressclass.kubernetes.io/is-default-class"). Цей контролер допуску ігнорує будь-які оновлення Ingress; він діє тільки при створенні.
Дивіться документацію Ingress для отримання додаткової інформації про класи ingress і як позначити один як стандартний клас.
DefaultStorageClass
Тип: Модифікуючий.
Цей контролер допуску спостерігає за створенням обʼєктів PersistentVolumeClaim, які не запитують жодного конкретного класу зберігання, і автоматично додає до них стандартний клас зберігання. Таким чином, користувачі, які не запитують жодного спеціального класу зберігання, не повинні про це турбуватися та отримають стандартний клас.
Цей контролер допуску нічого не робить, коли не налаштований жоден стандартний клас зберігання. Коли більше одного класу зберігання позначено як стандартний клас, він відхиляє будь-яке створення PersistentVolumeClaim з помилкою, і адміністратор повинен переглянути свої обʼєкти StorageClass і позначити лише один як стандартний клас. Цей контролер допуску ігнорує будь-які оновлення PersistentVolumeClaim; він діє тільки при створенні.
Дивіться документацію постійних томів про persistent volume claims та класи зберігання, а також як позначити клас зберігання як стандартний клас.
DefaultTolerationSeconds
Тип: Модифікуючий.
Цей контролер допуску встановлює стандартне значення толерантності для Podʼів, щоб терпіти taints notready:NoExecute та unreachable:NoExecute на основі параметрів введення k8s-apiserver default-not-ready-toleration-seconds та default-unreachable-toleration-seconds, якщо Podʼи ще не мають толерантності до taints node.kubernetes.io/not-ready:NoExecute або node.kubernetes.io/unreachable:NoExecute. Стандартне значення для default-not-ready-toleration-seconds та default-unreachable-toleration-seconds становить 5 хвилин.
DenyServiceExternalIPs
Тип: Валідаційний.
Цей контролер допуску відхиляє всі нові використання поля externalIPs у Service. Ця функція дуже потужна (дозволяє перехоплення мережевого трафіку) і не контролюється належним чином політиками. Коли цей контролер увімкнено, користувачі кластера не можуть створювати нові Serviceʼи, які використовують externalIPs, і не можуть додавати нові значення до externalIPs в поточних обʼєктах Service. Поточні використання externalIPs не зачіпаються, і користувачі можуть видаляти значення з externalIPs в наявних обʼєктах Service.
Більшість користувачів взагалі не потребує цієї функції, і адміністратори кластера повинні розглянути можливість її вимкнення. Кластери, які потребують цієї функції, повинні розглянути можливість використання власних політик для керування її використанням.
Цей контролер допуску стандартно вимкнено.
EventRateLimit
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.13 [alpha]
Тип: Валідаційний.
Цей контролер допуску зменшує проблему, коли API-сервер переповнюється запитами на зберігання нових подій (Events). Адміністратор кластера може вказати обмеження швидкості подій, виконавши такі кроки:
Увімкнути контролер допуску EventRateLimit;
Посилатися на конфігураційний файл EventRateLimit з файлу, наданого у командному рядку API-сервера з прапорцем --admission-control-config-file:
Цей втулок полегшує створення виділених вузлів з розширеними ресурсами. Якщо оператори хочуть створити виділені вузли з розширеними ресурсами (наприклад, GPU, FPGA тощо), вони повинні накладати taint на вузол з іменем розширеного ресурсу як ключем. Цей контролер допуску, якщо він увімкнений, автоматично додає толерантності до таких taint у Podʼи, які запитують розширені ресурси, тому користувачам не потрібно вручну додавати ці толерантності.
Цей контролер допуску стандартно вимкнено.
ImagePolicyWebhook
Тип: Валідаційний.
Контролер допуску ImagePolicyWebhook дозволяє бекенд-вебхуку приймати рішення про допуск.
Цей контролер допуску стандартно вимкнено.
Формат конфігураційного файлу
ImagePolicyWebhook використовує конфігураційний файл для налаштування поведінки бекенду. Цей файл може бути у форматі JSON або YAML і має наступний формат:
imagePolicy:kubeConfigFile:/path/to/kubeconfig/for/backend# час у секундах для кешування дозволуallowTTL:50# час у секундах для кешування відмовиdenyTTL:50# час у мілісекундах між спробами повторуretryBackoff:500# визначає поведінку у разі відмови бекенда вебхукаdefaultAllow:true
Посилання на конфігураційний файл ImagePolicyWebhook повинно бути зазначене у файлі, який передається прапорцю командного рядка API-сервера --admission-control-config-file:
Конфігураційний файл ImagePolicyWebhook повинен посилатися на файл у форматі kubeconfig, який налаштовує зʼєднання з бекендом. Бекенд повинен здійснювати комунікацію через TLS.
Поле cluster у файлі kubeconfig має посилатися на віддалений сервіс, а поле user повинно містити дані авторизації.
# clusters посилається на віддалений сервіс.clusters:- name:name-of-remote-imagepolicy-servicecluster:certificate-authority:/path/to/ca.pem # CA для верифікації віддаленого сервісу.server:https://images.example.com/policy# URL віддаленого сервісу для запитів. Повинен використовувати 'https'.# users посилається на конфігурацію вебхука API-сервера.users:- name:name-of-api-serveruser:client-certificate:/path/to/cert.pem# сертифікат для використання контролером допуску вебхукаclient-key:/path/to/key.pem # ключ, що відповідає сертифікату
Для додаткової конфігурації HTTP дивіться документацію kubeconfig.
Вміст запитів
Під час прийняття рішення про допуск, API-сервер надсилає POST-запит з серіалізованим у форматі JSON обʼєктом imagepolicy.k8s.io/v1alpha1ImageReview, що описує дію. Цей обʼєкт містить поля, що описують контейнери, які підлягають допуску, а також будь-які анотації Podʼу, що відповідають *.image-policy.k8s.io/*.
Примітка:
Обʼєкти API вебхуків підлягають тим самим правилам сумісності версій, що й інші обʼєкти API Kubernetes. Імплементатори повинні знати про менш жорсткі обіцянки сумісності для альфа-обʼєктів і перевіряти поле apiVersion запиту для забезпечення правильної десеріалізації. Крім того, API-сервер повинен увімкнути групу розширень API imagepolicy.k8s.io/v1alpha1 (--runtime-config=imagepolicy.k8s.io/v1alpha1=true).
Віддалений сервіс повинен заповнити поле status запиту і відповісти з дозволом або відмовою доступу. Поле spec тіла відповіді ігнорується, і його можна не включати. Відповідь, яка дозволяє доступ, виглядатиме так:
Усі анотації на Podʼі, що відповідають *.image-policy.k8s.io/*, надсилаються до вебхука. Надсилання анотацій дозволяє користувачам, які знають про бекенд політики образів, надсилати додаткову інформацію до нього, а також дозволяє реалізаціям різних бекендів приймати різну інформацію.
Приклади інформації, яку ви можете тут розмістити:
запит на "пробиття" для обходу політики у разі надзвичайної ситуації;
номер квитка з системи квитків, що документує запит на "пробиття";
підказка серверу політики щодо imageID наданого образу для економії часу на пошук.
У будь-якому випадку, анотації надаються користувачем і не перевіряються Kubernetes будь-яким чином.
LimitPodHardAntiAffinityTopology
Тип: Валідаційний.
Цей контролер допуску забороняє будь-який Pod, який визначає ключ топології AntiAffinity відмінний від kubernetes.io/hostname у requiredDuringSchedulingRequiredDuringExecution.
Цей контролер допуску стандартно вимкнено.
LimitRanger
Тип: Модифікуючий та Валідаційний.
Цей контролер допуску спостерігає за вхідним запитом та забезпечує, щоб він не порушував жодних обмежень, перерахованих в обʼєкті LimitRange в Namespace. Якщо ви використовуєте обʼєкти LimitRange у своєму розгортанні Kubernetes, ви МАЄТЕ використовувати цей контролер допуску для забезпечення дотримання цих обмежень. LimitRanger також може використовуватися для застосування стандартних ресурсних запитів до Pod, які їх не вказують; наразі стандартний LimitRanger застосовує вимогу до 0.1 CPU до всіх Pod у default namespace.
Цей контролер допуску викликає будь-які модифікуючі вебхуки, які відповідають запиту. Відповідні вебхуки викликаються послідовно; кожен з них може змінити обʼєкт, якщо це необхідно.
Цей контролер допуску (як випливає з назви) працює лише на етапі модифікації.
Якщо вебхук, викликаний цим контролером, має побічні ефекти (наприклад, зменшення квоти), він повинен мати систему узгодження, оскільки не гарантується, що наступні вебхуки або контролери допуску дозволять завершити запит.
Якщо ви вимкнете MutatingAdmissionWebhook, ви також повинні вимкнути обʼєкт MutatingWebhookConfiguration у групі/версії admissionregistration.k8s.io/v1 за допомогою прапорця --runtime-config, обидва стандартно увімкнені.
Будьте обережні при створенні та встановленні модифікуючих вебхуків
Користувачі можуть бути спантеличені, коли обʼєкти, які вони намагаються створити, відрізняються від того, що вони отримують назад.
Вбудовані контрольні цикли можуть зламатися, коли обʼєкти, які вони намагаються створити, відрізняються при зворотному читанні.
Встановлення спочатку незаданих полів менш ймовірно викличе проблеми, ніж переписування полів, встановлених у початковому запиті. Уникайте останнього.
Майбутні зміни в контрольних циклах для вбудованих або сторонніх ресурсів можуть зламати вебхуки, які добре працюють сьогодні. Навіть коли API вебхука для установки буде фіналізовано, не всі можливі поведінки вебхука будуть гарантовано підтримуватися нескінченно.
NamespaceAutoProvision
Тип: Модифікуючий.
Цей контролер допуску перевіряє всі вхідні запити на ресурси, що належать до namespace, і перевіряє чи існує зазначений namespace. Він створює namespace, якщо його не знайдено. Цей контролер допуску корисний у розгортаннях, які не хочуть обмежувати створення namespace до його використання.
NamespaceExists
Тип: Валідаційний.
Цей контролер допуску перевіряє всі запити на ресурси, що належать до namespace, крім самого Namespace. Якщо namespace, на який посилається запит, не існує, запит відхиляється.
NamespaceLifecycle
Тип: Валідаційний.
Цей контролер допуску забезпечує, що Namespace, який знаходиться в процесі завершення, не може мати нові обʼєкти, створені в ньому, і забезпечує відхилення запитів у неіснуючому Namespace. Цей контролер допуску також запобігає видаленню трьох системно зарезервованих namespaces: default, kube-system, kube-public.
Видалення Namespace запускає послідовність операцій, які видаляють усі обʼєкти (Pod, Service, тощо) у цьому namespace. Для забезпечення цілісності цього процесу, ми наполегливо рекомендуємо використовувати цей контролер допуску.
NodeRestriction
Тип: Валідаційний.
Цей контролер допуску обмежує обʼєкти Node і Pod, які kubelet може змінювати. Для того, щоб бути обмеженим цим контролером допуску, kubelets повинні використовувати облікові дані у групі system:nodes, з іменем користувача у формі system:node:<nodeName>. Такі kubelets будуть мати дозвіл лише змінювати свої власні обʼєкти API Node, і лише змінювати обʼєкти API Pod, які привʼязані до їх вузла. kubelets не мають права оновлювати або видаляти taint зі свого обʼєкта API Node.
Втулок допуску NodeRestriction перешкоджає kubelets видаляти їх обʼєкт API Node, і забезпечує оновлення kubeletʼом міток з префіксами kubernetes.io/ або k8s.io/ наступним чином:
Перешкоджає kubelets додавання/видалення/оновлення міток з префіксом node-restriction.kubernetes.io/. Цей префікс міток зарезервовано для адміністраторів для позначення мітками своїх обʼєктів Node з метою ізоляції робочих навантажень, і kubelets не буде дозволено змінювати мітки з цим префіксом.
Дозволяє kubelets додавати/видаляти/оновлювати ці мітки та префікси міток:
Використання будь-яких інших міток під префіксами kubernetes.io або k8s.io kubelets зарезервовано, і може бути заборонено або дозволено втулком допуску NodeRestriction у майбутньому.
Майбутні версії можуть додати додаткові обмеження для забезпечення того, щоб kubelets мали мінімальний набір дозволів, необхідних для правильної роботи.
OwnerReferencesPermissionEnforcement
Тип: Валідаційний.
Цей контролер допуску захищає доступ до metadata.ownerReferences обʼєкта, так що тільки користувачі з правами delete у обʼєкта можуть його змінювати. Цей контролер допуску також захищає доступ до metadata.ownerReferences[x].blockOwnerDeletion обʼєкта, так що тільки користувачі з правами update у субресурсу finalizers посилального власника можуть його змінювати.
PersistentVolumeClaimResize
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.24 [stable]
Тип: Валідаційний.
Цей контролер допуску реалізує додаткові перевірки для перевірки вхідних запитів на зміну розміру PersistentVolumeClaim.
Рекомендується увімкнути контролер допуску PersistentVolumeClaimResize. Цей контролер допуску запобігає зміні розміру всіх вимог за замовчуванням, якщо тільки StorageClass вимоги явно не дозволяє зміну розміру, встановлюючи allowVolumeExpansion на true.
Наприклад: всі PersistentVolumeClaim, створені з наступного StorageClass, підтримують розширення тому:
Для отримання додаткової інформації про persistent volume claims, дивіться PersistentVolumeClaims.
PersistentVolumeLabel
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.13 [deprecated]
Тип: Модифікуючий.
Цей контролер допуску автоматично додає мітки регіону або зони до PersistentVolumes як визначено постачальником хмарних послуг (наприклад, Azure або GCP). Він допомагає забезпечити, щоб Podʼи і PersistentVolumes, що монтуються, були в одному регіоні та/або зоні. Якщо контролер допуску не підтримує автоматичне додавання міток до ваших PersistentVolumes, вам може знадобитися додати мітки вручну, щоб запобігти монтуванню томів у Podʼи з іншої зони. PersistentVolumeLabel застарілий, оскільки позначення мітками для постіних томів було передано до cloud-controller-manager.
Цей контролер допуску стандартно вимкнено.
PodNodeSelector
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.5 [alpha]
Тип: Валідаційний.
Цей контролер допуску задає та обмежує, які селектори вузлів можуть використовуватися в межах namespace, шляхом читання анотації namespace та глобальної конфігурації.
Цей контролер допуску стандартно вимкнено.
Формат конфігураційного файлу
PodNodeSelector використовує конфігураційний файл для налаштування параметрів поведінки бекенду. Зверніть увагу, що формат конфігураційного файлу буде змінено на версійований файл у майбутньому випуску. Цей файл може бути у форматі json або yaml і має наступний формат:
Якщо Namespace має анотацію з ключем scheduler.alpha.kubernetes.io/node-selector, використовуйте її значення як селектор вузлів.
Якщо namespace не має такої анотації, використовуйте clusterDefaultNodeSelector, визначений у конфігураційному файлі втулка PodNodeSelector, як селектор вузлів.
Оцініть селектор вузлів Podʼа щодо селектора вузлів namespace на предмет конфліктів. Конфлікти призводять до відхилення.
Оцініть селектор вузлів Podʼа щодо дозволеного селектора, визначеного у конфігураційному файлі плагіну для конкретного namespace. Конфлікти призводять до відхилення.
Примітка:
PodNodeSelector дозволяє змусити Podʼи працювати на вузлах зі спеціальними мітками. Дивіться також втулок допуску PodTolerationRestriction, який дозволяє запобігти запуску Podʼів на вузлах зі спеціальними taintʼами.
PodSecurity
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.25 [stable]
Тип: Валідаційний.
Контролер допуску PodSecurity перевіряє нові Podʼи перед їх допуском і визначає, чи варто їх допускати на основі запитуваного контексту безпеки та обмежень щодо дозволених Стандартів безпеки для Podʼів для namespace, в якому буде знаходитися Pod.
PodSecurity замінив старіший контролер допуску під назвою PodSecurityPolicy.
PodTolerationRestriction
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.7 [alpha]
Тип: Модифікуючий та Валідаційний.
Контролер допуску PodTolerationRestriction перевіряє конфлікти між толерантностями Podʼа та толерантностями його namespace. Він відхиляє запит Podʼа у разі конфлікту. Потім він обʼєднує толерантності, анотовані на namespace, з толерантностями Podʼа. Отримані толерантності перевіряються щодо списку дозволених толерантностей, анотованих на namespace. Якщо перевірка пройде успішно, запит Podʼа допускається, інакше він відхиляється.
Якщо namespace Podʼа не має повʼязаних з ним стандартних толерантностей або дозволених толерантностей, анотованих, використовуються стандартні толерантності на рівні кластера або список дозволених толерантностей на рівні кластера, якщо вони зазначені.
Толерантності призначаються namespace за допомогою ключа анотації scheduler.alpha.kubernetes.io/defaultTolerations. Список дозволених толерантностей можна додати за допомогою ключа анотації scheduler.alpha.kubernetes.io/tolerationsWhitelist.
Контролер допуску Priority використовує поле priorityClassName і заповнює ціле значення пріоритету. Якщо клас пріоритету не знайдено, Pod відхиляється.
ResourceQuota
Тип: Валідаційний.
Цей контролер допуску спостерігає за вхідним запитом і гарантує, що він не порушує жодних обмежень, перерахованих у обʼєкті ResourceQuota у Namespace. Якщо ви використовуєте обʼєкти ResourceQuota у вашому розгортанні Kubernetes, ви МАЄТЕ використовувати цей контролер допуску для забезпечення дотримання квот.
Якщо ви визначаєте RuntimeClass з налаштованими накладними витратами, повʼязаними з роботою Podʼів, цей контролер допуску перевіряє вхідні Podʼи. При увімкненні, цей контролер допуску відхиляє будь-які запити на створення Podʼів, які вже мають встановлений overhead. Для Podʼів, які мають налаштований і обраний у своєму .spec RuntimeClass, цей контролер допуску встановлює .spec.overhead у Pod на основі значення, визначеного у відповідному RuntimeClass.
Цей контролер допуску реалізує автоматизацію для службових облікових записів. Проєкт Kubernetes наполегливо рекомендує увімкнути цей контролер допуску. Вам слід увімкнути цей контролер допуску, якщо ви маєте намір використовувати обʼєкти ServiceAccount в Kubernetes.
Щодо анотації kubernetes.io/enforce-mountable-secrets: Хоча назва анотації вказує, що вона стосується лише монтування Secrets, її застосування також поширюється на інші способи використання Secrets в контексті Pod. Тому важливо переконатися, що всі зазначені секрети правильно вказані в ServiceAccount.
StorageObjectInUseProtection
Тип: Модифікуючий.
Втулок StorageObjectInUseProtection додає завершувачі kubernetes.io/pvc-protection або kubernetes.io/pv-protection до новостворених Persistent Volume Claims (PVC) або Persistent Volumes (PV). У випадку видалення користувача PVC або PV PVC або PV не видаляється, поки завершувач не буде видалений з PVC або PV за допомогою контролера захисту PVC або PV.
Дивіться Захист обʼєктів зберігання які використовуються для отримання детальнішої інформації.
TaintNodesByCondition
Тип: Модифікуючий.
Цей контролер допуску додає taint до новостворених вузлів таких як NotReady та NoSchedule. Це позначення доволє уникнути стану перегонів, який може призвести до того, що Podʼи будуть заплановані на нових вузлах до того, як їх taint будуть оновлені для точної відповідності їх звітніх умов.
ValidatingAdmissionPolicy
Тип: Валідаційний.
Цей контролер допуску реалізує перевірку CEL для вхідних запитів, що збігаються. Він увімкнений, коли увімкнені як функціональна можливість validatingadmissionpolicy, так і група/версія admissionregistration.k8s.io/v1alpha1. Якщо будь-яка з політик ValidatingAdmissionPolicy не вдасться, запит не вдасться.
ValidatingAdmissionWebhook
Тип: Валідаційний.
Цей контролер допуску викликає будь-які валідуючі вебхуки, які відповідають запиту. Валідуючі вебхуки викликаються паралельно; якщо будь-який з них відхиляє запит, запит не вдається. Цей контролер допуску працює лише на етапі валідації; вебхуки, які він викликає, не можуть змінювати обʼєкт, на відміну від вебхуків, які викликаються контролером допуску MutatingAdmissionWebhook.
Якщо вебхук який викликається цим контролером, має побічні ефекти (наприклад, зменшення квоти), то обовʼязково має бути система реконсіляції, оскільки не гарантується, що подальші вебхуки або інші валідаційні контролери допуску дозволять закінчити запит.
Якщо ви вимкнете ValidatingAdmissionWebhook, вам також слід вимкнути обʼєкт ValidatingWebhookConfiguration у групі/версії admissionregistration.k8s.io/v1 за допомогою прапорця --runtime-config.
Чи існує рекомендований набір контролерів допуску для використання?
Так. Рекомендовані контролери допуску стандартно увімкнені (дивіться тут), тому вам не потрібно явно вказувати їх. Ви можете увімкнути додаткові контролери допуску поза стандартним набором за допомогою прапорця --enable-admission-plugins (порядок не має значення).
3.9 - Динамічне керування допуском
Окрім вбудованих втулків допуску, втулки допуску можуть бути розроблені як розширення і виконуватися як вебхуки, налаштовані під час роботи. Ця сторінка описує, як будувати, налаштовувати, використовувати та контролювати вебхуки допуску.
Що таке вебхуки допуску?
Вебхуки допуску — це зворотні виклики HTTP, які отримують запити на допуск та роблять з ними щось. Ви можете визначити два типи вебхуків допуску, валідаційний вебхук допуску та модифікуючий вебхук допуску. Модифікуючі вебхуки допуску викликаються першими та можуть змінювати обʼєкти, які надсилаються на сервер API, щоб застосовувати власні стандартні значення. Після завершення всіх модифікацій обʼєктів і після того, як вхідний обʼєкт перевірений сервером API, викликаються валідаційні вебхуки допуску та можуть відхиляти запити для застосування власних політик.
Примітка:
Вебхуки допуску, які потребують гарантії того, що вони бачать кінцевий стан обʼєкта, щоб застосувати політику, повинні використовувати валідаційний вебхук допуску, оскільки обʼєкти можуть бути змінені після того, як їх оглянули модифікуючі вебхуки.
Експерименти з вебхуками допуску
Вебхуки допуску фактично є частиною панелі управління кластера. Ви повинні писати та розгортати їх з великою обережністю. Будь ласка, прочитайте посібники користувача для інструкцій, якщо ви маєте намір писати/розгортати вебхуки допуску промислового рівня. Нижче ми описуємо, як швидко експериментувати з вебхуками допуску.
Передумови
Переконайтеся, що контролери допуску MutatingAdmissionWebhook та ValidatingAdmissionWebhook
увімкнені. Тут є рекомендований набір контролерів допуску для загального увімкнення.
Переконайтеся, що API admissionregistration.k8s.io/v1 увімкнено.
Написання сервера вебхуків допуску
Будь ласка, зверніться до реалізації сервера вебхуків допуску, який перевірено в е2е-тесті Kubernetes. Сервер вебхуків обробляє запити AdmissionReview, надіслані серверами API, і повертає своє рішення як обʼєкт AdmissionReview в тій же версії, що й отримав.
Дивіться розділ запиту вебхуку для деталей щодо даних, надісланих до вебхуків.
Дивіться розділ відповіді вебхуку для деталей щодо даних, які очікуються від вебхуків.
Приклад сервера вебхуків допуску залишає поле ClientAuthпорожнім, що типово дорівнює NoClientCert. Це означає, що сервер вебхуків не автентифікує ідентичність клієнтів, які, припускається, є серверами API. Якщо вам потрібен взаємний TLS або інші способи автентифікації клієнтів, дивіться як автентифікувати сервери API.
Розгортання служби вебхуків допуску
Сервер вебхуків у е2е-тесті розгортається в кластері Kubernetes за допомогою API deployment. Тест також створює службу як фронтенд сервера вебхуків. Дивіться код.
Ви також можете розгортати свої вебхуки поза кластером. Вам потрібно буде оновити відповідно ваші конфігурації вебхуків.
Приклад ValidatingWebhookConfiguration, конфігурація модифікуючого вебхуку подібна. Дивіться розділ конфігурації вебхуку для деталей про кожне поле конфігурації.
Ви повинні замінити <CA_BUNDLE> у вищезазначеному прикладі на дійсний пакунок CA це PEM-кодований (значення поля закодовано у Base64) пакунок CA для перевірки вебсервера сертифіката.
Поле scope вказує, чи тільки ресурси з області кластера ("Cluster") або з області простору імен ("Namespaced") будуть відповідати цьому правилу. "∗" означає, що обмежень області немає.
Примітка:
При використанні clientConfig.service, сертифікат сервера повинен бути дійсним для
<svc_name>.<svc_namespace>.svc.
Примітка:
Стандартний тайм-авт вебхуку — 10 секунд, ви можете встановити timeout, і рекомендується використовувати короткий тайм-авт для вебхуків. Якщо виклик вебхуку перевищує тайм-авт, запит обробляється відповідно до політики відмови вебхуку.
Коли сервер API отримує запит, що відповідає одному з rules, сервер API надсилає запит admissionReview до вебхуку, як зазначено в clientConfig.
Після створення конфігурації вебхуку, системі знадобиться кілька секунд, щоб визнати нову конфігурацію.
Автентифікація серверів API
Якщо вашим вебхукам для допуску потрібна автентифікація, ви можете налаштувати сервери API для використання базової автентифікації, токенів на предʼявника (bearer token) або сертифікатів для автентифікації себе у вебхуках. Налаштування складається з трьох кроків.
Під час запуску сервера API вкажіть розташування файлу конфігурації керування допуском за допомогою прапорця --admission-control-config-file.
У файлі конфігурації керування допуском вкажіть, де контролери MutatingAdmissionWebhook та ValidatingAdmissionWebhook повинні читати облікові дані. Облікові дані зберігаються у файлах kubeConfig (так, це та сама схема, що використовується kubectl), тому назва поля — kubeConfigFile. Ось приклад файлу конфігурації керування допуском:
# Застаріло у v1.17 на користь apiserver.config.k8s.io/v1apiVersion:apiserver.k8s.io/v1alpha1kind:AdmissionConfigurationplugins:- name:ValidatingAdmissionWebhookconfiguration:# Застаріло у v1.17 на користь apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfigurationapiVersion:apiserver.config.k8s.io/v1alpha1kind:WebhookAdmissionkubeConfigFile:"<path-to-kubeconfig-file>"- name:MutatingAdmissionWebhookconfiguration:# Застаріло у v1.17 на користь apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfigurationapiVersion:apiserver.config.k8s.io/v1alpha1kind:WebhookAdmissionkubeConfigFile:"<path-to-kubeconfig-file>"
apiVersion:v1kind:Configusers:# name повинно бути встановлено на DNS-імʼя служби або хост (включаючи порт) URL-адреси, з якою налаштовано взаємодію вебхуку.# Якщо для служб використовується порт, відмінний від 443, його необхідно включити до імені під час налаштування серверів API версії 1.16+.## Для вебхуку, налаштованого для взаємодії зі службою настандартному порті (443), вкажіть DNS-імʼя служби:# - name: webhook1.ns1.svc# user: ...## Для вебхуку, налаштованого для взаємодії зі службою на нестандартному порту (наприклад, 8443), вкажіть DNS-імʼя та порт служби у версії 1.16+:# - name: webhook1.ns1.svc:8443# user: ...# і, за бажанням, створіть другу секцію, використовуючи лише DNS-імʼя служби для сумісності з серверами API версії 1.15:# - name: webhook1.ns1.svc# user: ...## Для вебхуків, налаштованих для взаємодії з URL-адресою, вкажіть хост (і порт), вказані в URL-адресі вебхуку. Приклади:# Вебхук з `url: https://www.example.com`:# - name: www.example.com# user: ...## Вебхук з `url: https://www.example.com:443`:# - name: www.example.com:443# user: ...## Вебхук з `url: https://www.example.com:8443`:# - name: www.example.com:8443# user: ...#- name:'webhook1.ns1.svc'user:client-certificate-data:"<pem encoded certificate>"client-key-data:"<pem encoded key>"# Поле `name` підтримує використання * для підстановки сегментів префікса.- name:'*.webhook-company.org'user:password:"<password>"username:"<name>"# '*' є стандартним збігом.- name:'*'user:token:"<token>"
Звичайно, вам потрібно налаштувати сервер вебхуків для обробки цих запитів на автентифікацію.
Запит і відповідь вебхука
Запит
Вебхуки надсилаються як POST-запити з Content-Type: application/json, з об’єктом API AdmissionReview в API-групі admission.k8s.io, серіалізованим у JSON як тіло запиту.
Вебхуки можуть вказувати, які версії об’єктів AdmissionReview вони приймають, використовуючи поле admissionReviewVersions у своїй конфігурації:
admissionReviewVersions є обов’язковим полем при створенні конфігурацій вебхуків. Вебхуки повинні підтримувати принаймні одну версію AdmissionReview, яка зрозуміла поточному та попередньому API-серверу.
API-сервери надсилають першу версію AdmissionReview зі списку admissionReviewVersions, яку вони підтримують. Якщо жодна з версій у списку не підтримується API-сервером, створення конфігурації не буде дозволено. Якщо API-сервер виявляє конфігурацію вебхука, яка була створена раніше і не підтримує жодної з версій AdmissionReview, які API-сервер може надсилати, спроби виклику вебхука будуть невдалими та підлягатимуть політиці відмови.
Цей приклад показує дані, що містяться в об’єкті AdmissionReview для запиту на оновлення субресурсу scale для Deployment з групи apps/v1:
apiVersion:admission.k8s.io/v1kind:AdmissionReviewrequest:# Випадковий uid, що унікально ідентифікує цей виклик підтвердженняuid:705ab4f5-6393-11e8-b7cc-42010a800002# Повністю кваліфікована група/версія/тип вхідного об’єктаkind:group:autoscalingversion:v1kind:Scale# Повністю кваліфікована група/версія/тип ресурсу, що змінюєтьсяresource:group:appsversion:v1resource:deployments# субресурс, якщо запит стосується субресурсуsubResource:scale# Повністю кваліфікована група/версія/тип вхідного об’єкта в початковому запиті до API-сервера.# Це відрізняється від `kind`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.requestKind:group:autoscalingversion:v1kind:Scale# Повністю кваліфікована група/версія/тип ресурсу, що змінюється в початковому запиті до API-сервера.# Це відрізняється від `resource`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.requestResource:group:appsversion:v1resource:deployments# субресурс, якщо запит стосується субресурсу# Це відрізняється від `subResource`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.requestSubResource:scale# Ім’я ресурсу, що змінюєтьсяname:my-deployment# Простір імен ресурсу, що змінюється, якщо ресурс має простір імен (або є об’єктом Namespace)namespace:my-namespace# операція може бути CREATE, UPDATE, DELETE або CONNECToperation:UPDATEuserInfo:# Ім’я користувача автентифікованого користувача, що робить запит до API-сервераusername:admin# UID автентифікованого користувача, що робить запит до API-сервераuid:014fbff9a07c# Групові членства автентифікованого користувача, що робить запит до API-сервераgroups:- system:authenticated- my-admin-group# Додаткова довільна інформація, пов’язана з користувачем, що робить запит до API-сервера.# Це заповнюється шаром автентифікації API-сервера і повинно бути включено,# якщо будь-які перевірки SubjectAccessReview виконуються вебхуком.extra:some-key:- some-value1- some-value2# object є новим об’єктом, що підлягає допуску.# Це null для операцій DELETE.object:apiVersion:autoscaling/v1kind:Scale# oldObject є існуючим об’єктом.# Це null для операцій CREATE та CONNECT.oldObject:apiVersion:autoscaling/v1kind:Scale# options містить параметри операції, що підлягає допуску, як-от meta.k8s.io/v1 CreateOptions, UpdateOptions або DeleteOptions.# Це null для операцій CONNECT.options:apiVersion:meta.k8s.io/v1kind:UpdateOptions# dryRun вказує, що API-запит виконується в режимі dry run і не буде збережений.# Вебхуки з побічними ефектами повинні уникати здійснення цих побічних ефектів, коли dryRun дорівнює true.# Див. http://k8s.io/docs/reference/using-api/api-concepts/#make-a-dry-run-request для додаткової інформації.dryRun:False
Відповідь
Вебхуки відповідають зі статус-кодом HTTP 200, Content-Type: application/json та тілом, що містить об’єкт AdmissionReview (у тій же версії, що була надіслана), з заповненою секцією response, серіалізованою у JSON.
Мінімум, секція response повинна містити такі поля:
uid, скопійований з request.uid, що був надісланий до вебхука
allowed, встановлений або в true, або в false
Приклад мінімальної відповіді від вебхука для дозволу запиту:
При відхиленні запиту вебхук може налаштувати HTTP-код та повідомлення, яке повертається користувачеві, використовуючи поле status. Вказаний об’єкт статусу повертається користувачеві. Див. Довідник API для деталей про тип status. Приклад відповіді для заборони запиту з налаштуванням HTTP-коду та повідомлення, яке буде представлено користувачеві:
{
"apiVersion": "admission.k8s.io/v1",
"kind": "AdmissionReview",
"response": {
"uid": "<значення з request.uid>",
"allowed": false,
"status": {
"code": 403,
"message": "Ви не можете це зробити, тому що сьогодні вівторок і ваше ім’я починається з літери А" }
}
}
При дозволі запиту, модифікуючий вебхук допуску може за бажанням модифікувати вхідний об’єкт. Це робиться за допомогою полів patch та patchType у відповіді. Єдиний підтримуваний тип patchType наразі — JSONPatch. Див. документацію JSON patch для додаткової інформації. Для patchType: JSONPatch, поле patch містить base64-кодований масив операцій JSON patch.
Як приклад, єдина операція patch, яка встановить spec.replicas, виглядає так: [{"op": "add", "path": "/spec/replicas", "value": 3}]
Base64-кодована, вона виглядатиме так: W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=
Отже, відповідь вебхука для додавання цієї мітки буде такою:
Вебхуки допуску можуть за бажанням повертати попереджувальні повідомлення, які повертаються клієнту, що зробив запит, у HTTP-заголовках Warning з кодом попередження 299. Попередження можуть бути надіслані з дозволеними або відхиленими відповідями на допуск.
Якщо ви реалізуєте вебхук, що повертає попередження:
Не включайте префікс "Warning:" у повідомлення
Використовуйте попереджувальні повідомлення для опису проблем, які клієнт, що робить API-запит, має виправити або про які має знати
За можливості, обмежуйте попередження до 120 символів
Увага:
Індивідуальні попереджувальні повідомлення довжиною понад 256 символів можуть бути скорочені API-сервером перед поверненням клієнтам. Якщо додано більше 4096 символів попереджувальних повідомлень (від усіх джерел), додаткові попередження ігноруються.
{
"apiVersion": "admission.k8s.io/v1",
"kind": "AdmissionReview",
"response": {
"uid": "<значення з request.uid>",
"allowed": true,
"warnings": [
"зазначено дублюючі записи envvar з іменем MY_ENV",
"запит на пам’ять менший за 4 МБ зазначено для контейнера mycontainer, який не запуститься успішно" ]
}
}
Конфігурація вебхука
Для реєстрації вебхуків допуску створіть об’єкти API MutatingWebhookConfiguration або ValidatingWebhookConfiguration. Назва об’єкта MutatingWebhookConfiguration або ValidatingWebhookConfiguration має бути дійсним DNS-імʼям субдомену.
Кожна конфігурація може містити один або кілька вебхуків. Якщо в одній конфігурації вказано кілька вебхуків, кожен з них повинен мати унікальну назву. Це необхідно для полегшення відповідності логів аудиту та метрик активних конфігурацій.
Кожен вебхук визначає наступні параметри.
Відповідність запитів: правила
Кожен вебхук має вказувати список правил, що використовуються для визначення, чи повинен запит до API-сервера бути надісланий до вебхука. Кожне правило вказує одну або кілька операцій, груп API, версій API та ресурсів, а також область ресурсу:
operations отримує перелік з однієї або кількох операцій для порівняння. Можливі значення: "CREATE", "UPDATE", "DELETE", "CONNECT" або "*" для збігу зі всіма операціям.
apiGroups отримує перелік з однієї або кількох груп API для порівняння. "" означає ядро групи API. "*" відповідає всім групам API.
apiVersions отримує перелік з однієї або кількох версій API для порівняння. "*" відповідає всім версіям API.
resources отримує перелік з одного або кількох ресурсів для порівняння.
"*" відповідає всім ресурсам, але не субресурсам.
"*/*" відповідає всім ресурсам і субресурсам.
"pods/*" відповідає всім субресурсам Podʼів.
"*/status" відповідає всім субресурсам статусу.
scope вказує область для порівняння. Допустимі значення: "Cluster", "Namespaced" та "*". Субресурси відповідають області їх батьківського ресурсу. Стандартно "*".
"Cluster" означає, що тільки ресурси з кластерною областю відповідатимуть цьому правилу (об’єкти Namespace мають кластерну область).
"Namespaced" означає, що тільки ресурси з простору імен відповідатимуть цьому правилу.
"*" означає, що немає обмежень щодо області.
Якщо вхідний запит відповідає одному з: operations, apiGroups, apiVersions, resources та scope для будь-якого з правил вебхука, запит надсилається до вебхука.
Ось інші приклади правил, які можуть бути використані для визначення, які ресурси слід перехоплювати.
Відповідність запитам CREATE або UPDATE до apps/v1 та apps/v1beta1deployments і replicasets:
Вебхуки можуть за бажанням обмежувати, які запити перехоплюються, на основі міток обʼєктів, до яких вони будуть надіслані, вказуючи objectSelector. Якщо вказано, objectSelector оцінюється як для обʼєкта, так і для старого обʼєкта, які будуть надіслані до вебхука, і вважається відповідним, якщо будь-який з обʼєктів відповідає селектору.
Обʼєкт, що дорівнює null (oldObject у випадку створення або newObject у випадку видалення), або обʼєкт, який не може мати міток (наприклад, обʼєкт DeploymentRollback або PodProxyOptions), не вважається відповідним.
Використовуйте селектор обʼєктів тільки якщо вебхук є опціональним, тому що кінцеві користувачі можуть обійти вебхук допуску, встановлюючи мітки.
Цей приклад показує модифікуючий вебхук, який відповідатиме CREATE для будь-якого ресурсу (але не субресурсів) з міткою foo: bar:
Див. концепцію міток для більшої кількості прикладів селекторів міток.
Відповідність запитів: namespaceSelector
Вебхуки можуть за бажанням обмежувати, які запити на ресурси в межах простору імен перехоплюються, на основі міток простору імен, до якого вони належать, вказуючи namespaceSelector.
namespaceSelector вирішує, чи слід запускати вебхук для запиту на ресурс у межах простору імен (або обʼєкт Namespace), на основі того, чи відповідають мітки простору імен селектору. Якщо обʼєкт сам є простором імен, відповідність виконується за object.metadata.labels. Якщо обʼєкт є кластерним ресурсом, відмінним від Namespace, namespaceSelector не впливає.
Цей приклад показує модифікуючий вебхук, який відповідає CREATE для будь-якого ресурсу в межах простору імен, який не має мітки "runlevel" зі значенням "0" або "1":
Цей приклад показує валідаційний вебхук, який відповідає CREATE для будь-якого ресурсу в межах простору імен, асоційованого з "environment" зі значенням "prod" або "staging":
Див. концепцію міток для більшої кількості прикладів селекторів міток.
Відповідність запитів: matchPolicy
API сервери можуть робити обʼєкти доступними через кілька API груп або версій.
Наприклад, якщо вебхук визначає правило для певних API груп/версій (наприклад, apiGroups:["apps"], apiVersions:["v1","v1beta1"]), і запит робиться для зміни ресурсу через іншу API групу/версію (наприклад, extensions/v1beta1), запит не буде надіслано до вебхука.
matchPolicy дозволяє вебхуку визначити, як його rules використовуються для відповідності вхідним запитам. Допустимі значення — Exact або Equivalent.
Exact означає, що запит повинен бути перехоплений тільки в тому випадку, якщо він точно відповідає зазначеному правилу.
Equivalent означає, що запит повинен бути перехоплений, якщо він модифікує ресурс, зазначений в rules, навіть через іншу API групу або версію.
У наведеному вище прикладі, вебхук, зареєстрований тільки для apps/v1, може використовувати matchPolicy:
matchPolicy: Exact означає, що запит extensions/v1beta1 не буде надіслано до вебхука.
matchPolicy: Equivalent означає, що запит extensions/v1beta1 буде надіслано до вебхука (з обʼєктами, конвертованими до версії, яку вебхук визначив: apps/v1).
Вказування Equivalent рекомендовано і забезпечує, що вебхуки продовжують перехоплювати очікувані ресурси, коли оновлення включають нові версії ресурсу в API сервері.
Коли ресурс перестає обслуговуватись API сервером, він більше не вважається еквівалентним іншим версіям цього ресурсу, які все ще обслуговуються. Наприклад, extensions/v1beta1 розгортання були спочатку визнані застарілими, а потім видалені (у Kubernetes v1.16).
З моменту цього видалення, вебхук з правилом apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"] не перехоплює розгортання, створені через API apps/v1. З цієї причини, вебхуки повинні віддавати перевагу реєстрації для стабільних версій ресурсів.
Цей приклад показує валідаційний вебхук, який перехоплює модифікації розгортань (незалежно від API групи або версії) і завжди отримує обʼєкт Deployment версії apps/v1:
matchPolicy для вебхуків допуску за замовчуванням дорівнює Equivalent.
Відповідність запитів: matchConditions
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.30 [stable]
Ви можете визначити умови відповідності для вебхуків, якщо вам потрібна точніша фільтрація запитів. Ці умови корисні, якщо правила відповідності, objectSelectors та namespaceSelectors не надають необхідної фільтрації при викликах по HTTP. Умови відповідності є CEL виразами. Всі умови відповідності повинні оцінюватися як true для виклику вебхука.
Ось приклад, що ілюструє декілька різних способів використання умов відповідності:
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingWebhookConfigurationwebhooks:- name:my-webhook.example.commatchPolicy:Equivalentrules:- operations:['CREATE','UPDATE']apiGroups:['*']apiVersions:['*']resources:['*']failurePolicy:'Ignore'# Fail-open (опційно)sideEffects:NoneclientConfig:service:namespace:my-namespacename:my-webhookcaBundle:'<omitted>'# Ви можете мати до 64 умов відповідності на вебхукmatchConditions:- name:'exclude-leases'# Кожна умова відповідності повинна мати унікальне імʼяexpression:'!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")'# Відповідність ресурсам, які не є lease.- name:'exclude-kubelet-requests'expression:'!("system:nodes" in request.userInfo.groups)'# Відповідність запитам, зробленим не користувачами вузлів.- name:'rbac'# Пропуск запитів RBAC, які обробляються другим вебхуком.expression:'request.resource.group != "rbac.authorization.k8s.io"'# Цей приклад ілюструє використання 'authorizer'. Перевірка авторизації дорожча за простий вираз, тому в цьому прикладі вона обмежена лише запитами RBAC, використовуючи другий вебхук. Обидва вебхуки можуть обслуговуватись одним кінцевим пунктом.- name:rbac.my-webhook.example.commatchPolicy:Equivalentrules:- operations:['CREATE','UPDATE']apiGroups:['rbac.authorization.k8s.io']apiVersions:['*']resources:['*']failurePolicy:'Fail'# Fail-closed (стандартно)sideEffects:NoneclientConfig:service:namespace:my-namespacename:my-webhookcaBundle:'<omitted>'# Ви можете мати до 64 умов відповідності на вебхукmatchConditions:- name:'breakglass'# Пропуск запитів, зроблених користувачами, авторизованими для 'breakglass' на цьому вебхуку.# Дієслово API 'breakglass' не повинно існувати за межами цієї перевірки.expression:'!authorizer.group("admissionregistration.k8s.io").resource("validatingwebhookconfigurations").name("my-webhook.example.com").check("breakglass").allowed()'
Примітка:
Ви можете визначити до 64 елементів у полі matchConditions для кожного вебхука.
Умови відповідності мають доступ до наступних CEL змінних:
object — Обʼєкт з вхідного запиту. Значення є null для DELETE запитів. Версія обʼєкта може бути конвертована на основі matchPolicy.
oldObject — Наявний обʼєкт. Значення є null для CREATE запитів.
request — Частина запиту AdmissionReview, виключаючи object та oldObject.
authorizer — CEL Authorizer. Може використовуватись для виконання перевірок авторизації для головного облікового запису (автентифікованого користувача) запиту. Дивіться Authz у документації бібліотеки Kubernetes CEL для додаткової інформації.
authorizer.requestResource — Скорочення для перевірки авторизації, налаштованої на ресурс запиту (група, ресурс, (підресурс), простір імен, імʼя).
Коли сервер API визначає, що запит повинен бути надісланий до вебхука, йому потрібно знати, як звʼязатися з вебхуком. Це визначається в розділі clientConfig конфігурації вебхука.
Вебхуки можуть викликатися через URL або посилання на сервіс, і можуть за бажанням включати власний набір CA для використання для перевірки TLS-зʼєднання.
URL
Поле url вказує місцезнаходження вебхука у стандартній формі URL (scheme://host:port/path).
Поле host не повинно вказувати на сервіс, що працює в кластері; використовуйте посилання на сервіс, вказуючи поле service. Хост може бути вирішений через зовнішній DNS на деяких серверах API (наприклад, kube-apiserver не може вирішувати DNS всередині кластера, оскільки це буде порушенням шарів). host також може бути IP-адресою.
Зверніть увагу, що використання localhost або 127.0.0.1 як host є ризикованим, якщо ви не забезпечите запуск цього вебхука на всіх хостах, які запускають сервер API, який може потребувати викликів до цього вебхука. Такі інсталяції, ймовірно, будуть непереносними або не будуть легко запускатися в новому кластері.
Схема повинна бути "https"; URL повинен починатися з "https://".
Спроба використання користувача або базової автентифікації (наприклад, user:password@) не дозволена. Фрагменти (#...) та параметри запиту (?...) також не дозволені.
Ось приклад конфігурації модифікуючого вебхука для виклику URL (і очікується, що TLS-сертифікат буде перевірено за допомогою системних коренів довіри, тому не вказується caBundle):
Розділ service всередині clientConfig є посиланням на сервіс для цього вебхука. Якщо вебхук працює всередині кластера, вам слід використовувати service замість url. Необхідно вказати простір імен та імʼя сервісу. Порт є необовʼязковим і стандартно дорівнює 443. Шлях є необовʼязковим і стандартно дорівнює "/".
Ось приклад конфігурації модифікуючого вебхука для виклику сервісу на порту "1234" за підшляхом "/my-path", і для перевірки TLS-зʼєднання проти ServerName my-service-name.my-service-namespace.svc з використанням власного набору CA:
Ви повинні замінити <CA_BUNDLE> у наведеному вище прикладі на дійсний набір CA, який є PEM-кодованим набором CA для перевірки сертифіката сервера вебхука.
Побічні ефекти
Вебхуки зазвичай працюють тільки з вмістом AdmissionReview, надісланого їм. Однак деякі вебхуки здійснюють зміни поза межами під час обробки запитів на допуск.
Вебхуки, які здійснюють зміни поза межами ("побічні ефекти"), повинні також мати механізм узгодження (наприклад, контролер), який періодично визначає фактичний стан системи та коригує дані поза межами, змінені вебхуком допуску, щоб відобразити реальність. Це тому, що виклик до вебхука допуску не гарантує, що прийнятий обʼєкт буде збережений таким, яким він є, або взагалі. Пізніші вебхуки можуть змінити вміст обʼєкта, може виникнути конфлікт під час запису в сховище, або сервер може вимкнутися до збереження обʼєкта.
Крім того, вебхуки з побічними ефектами повинні пропускати ці побічні ефекти, коли обробляються запити допуску з dryRun: true. Вебхук повинен явно вказати, що він не матиме побічних ефектів при запуску з dryRun, інакше запит dry-run не буде надіслано до вебхука, і API-запит замість цього не вдасться.
Вебхуки вказують, чи мають вони побічні ефекти, за допомогою поля sideEffects у конфігурації вебхука:
None: виклик вебхука не матиме побічних ефектів.
NoneOnDryRun: виклик вебхука може мати побічні ефекти, але якщо до вебхука надіслано запит з dryRun: true, вебхук придушить побічні ефекти (вебхук враховує dryRun).
Ось приклад конфігурації вебхука перевірки, який вказує, що він не має побічних ефектів при запитах з dryRun: true:
Оскільки вебхуки додають затримку до запитів API, вони повинні оцінюватися якомога швидше. timeoutSeconds дозволяє налаштувати, скільки часу сервер API повинен чекати на відповідь вебхука, перш ніж розглядати виклик як невдалий.
Якщо тайм-аут закінчується до того, як вебхук відповість, виклик вебхука буде проігноровано або API-запит буде відхилено відповідно до політики помилок.
Значення тайм-ауту повинно бути між 1 і 30 секунд.
Ось приклад конфігурації вебхука перевірки з кастомним тайм-аутом у 2 секунди:
Тайм-аут для вебхука допуску стандартно становить 10 секунд.
Політика повторного виклику
Одне впорядкування втулків модифікуючого допуску (включаючи вебхуки) не підходить для всіх випадків (див. приклад у https://issue.k8s.io/64333). Модифікуючий вебхук може додати нову підструктуру до обʼєкта (наприклад, додати container до pod), а інші модифікуючи втулки, які вже виконані, можуть мати вплив на ці нові структури (наприклад, встановити imagePullPolicy для всіх контейнерів).
Щоб дозволити втулкам модифікуючого допуску спостерігати за змінами, внесеними іншими втулками, вбудовані модифікуючи втулки допуску повторно запускаються, якщо модифікуючий вебхук змінює обʼєкт, і модифікуючи вебхуки можуть вказати reinvocationPolicy для контролю того, чи будуть вони повторно викликані.
reinvocationPolicy може бути встановлено на Never або IfNeeded. Стандартно встановлено у Never.
Never: вебхук не повинен викликатися більше одного разу в рамках однієї оцінки допуску.
IfNeeded: вебхук може бути викликаний знову в рамках оцінки допуску, якщо обʼєкт, що авторизується, змінюється іншими втулками допуску після початкового виклику вебхука.
Важливі моменти, на які слід звернути увагу:
Кількість додаткових викликів не гарантується як точно одна.
Якщо додаткові виклики призводять до подальших змін обʼєкта, не гарантується, що вебхуки будуть викликані знов.
Вебхуки, які використовують цей параметр, можуть бути переупорядковані для мінімізації кількості додаткових викликів.
Щоб перевірити обʼєкт після того, як всі модифікації гарантовано завершені, використовуйте вебхук допуску (рекомендується для вебхуків з побічними ефектами).
Ось приклад конфігурації модифікуючого вебхука, який вибирає повторний виклик, якщо пізніші втулки допуску змінюють обʼєкт:
Модифікуючи вебхуки повинні бути ідемпотентними, здатними успішно обробити обʼєкт, який вони вже авторизували і потенційно змінили. Це стосується всіх модифікуючих вебхуків допуску, оскільки будь-яка зміна, яку вони можуть внести в обʼєкт, вже могла існувати в обʼєкті, наданому користувачем, але це є особливо важливим для вебхуків, які вибирають повторний виклик.
Політика обробки помилок
failurePolicy визначає, як обробляються невизнані помилки та помилки тайм-ауту від вебхука допуску. Допустимі значення: Ignore або Fail.
Ignore означає, що помилка при виклику вебхука ігнорується, і запит API дозволяється продовжити.
Fail означає, що помилка при виклику вебхука призводить до невдачі допуску та відхилення запиту API.
Ось приклад конфігурації модифікуючого вебхука, налаштованого на відхилення запиту API, якщо виникають помилки під час виклику вебхука допуску:
Стандартна політика обробки помилок failurePolicy для вебхуків допуску Fail.
Моніторинг вебхуків авторизації
Сервер API надає способи моніторингу поведінки вебхуків допуску. Ці механізми моніторингу допомагають адміністраторам кластерів відповісти на запитання, як:
Який модифікуючий вебхук змінив обʼєкт у запиті API?
Яку зміну модифікуючий вебхук застосував до обʼєкта?
Які вебхуки часто відхиляють запити API? Яка причина відхилення?
Анотації аудиту модифікуючих вебхуків
Іноді корисно знати, який модифікуючий вебхук змінив обʼєкт у запиті API, і яку зміну вебхук застосував.
Сервер API Kubernetes виконує аудит кожного виклику модифікуючого вебхука. Кожен виклик генерує анотацію аудиту, яка відображає, чи був обʼєкт запиту змінений викликом, і, за необхідності, генерує анотацію із застосованим патчем з відповіді вебхука допуску. Анотації встановлюються в подію аудиту для даного запиту на даній стадії його виконання, яка потім попередньо обробляється відповідно до певної політики та записується в бекенд.
Рівень аудиту події визначає, які анотації будуть записані:
На рівні аудиту Metadata або вище записується анотація з ключем mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx} з JSON-наватаженням, яке вказує, що вебхук був викликаний для даного запиту і чи змінив він обʼєкт чи ні.
Наприклад, наступна анотація записується для вебхука, який повторно викликається. Вебхук є третім у ланцюгу модифікуючих вебхуків і не змінив обʼєкт запиту під час виклику.
# записана подія аудиту{"kind": "Event","apiVersion": "audit.k8s.io/v1","annotations": {"mutation.webhook.admission.k8s.io/round_1_index_2": "{\"configuration\":\"my-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook.example.com\",\"mutated\": false}"# інші анотації...}# інші поля...}
# десеріалізоване значення анотації{"configuration": "my-mutating-webhook-configuration.example.com","webhook": "my-webhook.example.com","mutated": false}
Наступна анотація записується для вебхука, який викликається на першій стадії. Вебхук є першим у ланцюгу модифікуючих вебхуків і змінив обʼєкт запиту під час виклику.
# записана подія аудиту{"kind": "Event","apiVersion": "audit.k8s.io/v1","annotations": {"mutation.webhook.admission.k8s.io/round_0_index_0": "{\"configuration\":\"my-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook-always-mutate.example.com\",\"mutated\": true}"# інші анотації...}# інші поля...}
# десеріалізоване значення анотації{"configuration": "my-mutating-webhook-configuration.example.com","webhook": "my-webhook-always-mutate.example.com","mutated": true}
На рівні аудиту Request або вище записується анотація з ключем patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx} з JSON-навантаженням, яке вказує, що вебхук був викликаний для даного запиту і який патч був застосований до обʼєкта запиту.
Наприклад, наступна анотація записується для вебхука, який повторно викликається. Вебхук є четвертим у ланцюгу модифікуючих вебхуків і відповів JSON-патчем, який був застосований до обʼєкта запиту.
# записана подія аудиту{"kind": "Event","apiVersion": "audit.k8s.io/v1","annotations": {"patch.webhook.admission.k8s.io/round_1_index_3": "{\"configuration\":\"my-other-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook-always-mutate.example.com\",\"patch\":[{\"op\":\"add\",\"path\":\"/data/mutation-stage\",\"value\":\"yes\"}],\"patchType\":\"JSONPatch\"}"# інші анотації...}# інші поля...}
Сервер API надає метрики Prometheus з точки доступу /metrics, які можна використовувати для моніторингу та діагностики стану сервера API. Наведені нижче метрики фіксують стан, повʼязаний з вебхуками допуску.
Лічильник відхилення запитів вебхука допуску сервера API
Іноді корисно знати, які вебхуки допуску часто відхиляють запити API, та причину відхилення.
Сервер API надає метрику лічильника Prometheus, яка фіксує відхилення вебхуків допуску. Метрики мають підписи, що ідентифікують причини відхилення запитів вебхуками:
name: назва вебхука, який відхилив запит.
operation: тип операції запиту, може бути одним із CREATE, UPDATE, DELETE та CONNECT.
type: тип вебхука допуску, може бути одним із admit та validating.
error_type: визначає, чи сталася помилка під час виклику вебхука, яка призвела до відхилення. Його значення може бути одним із:
calling_webhook_error: невизнані помилки або помилки тайм-ауту від вебхука допуску сталися, і політика помилки вебхука встановлена на Fail.
no_error: помилка не сталася. Вебхук відхилив запит з allowed: false у відповіді допуску. Підписи метрики rejection_code записують значення .status.code, встановлене в відповіді допуску.
apiserver_internal_error: сталася внутрішня помилка сервера API.
rejection_code: HTTP-код статусу, встановлений у відповіді допуску, коли вебхук відхилив запит.
Приклад метрик лічильника відхилення:
# HELP apiserver_admission_webhook_rejection_count [ALPHA] Лічильник відхилення вебхуків авторизації, ідентифікований за назвою та розділений для кожного типу авторизації (валідація чи допуск) та операції. Додаткові підписи вказують тип помилки (calling_webhook_error або apiserver_internal_error, якщо виникла помилка; no_error інакше) та, за потреби, ненульовий код відхилення, якщо вебхук відхилив запит із HTTP-кодом статусу (врахований сервером API, якщо код більший або рівний 400). Коди, більші за 600, обрізаються до 600, щоб обмежити кардинальність метрик.
# TYPE apiserver_admission_webhook_rejection_count counter
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="always-timeout-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="invalid-admission-response-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="no_error",name="deny-unwanted-configmap-data.example.com",operation="CREATE",rejection_code="400",type="validating"} 13
Найкращі практики та попередження
Ідемпотентність
Ідемпотентний вебхук допуску, що змінює дані, може успішно обробляти обʼєкт, який він вже допустив і, можливо, змінив. Допуск можна застосовувати кілька разів, не змінюючи результат поза початковою обробкою.
Для запиту CREATE Pod додається sidecar контейнер з імʼям foo-sidecar, суфіксований поточним часовим позначенням (наприклад, foo-sidecar-19700101-000000).
Для CREATE/UPDATE Pod відхиляються запити, якщо позначка "env" установлена, в іншому випадку додається позначка "env": "prod".
Для запиту CREATE Pod додається контейнер під назвою foo-sidecar без перевірки наявності контейнера foo-sidecar у специфікації Pod.
У першому випадку вебхук може додавати однаковий контейнер декілька разів до Pod, кожного разу з різним іменем контейнера. Аналогічно, вебхук може додавати дубльовані контейнери, якщо вони вже існують у Podʼах користувачів.
У другому випадку повторний виклик вебхука призведе до помилки вихідних даних вебхука.
У третьому випадку повторний виклик вебхука призведе до дублювання контейнерів у специфікації Pod, що робить запит недійсним та відхиленим сервером API.
Перехоплення всіх версій обʼєкта
Рекомендується, щоб вебхуки допуску завжди перехоплювали всі версії обʼєкта, встановлюючи .webhooks[].matchPolicy на Equivalent. Також рекомендується, щоб вебхуки допуску завжди реєструвалися для стабільних версій ресурсів. Невдала спроба перехопити всі версії обʼєкта може призвести до того, що політика допуску не буде застосовуватися до деяких версій запитів. Дивіться Відповідність запитів: matchPolicy для прикладів.
Доступність
Рекомендується, щоб вебхуки допуску оцінювалися якомога швидше (зазвичай за мілісекунди), оскільки вони збільшують затримку запиту API. Рекомендується використовувати невеликий таймаут для вебхуків. Дивіться Таймаути для докладнішої інформації.
Рекомендується, щоб вебхуки допуску використовували якусь форму балансування навантаження, щоб забезпечити високу доступність та вигоди в продуктивності. Якщо вебхук працює всередині кластера, ви можете запустити декілька вебхуків позаду служби, щоб скористатися балансуванням навантаження, яке підтримує ця служба.
Гарантування остаточного стану обʼєкта
Вебхуки допуску, які повинні гарантувати, що вони бачать остаточний стан обʼєкта, щоб застосовувати політику, повинні використовувати вебхук допуску для валідації, оскільки обʼєкти можуть бути змінені після перегляду модифікуючими вебхуками.
Наприклад, модифікуючий вебхук допуску налаштований на впровадження контейнера sidecar з імʼям "foo-sidecar" на кожний запит CREATE pod. Якщо необхідно, щоб контейнер був присутнім, також слід налаштувати вебхук допуску для перехоплення запитів CREATE pod, і перевірити, що контейнер з імʼям "foo-sidecar" з необхідною конфігурацією існує в обʼєкті, який має бути створений.
Уникнення блокування вебхуків у самостійно розміщених вебхуках
Вебхук, що працює всередині кластера, може призвести до блокування власного deployment, якщо він налаштований для перехоплення ресурсів, необхідних для запуску власних Podʼів.
Наприклад, модифікуючий вебхук допуску налаштований на допуск запитів на створення CREATE pod лише в тому випадку, якщо у pod встановлено певну мітку (наприклад, "env": "prod"). Сервер розгортання вебхука працює в deployment, яке не встановлює мітку "env". Коли вузол, на якому запущено Podʼи вебхука, стає непрацездатним, deployment вебхука спробує перепланувати Podʼи на інший вузол. Однак запити будуть відхилені існуючим сервером вебхука, оскільки мітка "env" не встановлена, і міграція не може відбутися.
Рекомендується виключати простір імен, де працює ваш вебхук, за допомогою namespaceSelector.
Побічні ефекти
Рекомендується, щоб вебхуки допуску уникати побічних ефектів, якщо це можливо, що означає, що вебхуки працюють тільки з вмістом AdmissionReview, надісланим до них, і не вносять зміни поза цими рамками. Поле .webhooks[].sideEffects має бути встановлене на None, якщо у вебхука немає жодних побічних ефектів.
Якщо побічні ефекти потрібні під час оцінки допуску, їх потрібно приглушити при обробці обʼєкта AdmissionReview з dryRun встановленим на true, і поле .webhooks[].sideEffects має бути встановлене на NoneOnDryRun. Дивіться Побічні ефекти для докладнішої інформації.
Уникнення операцій у просторі імен kube-system
Простір імен kube-system містить обʼєкти, створені компонентами панелі управління Kubernetes, наприклад, службові облікові записи для компонентів панелі управління, Podʼи такі як kube-dns. Ненавмисна зміна або відхилення запитів у просторі імен kube-system може призвести до того, що компоненти панелі управління перестануть працювати або будуть внесені невідомі зміни. Якщо ваші вебхуки допуску не мають на меті змінювати поведінку панелі управління Kubernetes, виключіть простір імен kube-system з перехоплення за допомогою namespaceSelector.
3.10 - Управління службовими обліковими записами
Службовий обліковий запис (ServiceAccount) надає ідентифікацію для процесів, що виконуються в Pod.
Процес всередині Pod може використовувати ідентифікацію свого повʼязаного службового облікового запису для автентифікації у API сервері кластера.
Цей посібник пояснює деякі концепції, повʼязані зі ServiceAccount. Також у посібнику розглядається, як отримати або відкликати токени, що представляють ServiceAccounts.
Перш ніж ви розпочнете
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Щоб точно виконати ці кроки, переконайтеся, що у вас є простір імен під назвою examplens. Якщо ні, створіть його, виконавши команду:
kubectl create namespace examplens
Облікові записи користувачів та службові облікові записи
Kubernetes розрізняє поняття облікового запису користувача та службового облікового запису з кількох причин:
Облікові записи користувачів призначені для людей. Службові облікові записи призначені для процесів застосунків, які (для Kubernetes) виконуються в контейнерах, що є частиною Pod.
Облікові записи користувачів мають бути глобальними: імена повинні бути унікальними у всіх просторах імен кластера. Незалежно від того, який простір імен ви розглядаєте, певний обліковий запис користувача представляє того самого користувача. У Kubernetes службові облікові записи є привʼязаними до простору імен: два різні простори імен можуть містити ServiceAccountʼи з однаковими іменами.
Як правило, облікові записи користувачів кластера можуть синхронізуватися з корпоративною базою даних, де створення нового облікового запису користувача вимагає спеціальних привілеїв і повʼязане зі складними бізнес-процесами. Навпаки, створення службових облікових записів повинно бути легшим, дозволяючи користувачам кластера створювати службові облікові записи для конкретних завдань за запитом. Відділення створення ServiceAccount від кроків для реєстрації користувачів полегшує дотримання принципу найменших привілеїв для робочих навантажень.
Вимоги до аудиту для облікових записів користувачів (людей) та службових облікових записів можуть відрізнятися; розділення полегшує досягнення цих вимог.
Конфігураційний пакет для складної системи може містити визначення різних службових облікових записів для компонентів цієї системи. Оскільки службові облікові записи можуть створюватися без багатьох обмежень і мають імена, привʼязані до простору імен, така конфігурація зазвичай є переносимою.
Привʼязані токени службових облікових записів
Токени ServiceAccount можуть бути привʼязані до API обʼєктів, що існують у kube-apiserver. Їх можна використовувати для звʼязування дійсності токена з існуванням іншого API обʼєкта. Підтримувані типи обʼєктів наступні:
Pod (використовується для projected томів, див. нижче)
Secret (може використовуватися для відкликання токена шляхом видалення Secret)
Node (у версії v1.30 створення нових токенів, привʼязаних до вузлів, є альфа-функцією, використання наявних токенів, привʼязаних до вузлів, є бета-функцією)
Коли токен привʼязаний до обʼєкта, metadata.name і metadata.uid цього обʼєкта зберігаються як додаткові "приватні заявки" у виданому JWT.
Коли привʼязаний токен представляється kube-apiserver, автентифікатор службового облікового запису витягне і перевірить ці заявки. Якщо обʼєкт, на який він посилається, більше не існує (або його metadata.uid не збігається), запит не буде автентифікований.
Додаткові метадані в токенах, повʼязаних з Pod
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.30 [beta]
Коли токен службового облікового запису привʼязаний до обʼєкта Pod, додаткові метадані також вбудовуються в токен, що вказує на значення поля spec.nodeName повʼязаного Pod і uid цього вузла, якщо це можливо.
Ця інформація про вузол не перевіряється kube-apiserver, коли токен використовується для автентифікації. Вона включена, щоб інтегратори не повинні були отримувати обʼєкти API Pod або Node для перевірки повʼязаного імені вузла та uid при інспекції JWT.
Перевірка та інспекція приватних заявок
API TokenReview може використовуватися для перевірки та вилучення приватних заявок з токена:
Спочатку припустимо, що у вас є Pod з назвою test-pod і службовий обліковий запис з назвою my-sa.
Попри використання kubectl create -f для створення цього ресурсу, і визначення його схожим чином з іншими типами ресурсів у Kubernetes, TokenReview є спеціальним типом і kube-apiserver насправді не зберігає обʼєкт TokenReview в etcd. Тому kubectl get tokenreview не є допустимою командою.
Механізм томів привʼязаного токена службового облікового запису
...- name:kube-api-access-<random-suffix>projected:sources:- serviceAccountToken:path:token# має збігатися з шляхом, який очікує застосунок- configMap:items:- key:ca.crtpath:ca.crtname:kube-root-ca.crt- downwardAPI:items:- fieldRef:apiVersion:v1fieldPath:metadata.namespacepath:namespace
Цей фрагмент маніфесту визначає projected том, що складається з трьох джерел. У цьому випадку,
кожне джерело також представляє один шлях у цьому томі. Три джерела такі:
Джерело serviceAccountToken, яке містить токен, який kubelet отримує з kube-apiserver. Kubelet отримує токени з обмеженим терміном дії за допомогою API TokenRequest. Токен, наданий для TokenRequest, закінчується або при видаленні Pod, або після визначеного терміну дії (стандартно, це 1 година). Kubelet також оновлює цей токен перед тим, як термін його дії закінчиться. Токен привʼязаний до конкретного Pod і має kube-apiserver як свою аудиторію. Цей механізм замінив попередній механізм, який додавав том на основі Secret, де Secret представляв ServiceAccount для Pod, але не мав терміну дії.
Джерело configMap. ConfigMap містить набір даних центру сертифікації. Pod можуть використовувати ці сертифікати, щоб упевнитись, що вони підключаються до kube-apiserver вашого кластера (а не до проміжного блоку або випадково неправильно налаштованого колеги).
Джерело downwardAPI, яке шукає імʼя простору імен, що містить Pod, і надає цю інформацію про імʼя для коду застосунку, що виконується всередині Pod.
Будь-який контейнер у Pod, який монтує цей том, може отримати доступ до вищевказаної інформації.
Примітка:
Не існує якогось окремого механізму для анулювання токена, виданого через TokenRequest. Якщо ви більше не довіряєте привʼязаному токену службового облікового запису для Pod, ви можете видалити цей Pod. Видалення Pod анулює його привʼязані токени службових облікових записів.
Ручне управління Secret для ServiceAccounts
Версії Kubernetes до v1.22 автоматично створювали облікові дані для доступу до API Kubernetes. Цей старіший механізм був заснований на створенні токенів Secret, які потім могли бути змонтовані в запущені Podʼи.
У новіших версіях, включаючи Kubernetes v1.30, API облікові дані отримуються безпосередньо за допомогою TokenRequest, і монтуються в Podʼи за допомогою projected тому. Токени, отримані за допомогою цього методу, мають обмежений термін дії та автоматично анулюються, коли Pod, в який вони змонтовані, видаляється.
Ви все ще можете створити вручну Secret для збереження токена службового облікового запису; наприклад, якщо вам потрібен токен, який ніколи не закінчується.
Після того, як ви вручну створите Secret і звʼяжете його зі службовим обліковим записом, панель управління Kubernetes автоматично заповнює токен у цьому Secret.
Примітка:
Хоча існує ручний механізм для створення токена службового облікового запису з тривалим терміном дії, рекомендується використовувати TokenRequest для отримання токенів доступу до API з коротким терміном дії.
До версії 1.24 Kubernetes автоматично генерував токени на основі Secret для ServiceAccount. Щоб розрізнити автоматично згенеровані токени та створені вручну, Kubernetes перевіряє посилання з поля секретів ServiceAccount. Якщо Secret згадується в полі secrets, він вважається автоматично згенерованим застарілим токеном. В іншому випадку він вважається вручну створеним застарілим токеном. Наприклад:
apiVersion:v1kind:ServiceAccountmetadata:name:build-robotnamespace:defaultsecrets:- name:build-robot-secret# зазвичай НЕ присутній для вручну створеного токена
Починаючи з версії 1.29, застарілі токени службових облікових записів, які були згенеровані автоматично, будуть позначені як недійсні, якщо вони залишатимуться невикористаними протягом певного періоду часу (стандартно один рік). Токени, які продовжують залишатися невикористаними протягом цього визначеного періоду (знову ж таки, стандартно один рік), будуть згодом видалені панеллю управління.
Якщо користувачі використовують анульований автоматично згенерований токен, валідатор токенів:
додасть анотацію аудиту для пари ключ-значення authentication.k8s.io/legacy-token-invalidated: <secret name>/<namespace>,
оновить мітку Secret kubernetes.io/legacy-token-last-used з новою датою,
поверне помилку, вказуючи, що токен був анульований.
При отриманні цієї помилки валідації користувачі можуть оновити Secret, щоб видалити мітку kubernetes.io/legacy-token-invalid-since, щоб тимчасово дозволити використання цього токена.
Ось приклад автоматично згенерованого застарілого токена, який був позначений мітками kubernetes.io/legacy-token-last-used і kubernetes.io/legacy-token-invalid-since:
Контролер ServiceAccount керує ServiceAccount всередині просторів імен та забезпечує наявність ServiceAccount з іменем "default" у кожному активному просторі імен.
Контролер токенів
Контролер токенів службових облікових записів працює як частина kube-controller-manager. Цей контролер діє асинхронно. Він:
відстежує видалення ServiceAccount та видаляє всі відповідні Secretʼи токенів ServiceAccount.
відстежує додавання Secretʼу токенів ServiceAccount та забезпечує наявність відповідного ServiceAccount, додає токен до Secretʼу за потреби.
відстежує видалення Secretʼу та видаляє посилання з відповідного ServiceAccount за потреби.
Необхідно передати файл приватного ключа службового облікового запису контролеру токенів у kube-controller-manager, використовуючи прапорець --service-account-private-key-file. Приватний ключ використовується для підпису згенерованих токенів службових облікових записів. Аналогічно, необхідно передати відповідний публічний ключ у kube-apiserver, використовуючи прапорець --service-account-key-file. Публічний ключ буде використовуватися для перевірки токенів під час автентифікації.
Контролер допуску ServiceAccount
Зміна Podʼів здійснюється через втулок, що викликається Контролером допуску. Він є частиною сервера API. Цей контролер допуску діє синхронно для зміни Podʼів під час їх створення. Коли цей втулок активний (а він є стандартно активним у більшості дистрибутивів), то під час створення Pod він виконує наступні дії:
Якщо у Pod не встановлено значення .spec.serviceAccountName, контролер допуску встановлює імʼя ServiceAccount default для цього Pod.
Контролер допуску забезпечує наявність ServiceAccount, на який посилається Pod. Якщо не існує ServiceAccount з відповідним імʼям, контролер допуску відхиляє Pod. Ця перевірка застосовується навіть для default ServiceAccount.
Якщо поле automountServiceAccountToken у ServiceAccount або в Podʼі не встановлено в false:
контролер допуску змінює Pod, додаючи додатковий том, що містить токен для доступу до API.
контролер допуску додає volumeMount до кожного контейнера в Podʼі, пропускаючи контейнери, які вже мають визначений шлях для монтування тому /var/run/secrets/kubernetes.io/serviceaccount. Для Linux-контейнерів цей том монтується за адресою /var/run/secrets/kubernetes.io/serviceaccount; на Windows-вузлах монтування знаходиться ну еквівалентному шляху.
Якщо в специфікації Pod не містяться жодні imagePullSecrets, контролер допуску додає imagePullSecrets, копіюючи їх з ServiceAccount.
Цей контролер створює ConfigMap з назвою kube-system/kube-apiserver-legacy-service-account-token-tracking у просторі імен kube-system. ConfigMap фіксує мітку часу, коли система почала відстежувати застарілі токени службових облікових записів.
Очищувач токенів застарілих ServiceAccount
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.30 [stable]
Очищувач токенів застарілих ServiceAccount працює як частина kube-controller-manager і перевіряє кожні 24 години, чи не використовувався будь-який автоматично згенерований застарілий токен службового облікового запису протягом визначеного часу. Якщо так, очищувач позначає ці токени як недійсні.
Очищувач працює, спершу перевіряючи ConfigMap, створений панеллю управління (за умови, що LegacyServiceAccountTokenTracking увімкнено). Якщо поточний час перевищує визначений час після дати в ConfigMap, очищувач переглядає список Secretʼів у кластері та оцінює кожен Secret, що має тип kubernetes.io/service-account-token.
Якщо Secret відповідає всім наступним умовам, очищувач позначає його як недійсний:
Secret створено автоматично, що означає що він двонаправлено згадується ServiceAccount.
Secret не змонтовано жодним Podʼом.
Secret не використовувався протягом визначеного часу з моменту створення або останнього використання.
Очищувач позначає Secret як недійсний, додаючи мітку kubernetes.io/legacy-token-invalid-since до Secret, з поточною датою. Якщо недійсний Secret не використовується протягом визначеного часу, очищувач видаляє його.
Примітка:
Усі визначені часи стандартно становлять один рік. Адміністратор кластера може налаштувати це значення через аргумент командного рядка --legacy-service-account-token-clean-up-period для компонента kube-controller-manager.
API TokenRequest
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.22 [stable]
Ви використовуєте субресур TokenRequest з ServiceAccount, щоб отримати токен з обмеженим часом дії для цього ServiceAccount. Вам не потрібно викликати його для отримання API-токена для використання в контейнері, оскільки kubelet налаштовує це для вас, використовуючи projected том.
Панель управління Kubernetes (зокрема, контролер допуску ServiceAccount) додає projected том до Podʼів, а kubelet забезпечує, що цей том містить токен, який дозволяє контейнерам автентифікуватися як відповідний ServiceAccount.
(Цей механізм замінив попередній механізм, який додавав том на основі Secret, де Secret представляв ServiceAccount для Pod, але не мав терміну дії.)
Ось приклад того, як це виглядає для запущеного Pod:
Цей фрагмент маніфесту визначає projected том, який обʼєднує інформацію з трьох джерел:
Джерело serviceAccountToken, що містить токен, який kubelet отримує від kube-apiserver. Kubelet отримує токени з обмеженим часом дії, використовуючи API TokenRequest. Токен, виданий для TokenRequest, спливає або коли Pod видаляється, або через визначений термін життя (стандартно — 1 година). Токен привʼязаний до конкретного Podʼа та має kube-apiserver як свою аудиторію.
Джерело configMap. ConfigMap містить пакет даних сертифікаційного центру. Podʼи можуть використовувати ці сертифікати, щоб переконатися, що вони підключаються до kube-apiserver вашого кластера (а не до проміжного блоку або випадково неправильно налаштованого колеги).
Джерело downwardAPI. Цей том downwardAPI робить імʼя простору імен, що містить Pod, доступним для коду програми, що працює всередині Podʼа.
Будь-який контейнер у Podʼі, що монтує цей том, може отримати доступ до вищезазначеної інформації.
Створення додаткових API токенів
Увага:
Створюйте довгострокові API токени тільки якщо механізм запиту токенів не підходить. Механізм запиту токенів надає токени з обмеженим часом дії; оскільки вони спливають, вони представляють менший ризик для інформаційної безпеки.
Для створення постійного API токена для ServiceAccount, створіть Secret типу kubernetes.io/service-account-token з анотацією, що посилається на ServiceAccount. Панель управління потім генерує довгостроковий токен і оновлює цей Secret з даними згенерованого токена.
Якщо ви запустите новий Pod у просторі імен examplens, він може використовувати Secret токену службового облікового запису myserviceaccount, який ви щойно створили.
API для сертифікатів та наборів довіри Kubernetes дозволяють автоматизувати створення облікових даних X.509, надаючи програмний інтерфейс для клієнтів API Kubernetes для запиту та отримання X.509 сертифікатів від Центру сертифікації (CA).
Також є експериментальна (альфа) підтримка розподілу наборів довіри.
Запити на підписання сертифікатів
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.19 [stable]
Ресурс CertificateSigningRequest (CSR) використовується для запиту підписання сертифіката від вказаного підписувача, після чого запит може бути схвалений або відхилений перед остаточним підписанням.
Процес підписання запиту
Ресурс типу CertificateSigningRequest дозволяє клієнту запросити видачу сертифіката X.509 на основі запиту на підписання. Обʼєкт CertificateSigningRequest містить PEM-кодований запит на підпис у форматі PKCS#10 у полі spec.request. CertificateSigningRequest вказує підписувача (одержувача, до якого робиться запит) за допомогою поля spec.signerName. Зверніть увагу, що після версії API certificates.k8s.io/v1 ключ spec.signerName є обовʼязковим. У Kubernetes v1.22 та пізніших версіях клієнти можуть за бажанням встановити поле spec.expirationSeconds, щоб запросити певний термін дії виданого сертифіката. Мінімальне допустиме значення для цього поля — 600, тобто десять хвилин.
Після створення CertificateSigningRequest його необхідно схвалити перед підписанням. Залежно від обраного підписувача, CertificateSigningRequest може бути автоматично схвалений контролером. В іншому випадку CertificateSigningRequest слід схвалити вручну через API REST (або client-go) або за допомогою команди kubectl certificate approve. Аналогічно CertificateSigningRequest також може бути відхилений, що повідомляє налаштованому підписувачу, що він не повинен підписати запит.
Для схвалених сертифікатів наступним кроком є підписання. Відповідний контролер підпису перевіряє, чи виконуються умови підписання, а потім створює сертифікат. Після цього контролер підпису оновлює CertificateSigningRequest, зберігаючи новий сертифікат у полі status.certificate наявного обʼєкта CertificateSigningRequest. Поле status.certificate CertificateSigningRequest може бути порожнім або містити сертифікат X.509, кодований у форматі PEM. Поле status.certificate CertificateSigningRequest залишається порожнім, доки підписувач не зробить це.
Після заповнення поля status.certificate запит вважається завершеним, і клієнти тепер можуть отримати PEM-дані підписаного сертифіката з ресурсу CertificateSigningRequest. Підписувачі також можуть відхилити підпис сертифіката, якщо умови схвалення не виконані.
Для зменшення кількості застарілих ресурсів CertificateSigningRequest в кластері періодично запускається контролер збору сміття. Він видаляє CertificateSigningRequests, які не змінювали стан протягом певного періоду:
Схвалені запити: автоматично видаляються після 1 години
Відхилені запити: автоматично видаляються після 1 години
Невдалі запити: автоматично видаляються після 1 години
Запити в очікуванні: автоматично видаляються після 24 годин
Усі запити: автоматично видаляються після того, як видача сертифіката закінчиться після спливання часу дії
Авторизація підпису сертифікатів
Для можливості створення запиту на підпис сертифіката та отримання будь-якого запиту на підпис сертифіката:
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:csr-signerrules:- apiGroups:- certificates.k8s.ioresources:- certificatesigningrequestsverbs:- get- list- watch- apiGroups:- certificates.k8s.ioresources:- certificatesigningrequests/statusverbs:- update- apiGroups:- certificates.k8s.ioresources:- signersresourceNames:- example.com/my-signer-name# example.com/* може використовуватись для авторизації всіх підписувачів в домені 'example.com'verbs:- sign
Підписувачі
Підписувачі абстрактно представляють сутність або сутності, які можуть підписувати або вже підписали сертифікат.
Будь-який підписувач, який доступний за межами конкретного кластера, повинен надавати інформацію про те, як працює підписувач, щоб споживачі могли зрозуміти, що це означає для CertificateSigningRequests та (якщо це увімкнено) ClusterTrustBundles. Це охоплює:
Розподіл довіри: як розподіляються якорі довіри (CA-сертифікати або набори сертифікатів).
Дозволені субʼєкти: будь-які обмеження та поведінка, коли запитано недопустимий субʼєкт.
Дозволені розширення x509: включаючи IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames тощо, та поведінка, коли запитано недопустиме розширення.
Дозволені використання ключів / розширені використання ключів: будь-які обмеження та поведінка, коли використання, відмінне від використання, визначеного підписувачем, вказане в CSR.
Термін дії / термін життя сертифіката: чи він фіксується підписувачем, настроюваний адміністратором, визначений полем spec.expirationSeconds CSR тощо, та поведінка, коли термін дії, визначений підписувачем, відрізняється від поля spec.expirationSeconds CSR.
Дозволені / заборонені прапорці CA: та поведінка, якщо CSR містить запит на отримання сертифіката CA, коли підписувач не пропускає його.
Зазвичай поле status.certificate обʼєкта CertificateSigningRequest містить один PEM-кодований сертифікат X.509, як тільки CSR схвалено, і сертифікат видається. Деякі підписувачі зберігають кілька сертифікатів у полі status.certificate. У цьому випадку документація для підписувача повинна вказувати значення додаткових сертифікатів; наприклад, це може бути сертифікат плюс проміжні сертифікати, які представляються під час рукостискання TLS.
Якщо ви хочете зробити якір довіри (кореневий сертифікат) доступним, це слід зробити окремо від CertificateSigningRequest та його поля status.certificate. Наприклад, ви можете використовувати ClusterTrustBundle.
Формат підпису PKCS#10 не має стандартного механізму для вказання терміну дії або терміну життя сертифіката. Термін дії або термін життя має бути встановлено через поле spec.expirationSeconds обʼєкта CSR. Вбудовані підписувачі використовують параметр конфігурації ClusterSigningDuration, який стандартно становить 1 рік, (прапорець командного рядка --cluster-signing-duration kube-controller-manager) в як стандартне значення, коли не вказано spec.expirationSeconds. Коли вказано spec.expirationSeconds, використовується мінімум з spec.expirationSeconds та ClusterSigningDuration.
Примітка:
Поле spec.expirationSeconds було додано в Kubernetes v1.22. У попередніх версіях Kubernetes це поле не враховується. API-сервери Kubernetes до v1.22 будуть мовчки видаляти це поле при створенні обʼєкта.
Підписувачі Kubernetes
Kubernetes надає вбудовані підписувачі для підпису сертифікатів, кожен з яких має широко відоме імʼя підписувача signerName:
kubernetes.io/kube-apiserver-client: підписує сертифікати, які мають вважатись сертифікатами клієнтів сервером API. Ніколи автоматично не затверджуються kube-controller-manager.
Розподіл довіри: підписані сертифікати мають вважатись клієнтськими сертифікатами для доступу до API-сервера. Набір ЦС не поширюється жодним іншим способом.
Дозволені субʼєкти: немає обмежень для субʼєктів, однак затверджувачі та підписувачі можуть відхилити запити на затвердження та підпис. Певні субʼєкти подібні до користувачів та груп на рівні кластера є різними поміж різними дистрибутивами, що вимагає додаткових перевірок перед затвердженням та підписуванням. Втулок допуску CertificateSubjectRestrictions є стандартно увімкненим для обмеження system:masters, але в кластері є не тільки субʼєкти рівня адміністраторів кластера.
Дозволені розширення x509: враховують subjectAltNames та використання ключів, відкидаючи інші розширення.
Використання дозволених ключів: мають включати ["client auth"]. Не мають містити використання ключів поза ["digital signature", "key encipherment", "client auth"].
Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
Біт ЦС дозволено / заборонено: не дозволяється.
kubernetes.io/kube-apiserver-client-kubelet: підписує сертифікати, які мають вважатись сертифікатами клієнтів сервером API. Можуть бути автоматично затверджені kube-controller-manager.
Розподіл довіри: підписані сертифікати мають вважатись клієнтськими сертифікатами для доступу до API-сервера. Набір ЦС не поширюється жодним іншим способом.
Дозволені субʼєкти: організації є безумовно ["system:nodes"], загальні імена починаються з "system:node:".
Дозволені розширення x509: враховують розширення з використанням ключів, забороняють розширення subjectAltNames та відкидає інші розширення.
Дозволені використання ключів: ["key encipherment", "digital signature", "client auth"] або ["digital signature", "client auth"].
Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
Біт ЦС дозволено / заборонено: не дозволяється.
kubernetes.io/kubelet-serving: підписує сертифікати, які мають вважатись сертифікатами, які обслуговуються kubelet, але не мають жодних гарантій. Ніколи автоматично не затверджуються kube-controller-manager.
Розподіл довіри: підписані сертифікати мають вважатись API сервером дійсними для обробки зʼєднань з kubelet. Набір ЦС не поширюється жодним іншим способом.
Дозволені субʼєкти: організації є безумовно ["system:nodes"], загальні імена починаються з "system:node:".
Дозволені розширення x509: враховують використання ключів та розширень DNSName/IPAddress subjectAltName extensions, забороняють розширення EmailAddress та URI subjectAltName, відкидають інші розширення. Принаймні один субʼєкт DNS чи IP повинен бути у subjectAltNames.
Дозволені використання ключів: ["key encipherment", "digital signature", "server auth"] або ["digital signature", "server auth"].
Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
Біт ЦС дозволено / заборонено: не дозволяється.
kubernetes.io/legacy-unknown: не має гарантій довіри взагалі. Деякі сторонні дистрибутиви Kubernetes можуть використовувати сертифікати клієнтів, підписані ним. Стабільний API CertificateSigningRequest (версії certificates.k8s.io/v1 та пізніше) не дозволяють встановлювати signerName на kubernetes.io/legacy-unknown. Ніколи автоматично не затверджується kube-controller-manager.
Розподіл довіри: Немає. Для цього підписувача не існує стандартної довіри або розподілу в кластері Kubernetes.
Дозволені субʼєкти: будь-які
Дозволені розширення x509: враховуються subjectAltNames та використання ключів, відкидаються інші розширення.
Дозволені використання ключів: будь-які
Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
Біт ЦС дозволено / заборонено: не дозволяється.
kube-controller-manager реалізує підписування панелю управління для кожного з вбудованих підписувачів. Збої для всіх цих операцій повідомляються лише в логах kube-controller-manager.
Примітка:
Поле spec.expirationSeconds було додано в Kubernetes v1.22. Раніше версії Kubernetes не враховували це поле. API-сервери Kubernetes до v1.22 будуть просто ігнорувати це поле під час створення обʼєкта.
Розподіл довіри відбувається поза рамками для цих підписувачів. Будь-яка довіра за межами описаного вище є строго випадковою. Наприклад, деякі дистрибутиви можуть приймати kubernetes.io/legacy-unknown як клієнтські сертифікати для kube-apiserver, але це не є стандартом. Жодне з цих використань не повʼязане з токенами секретів ServiceAccount .data[ca.crt]. Цей пакет CA гарантовано лише для верифікації зʼєднання з API-сервером за допомогою стандартного Service (kubernetes.default.svc).
Власні підписувачі
Ви можете ввести власних підписувачів, які матимуть схожі імена з префіксами, але такі, що вказують на ваш власний домен. Наприклад, якщо ви є представником проєкту з відкритими сирцями, який використовує доменне імʼя open-fictional.example, тоді ви можете використовувати issuer.open-fictional.example/service-mesh як імʼя підписувача.
Власний підписувач використовує API Kubernetes для випуску сертифікатів. Дивіться підписувачі на основі API для деталей.
Підписування
Підписування панеллю управління
Панель управління Kubernetes реалізує кожного з підписувачів Kubernetes як частину kube-controller-manager.
Примітка:
До Kubernetes v1.18, kube-controller-manager підписував будь-які CSRs, які були позначені як схвалені.
Примітка:
Поле spec.expirationSeconds було додано в Kubernetes v1.22. Раніше версії Kubernetes не враховували це поле. API-сервери Kubernetes до v1.22 будуть просто ігнорувати це поле під час створення обʼєкта.
Підписувачі на основі API
Користувачі REST API можуть підписувати CSRs, надсилаючи запит UPDATE до субресурсу status CSR, який потрібно підписати.
У рамках цього запиту поле status.certificate повинно бути встановлено, щоб містити підписаний сертифікат. Це поле містить один або більше сертифікатів, закодованих у форматі PEM.
Всі PEM блоки повинні мати мітку "CERTIFICATE", не містити заголовків, а закодовані дані повинні бути структурою сертифіката BER, закодованого в ASN.1, як описано в розділі 4 RFC5280.
Не-PEM вміст може зʼявлятися до або після блоків CERTIFICATE PEM і не перевіряється, щоб дозволити пояснювальний текст, як описано в розділі 5.2 RFC7468.
При кодуванні в JSON або YAML це поле закодоване в base-64. Запит на підпис сертифіката (CertificateSigningRequest), що містить приклад сертифіката вище, виглядатиме так:
Перед тим, як підписувач видасть сертифікат на основі запиту на підписання сертифіката (CertificateSigningRequest), підписувач зазвичай перевіряє, що видача для цього CSR була схвалена.
Автоматичне схвалення панелі управління
kube-controller-manager поставляється з вбудованим схвалювачем для сертифікатів з іменем підписувача kubernetes.io/kube-apiserver-client-kubelet, який делегує різні дозволи на CSRs для облікових даних вузлів до авторизації. kube-controller-manager надсилає ресурси SubjectAccessReview до API-сервера для перевірки авторизації на схвалення сертифіката.
Схвалення або відхилення за допомогою kubectl
Адміністратор Kubernetes (з відповідними дозволами) може вручну схвалювати (або відхиляти) запити на підписання сертифікатів (CertificateSigningRequests) за допомогою команд kubectl certificate approve та kubectl certificate deny.
Схвалення або відхилення за допомогою API Kubernetes
Користувачі REST API можуть схвалювати CSRs, надсилаючи запит UPDATE до субресурсу approval CSR, який потрібно схвалити. Наприклад, ви можете написати оператор, який слідкує за певним видом CSR, а потім надсилає UPDATE для їх схвалення.
Коли ви робите запит на схвалення або відхилення, встановіть або умову статусу Approved, або Denied залежно від визначеного стану:
Для схвалених CSR:
apiVersion:certificates.k8s.io/v1kind:CertificateSigningRequest...status:conditions:- lastUpdateTime:"2020-02-08T11:37:35Z"lastTransitionTime:"2020-02-08T11:37:35Z"message:Approved by my custom approver controllerreason:ApprovedByMyPolicy# Ви можете вказати тут будь-який рядокtype:Approved
Для відхилених CSR:
apiVersion:certificates.k8s.io/v1kind:CertificateSigningRequest...status:conditions:- lastUpdateTime:"2020-02-08T11:37:35Z"lastTransitionTime:"2020-02-08T11:37:35Z"message:Denied by my custom approver controllerreason:DeniedByMyPolicy# Ви можете вказати тут будь-який рядокtype:Denied
Зазвичай встановлюється в поле status.conditions.reason код причини, зручний для машинного зчитування, використовуючи TitleCase; це є умовністю, але ви можете встановити тут будь-яке значення. Якщо ви хочете додати примітку для читання людьми, використовуйте поле status.conditions.message.
Пакети довіри кластера
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.27 [alpha]
Примітка:
У Kubernetes 1.30 ви повинні ввімкнути функціональну можливістьClusterTrustBundleтагрупу APIcertificates.k8s.io/v1alpha1,
щоб використовувати цей API.
ClusterTrustBundles — це обʼєкт масштабу кластера для розподілу якорів довіри X.509 (кореневих сертифікатів) до робочих навантажень у кластері. Вони розроблені для гарної роботи з концепцією підписувача із запитів на підписання сертифікатів (CertificateSigningRequests).
Усі обʼєкти ClusterTrustBundle мають сувору валідацію вмісту їхнього поля trustBundle. Це поле повинно містити один або більше сертифікатів X.509, серіалізованих у DER, кожен з яких обгорнутий у блок PEM CERTIFICATE. Сертифікати повинні аналізуватися як дійсні сертифікати X.509.
Езотеричні функції PEM, такі як дані між блоками та заголовки всередині блоків, або відхиляються під час валідації обʼєкта, або можуть ігноруватися споживачами обʼєкта. Крім того, споживачі можуть перевпорядковувати сертифікати в пакеті за своїм власним довільним, але стабільним порядком.
Обʼєкти ClusterTrustBundle слід вважати загальнодоступними в межах кластера. Якщо ваш кластер використовує авторизацію RBAC, усі ServiceAccounts стандартно мають дозволи get, list та watch для всіх обʼєктів ClusterTrustBundle. Якщо ви використовуєте власний механізм авторизації та ввімкнули ClusterTrustBundles у своєму кластері, вам слід налаштувати еквівалентне правило для того, щоб ці обʼєкти були загальнодоступними в межах кластера, щоб вони працювали належним чином.
Якщо ви не маєте стандартного дозволу для отримання переліку пакетів довіри кластера у вашому кластері, ви можете діяти від імені службового облікового запису, до якого у вас є доступ, щоб побачити доступні ClusterTrustBundles:
kubectl get clustertrustbundles --as='system:serviceaccount:mynamespace:default'
ClusterTrustBundles, звʼязані з підписувачем
ClusterTrustBundles, звʼязані з підписувачем, асоціюються з імʼям підписувача, як тут:
apiVersion:certificates.k8s.io/v1alpha1kind:ClusterTrustBundlemetadata:name:example.com:mysigner:foospec:signerName:example.com/mysignertrustBundle:"<... PEM data ...>"
ClusterTrustBundles призначені для підтримки контролера, специфічного для підписувача в кластері, тому вони мають кілька функцій безпеки:
Щоб створити або оновити ClusterTrustBundle, звʼязаний з підписувачем, ви повинні мати дозвіл підтвердити підписувача (спеціальне дієслово авторизації attest, група API certificates.k8s.io; шлях ресурсу signers). Ви можете налаштувати авторизацію для конкретного імені ресурсу <signerNameDomain>/<signerNamePath> або відповідати шаблону, наприклад <signerNameDomain>/*.
ClusterTrustBundles, звʼязані з підписувачем, повинні бути названі з префіксом, отриманим з їхнього поля spec.signerName. Слеші (/) замінюються на двокрапки (:), а в кінці додається двокрапка. За цим слідує довільне імʼя. Наприклад, підписувач example.com/mysigner може бути звʼязаний з ClusterTrustBundle example.com:mysigner:<arbitrary-name>.
ClusterTrustBundles, звʼязані з підписувачем, зазвичай використовуються у робочих навантаженнях за допомогою комбінації селектора полів за іменем підписувача та окремого селектора міток.
ClusterTrustBundles, незвʼязані з підписувачем
ClusterTrustBundles, незвʼязані з підписувачем, мають порожнє поле spec.signerName, як це:
apiVersion:certificates.k8s.io/v1alpha1kind:ClusterTrustBundlemetadata:name:foospec:# signerName не вказано, тому поле порожнєtrustBundle:"<... PEM data ...>"
Вони призначені головним чином для випадків використання конфігурації кластера. Кожен ClusterTrustBundle, незвʼязаний з підписувачем, є незалежним обʼєктом, на відміну від звичайної групової поведінки ClusterTrustBundles, звʼязаних з підписувачем.
ClusterTrustBundles, незвʼязані з підписувачем, не мають вимоги щодо дієслова attest. Натомість, ви контролюєте доступ до них безпосередньо за допомогою звичайних механізмів, таких як контроль доступу на основі ролей.
Щоб відрізнити їх від ClusterTrustBundles, звʼязаних з підписувачем, назви ClusterTrustBundles, незвʼязаних з підписувачем, не повинні містити двокрапку (:).
Доступ до ClusterTrustBundles з Podʼів
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.29 [alpha]
Вміст ClusterTrustBundles може бути впроваджений у файлову систему контейнера, подібно до ConfigMaps та Secrets. Дивіться джерело projected томів clusterTrustBundle для отримання додаткової інформації.
Як видати сертифікат для користувача
Для того, щоб звичайний користувач міг автентифікуватися та викликати API, потрібно виконати кілька кроків. Спершу цей користувач повинен мати сертифікат, виданий кластером Kubernetes, а потім надати цей сертифікат API Kubernetes.
Створення приватного ключа
Наступні скрипти показують, як згенерувати приватний ключ PKI та CSR. Важливо встановити значення CN та O атрибута CSR. CN — це імʼя користувача, а O — це група, до якої належатиме цей користувач. Ви можете звернутися до RBAC по стандартні групи.
Створіть запит на підписання сертифікату (CertificateSigningRequest) і подайте його до кластера Kubernetes через kubectl. Нижче наведено скрипт для CertificateSigningRequest.
3.12 - Зіставлення PodSecurityPolicies зі стандартами безпеки Podʼів
Нижче наведено таблиці, що перераховують параметри конфігурації обʼєктів PodSecurityPolicy, чи поле змінює або перевіряє контейнери, та як значення конфігурації зіставляються з Стандартами безпеки Podʼів.
Для кожного параметра, до якого це застосовується, перераховані допустимі значення для Baseline та Restricted профілів. Все, що перебуває за межами допустимих значень для цих профілів, підпадає під Privileged профіль. "Немає думки" означає, що всі значення допустимі для всіх стандартів безпеки Podʼів.
Baseline: "runtime/default,"(Кома в кінці, щоб встановити unset)
Restricted: "runtime/default"(Без коми в кінці)
Значення localhost/* також дозволені як для Baseline, так і для Restricted.
3.13 - Автентифікація/авторизація kubelet
Огляд
HTTP-запити до HTTPS-точки доступу kubelet надають доступ до даних різного рівня чутливості та дозволяють виконувати операції з різними рівнями повноважень на вузлі та в контейнерах.
У цьому документі описано, як автентифікувати та авторизувати доступ до HTTPS-точки доступу kubelet.
Автентифікація kubelet
Стандартно запити до HTTPS-точки доступу kubelet, які не відхилені іншими налаштованими методами автентифікації, розглядаються як анонімні запити та отримують імʼя користувача system:anonymous та групу system:unauthenticated.
Щоб вимкнути анонімний доступ та надсилати відповіді 401 Unauthorized на невідомі запити:
запустіть kubelet з прапорцем --anonymous-auth=false
Щоб увімкнути автентифікацію за допомогою клієнтських сертифікатів X509 до HTTPS-точки доступу kubelet:
запустіть kubelet з прапорцем --client-ca-file, надаючи набір кореневих сертифікатів для перевірки клієнтських сертифікатів
запустіть apiserver з прапорцями --kubelet-client-certificate та --kubelet-client-key
Щоб увімкнути використання API-токенів на предʼявника (включаючи токени службових облікових записів) для автентифікації до HTTPS-точки доступу kubelet:
переконайтеся, що група API authentication.k8s.io/v1beta1 ввімкнена в apiserver
запустіть kubelet з прапорцями --authentication-token-webhook та --kubeconfig
kubelet викликає API TokenReview на налаштованому apiserver, щоб визначити інформацію про користувача з токенів на предʼявника
Авторизація kubelet
Будь-який запит, який успішно автентифікується (включаючи анонімний запит), потім авторизується. Стандартний режим авторизації — AlwaysAllow, який дозволяє всі запити.
Є багато можливих причин для розподілу доступу до API kubelet:
ввімкнено анонімну автентифікацію, але потрібно обмежити можливості анонімних користувачів викликати API kubelet
ввімкнено автентифікацію з використанням токенів на предʼявника, але потрібно обмежити можливості довільних користувачів API (наприклад, службові облікові записи) викликати API kubelet
ввімкнено автентифікацію за допомогою клієнтських сертифікатів, але дозволено використовувати API kubelet тільки деяким сертифікатам клієнтів, які підписані налаштованим кореневим сертифікатом
Щоб розділити доступ до API kubelet, делегуйте авторизацію apiserver:
переконайтеся, що група API authorization.k8s.io/v1beta1 ввімкнена в apiserver
запустіть kubelet з прапорцями --authorization-mode=Webhook та --kubeconfig
kubelet викликає API SubjectAccessReview на налаштованому apiserver, щоб визначити, чи авторизований кожний запит
Kubelet авторизує запити до API, використовуючи той самий підхід до атрибутів запиту, що й apiserver.
Дієслово визначається з HTTP-дії вхідного запиту:
HTTP-дія
Дієслово запиту
POST
create
GET, HEAD
get
PUT
update
PATCH
patch
DELETE
delete
Ресурс та субресурс визначаються з шляху вхідного запиту:
Kubelet API
Ресурс
Субресурс
/stats/*
nodes
stats
/metrics/*
nodes
metrics
/logs/*
nodes
log
/spec/*
nodes
spec
всі інші
nodes
proxy
Атрибути простору імен та групи API завжди є порожніми рядками, а імʼя ресурсу завжди є імʼям обʼєкта Node kubelet.
При використанні цього режиму переконайтеся, що користувач, визначений прапорцями --kubelet-client-certificate та --kubelet-client-key, переданими до apiserver, має дозвіл наступних атрибутів:
verb=*, resource=nodes, subresource=proxy
verb=*, resource=nodes, subresource=stats
verb=*, resource=nodes, subresource=log
verb=*, resource=nodes, subresource=spec
verb=*, resource=nodes, subresource=metrics
3.14 - Початкове завантаження TLS
У кластері Kubernetes компоненти на вузлах робочих навантажень, kubelet та kube-proxy, повинні взаємодіяти з компонентами панелі управління Kubernetes, зокрема з kube-apiserver. Для забезпечення приватності комунікації, її невтручання та переконання, що кожен компонент кластера спілкується з іншим довіреним компонентом, ми наполегливо рекомендуємо використовувати TLS-сертифікати клієнтів на вузлах.
Звичайний процес ініціалізації цих компонентів, особливо робочих вузлів, які потребують сертифікати для безпечної комунікації з kube-apiserver, може бути складним, оскільки він часто виходить за межі Kubernetes і вимагає значної додаткової роботи. Це, своєю чергою, може ускладнити ініціалізацію або масштабування кластера.
З метою спрощення процесу, починаючи з версії 1.4, Kubernetes ввів API запиту та підпису сертифікатів. Пропозицію можна знайти тут.
У цьому документі описано процес ініціалізації вузла, спосіб налаштування початкового завантаження TLS-сертифікатів клієнтів для kubelet та його роботу.
Процес ініціалізації
Коли робочий вузол запускається, kubelet виконує наступне:
Шукає свій файл kubeconfig.
Отримує URL-адресу сервера API та облікові дані, зазвичай ключ TLS та підписаний сертифікат з файлу kubeconfig.
Намагається спілкуватися з сервером API, використовуючи облікові дані.
Припускаючи, що kube-apiserver успішно перевіряє облікові дані kubelet, він буде вважати kubelet дійсним вузлом та почне призначати для нього Podʼи.
Зауважте, що вищевказаний процес залежить від:
Існування ключа та сертифіката на локальному хості у kubeconfig.
Підписання сертифіката центром сертифікації (CA), якому довіряє kube-apiserver.
Всі перелічені нижче обовʼязки покладаються на того, хто налаштовує та керує кластером:
Створення ключа та сертифіката CA.
Розповсюдження сертифіката CA на вузли панелі управління, де запущений kube-apiserver.
Створення ключа та сертифіката для кожного kubelet; наполегливо рекомендується мати унікальний ключ з унікальним CN для кожного kubelet.
Підписання сертифіката kubelet за допомогою ключа CA.
Розповсюдження ключа та підписаного сертифіката kubelet на конкретний вузол, на якому працює kubelet.
Початкове завантаження TLS, описане у цьому документі, призначене спростити та частково або повністю автоматизувати кроки з 3 по 14, оскільки вони є найбільш поширеними при ініціалізації або масштабуванні кластера.
Ініціалізація початкового завантаження
Під час процесу ініціалізації початкового завантаження відбувається наступне:
kubelet починає роботу.
kubelet бачить, що у нього немає файлу kubeconfig.
kubelet шукає та знаходить файл bootstrap-kubeconfig.
kubelet читає свій файл ініціалізації початкового завантаження, отримуючи URL-адресу сервера API та обмежений "токен".
kubelet підключається до сервера API, автентифікується за допомогою токена.
у kubelet тепер є обмежені облікові дані для створення та отримання запиту на підпис сертифіката (CSR).
kubelet створює CSR для себе з встановленим signerName kubernetes.io/kube-apiserver-client-kubelet.
CSR затверджується одним з двох способів:
Якщо налаштовано, kube-controller-manager автоматично затверджує CSR.
Якщо налаштовано, зовнішній процес, можливо, людина, затверджує CSR за допомогою API Kubernetes або через kubectl.
Сертифікат створюється для kubelet.
Сертифікат видано для kubelet.
kubelet отримує сертифікат.
kubelet створює належний kubeconfig з ключем та підписаним сертифікатом.
kubelet починає нормальну роботу.
Опціонально: якщо налаштовано, kubelet автоматично запитує поновлення сертифіката, коли той наближається до закінчення строку дії.
Поновлений сертифікат затверджується та видається, або автоматично, або вручну, залежно від налаштувань.
Усі інші розділи цього документу описують необхідні кроки для налаштування початкового завантаження TLS та його обмежень.
Налаштування
Для налаштування початкового завантаження TLS та опціонального автоматичного затвердження потрібно налаштувати параметри на наступних компонентах:
kube-apiserver
kube-controller-manager
kubelet
ресурси в кластері: ClusterRoleBinding та, можливо, ClusterRole
Крім того, вам потрібен ваш центр сертифікації Kubernetes (CA).
Центр сертифікації
Як і без початкового завантаження, вам знадобиться ключ та сертифікат центру сертифікації (CA). Як і раніше, вони будуть використовуватися для підпису сертифіката kubelet. Як і раніше, ваша відповідальність полягає в їх розповсюджені на вузли панелі управління.
Для цілей цього документу ми припускаємо, що вони розповсюджені на вузли панелі управління за шляхом /var/lib/kubernetes/ca.pem (сертифікат) та /var/lib/kubernetes/ca-key.pem (ключ). Ми будемо посилатися на них як "сертифікат та ключ CA Kubernetes".
Всі компоненти Kubernetes, які використовують ці сертифікати — kubelet, kube-apiserver, kube-controller-manager — припускають, що ключ та сертифікат закодовані у PEM-форматі.
Налаштування kube-apiserver
У kube-apiserver є кілька вимог для активації початкового завантаження TLS:
Визнання CA, який підписує сертифікат клієнта
Автентифікація початкового завантаження kubelet у групу system:bootstrappers
Авторизація початкового завантаження kubelet для створення запиту на підпис сертифіката (CSR)
Визнання сертифікатів клієнтів
Це є нормою для всієї автентифікації сертифікатів клієнтів. Якщо це ще не налаштовано, додайте прапорець --client-ca-file=ФАЙЛ до команди kube-apiserver, щоб активувати автентифікацію за сертифікатом клієнта, посилаючись на пакет сертифікатів центру сертифікації, наприклад --client-ca-file=/var/lib/kubernetes/ca.pem.
Початкова автентифікація початкового завантаження
Для того, щоб процес початкового завантаження kubelet міг підʼєднатися до kube-apiserver та запросити сертифікат, спочатку йому потрібно автентифікуватися на сервері. Ви можете використовувати будь-який автентифікатор, який може автентифікувати kubelet.
Хоча будь-яка стратегія автентифікації може бути використана для початкових облікових даних kubelet, рекомендується використовувати наступні два автентифікатори для полегшення надання прав.
Використання токенів початкового завантаження є простішим та зручнішим способом автентифікації kubelet і не вимагає додаткових прапорів при запуску kube-apiserver.
Який би метод ви не обрали, вимога полягає в тому, щоб kubelet міг автентифікуватися як користувач з правами на:
створення та отримання CSRs
автоматичне затвердження запиту клієнтських сертифікатів вузлів, якщо увімкнено автоматичне затвердження.
Kubelet, який автентифікується за допомогою початкових токенів, автентифікується як користувач у групі system:bootstrappers, що є стандартним методом використання.
Оскільки ця функція вдосконалюється, вам слід переконатися, що токени привʼязані до політики управління доступом на основі ролей (RBAC), яка обмежує запити (використовуючи початковий токен) виключно клієнтськими запитами, повʼязаними з наданням сертифікатів. З RBAC можна гнучко налаштовувати обмеження для токенів за групами. Наприклад, ви можете вимкнути доступ певної початкової групи після завершення розгортання вузлів.
Токени початкового завантаження
Токени початкового завантаження докладно описані тут. Це токени, які зберігаються як секрети в кластері Kubernetes і потім видаються окремим kubelet. Ви можете використовувати один токен для всього кластера або видавати по одному на кожен робочий вузол.
Процес складається з двох етапів:
Створити Secret Kubernetes з ідентифікатором токена, секретом і областю(ями).
Видати токен kubelet.
З погляду kubelet, один токен такий самий, як інший і не має особливого значення. З погляду kube-apiserver, однак, початковий токен є особливим. Завдяки його type, namespace і name, kube-apiserver розпізнає його як спеціальний токен і надає будь-кому, хто автентифікується з цим токеном, особливі права початкового завантаження, зокрема, розглядаючи їх як члена групи system:bootstrappers. Це виконує основну вимогу для початкового завантаження TLS.
Якщо ви хочете використовувати токени початкового завантаження, ви повинні увімкнути їх на kube-apiserver з прапорцем:
--enable-bootstrap-token-auth=true
Файл автентифікації токенів
kube-apiserver має можливість приймати токени для автентифікації. Ці токени можуть бути довільними, але повинні представляти щонайменше 128 біт ентропії, отриманих з надійного генератора випадкових чисел (наприклад, /dev/urandom у більшості сучасних Linux-систем). Є кілька способів генерації токена. Наприклад:
head -c 16 /dev/urandom | od -An -t x | tr -d ' '
Це згенерує токени, які виглядають так: 02b50b05283e98dd0fd71db496ef01e8.
Файл токенів повинен виглядати як у наступному прикладі, де перші три значення можуть бути будь-якими, а імʼя групи в лапках повинно бути таким, як показано:
Додайте прапорець --token-auth-file=FILENAME до команди kube-apiserver (можливо, у вашому файлі systemd), щоб увімкнути файл токенів. Докладніше дивіться тут.
Авторизація kubelet на створення CSR
Тепер, коли вузол початкового завантаження автентифікований як частина групи system:bootstrappers, його потрібно авторизувати на створення запиту на підпис сертифіката (CSR), а також на його отримання після завершення. На щастя, Kubernetes постачається з ClusterRole, який має саме ці (і тільки ці) дозволи, system:node-bootstrapper.
Щоб зробити це, потрібно лише створити ClusterRoleBinding, що звʼязує групу system:bootstrappers з кластерною роллю system:node-bootstrapper.
# увімкнення створення CSR для вузлів початкового завантаженняapiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:create-csrs-for-bootstrappingsubjects:- kind:Groupname:system:bootstrappersapiGroup:rbac.authorization.k8s.ioroleRef:kind:ClusterRolename:system:node-bootstrapperapiGroup:rbac.authorization.k8s.io
Налаштування kube-controller-manager
Поки apiserver отримує запити на сертифікати від kubelet і автентифікує ці запити, controller-manager відповідає за видачу фактичних підписаних сертифікатів.
Controller-manager виконує цю функцію через цикл управління видачею сертифікатів. Це реалізується у вигляді локального підписувача cfssl, який використовує активи на диску. Зараз всі видані сертифікати стандартно мають один рік дійсності та набір ключів для використання.
Для того, щоб controller-manager міг підписувати сертифікати, йому потрібно наступне:
доступ до "ключа та сертифіката Kubernetes CA", який ви створили та розповсюдили
увімкнення підписування CSR
Доступ до ключа та сертифіката
Як описано раніше, вам потрібно створити ключ і сертифікат Kubernetes CA і розповсюдити їх на вузли панелі управління. Ці сертифікати будуть використовуватися controller-manager для підписування сертифікатів kubelet.
Оскільки ці підписані сертифікати, своєю чергою, будуть використовуватися kubelet для автентифікації як звичайного kubelet до kube-apiserver, важливо, щоб CA, наданий controller-manager на цьому етапі, також був довірений kube-apiserver для автентифікації. Це надається kube-apiserver за допомогою прапорця --client-ca-file=FILENAME (наприклад, --client-ca-file=/var/lib/kubernetes/ca.pem), як описано в розділі конфігурації kube-apiserver.
Щоб надати ключ і сертифікат Kubernetes CA для kube-controller-manager, використовуйте наступні прапорці:
Тривалість дійсності підписаних сертифікатів можна налаштувати за допомогою прапорця:
--cluster-signing-duration
Затвердження
Щоб затвердити CSR, потрібно вказати controller-manager, що їх можна затверджувати. Це робиться шляхом надання прав доступу RBAC потрібній групі.
Існують два різні набори дозволів:
nodeclient: Якщо вузол створює новий сертифікат для вузла, тоді у нього ще немає сертифіката. Він автентифікується за допомогою одного з токенів, зазначених вище, і таким чином є частиною групи system:bootstrappers.
selfnodeclient: Якщо вузол оновлює свій сертифікат, тоді у нього вже є сертифікат (за визначенням), який він використовує для автентифікації як частина групи system:nodes.
Щоб дозволити kubelet запитувати та отримувати новий сертифікат, створіть ClusterRoleBinding, що звʼязує групу, в якій є членом вузол початкового завантаження, system:bootstrappers, з ClusterRole, що надає їй дозвіл, system:certificates.k8s.io:certificatesigningrequests:nodeclient:
# Затвердження всіх CSR для групи "system:bootstrappers"apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:auto-approve-csrs-for-groupsubjects:- kind:Groupname:system:bootstrappersapiGroup:rbac.authorization.k8s.ioroleRef:kind:ClusterRolename:system:certificates.k8s.io:certificatesigningrequests:nodeclientapiGroup:rbac.authorization.k8s.io
Щоб дозволити kubelet оновлювати власний клієнтський сертифікат, створіть ClusterRoleBinding, що звʼязує групу, в якій є членом повнофункціональний вузол, system:nodes, з ClusterRole, що
надає їй дозвіл, system:certificates.k8s.io:certificatesigningrequests:selfnodeclient:
# Затвердження запитів на оновлення CSR для групи "system:nodes"apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:auto-approve-renewals-for-nodessubjects:- kind:Groupname:system:nodesapiGroup:rbac.authorization.k8s.ioroleRef:kind:ClusterRolename:system:certificates.k8s.io:certificatesigningrequests:selfnodeclientapiGroup:rbac.authorization.k8s.io
Контролер csrapproving, який постачається як частина kube-controller-manager, стандартно увімкнено. Контролер використовує API SubjectAccessReview для визначення, чи авторизований користувач для запиту CSR, а потім затверджує на основі результатів авторизації. Щоб уникнути конфліктів з іншими затверджувачами, вбудований затверджувач не відхиляє CSR явним чином. Він лише ігнорує неавторизовані запити. Контролер також видаляє прострочені сертифікати в рамках збору сміття.
Налаштування kubelet
Нарешті, з правильно налаштованими вузлами панелі управління та всією необхідною автентифікацією та авторизацією, ми можемо налаштувати kubelet.
Для початкового завантаження kubelet потрібна наступна конфігурація:
Шлях для зберігання ключа та сертифіката, які він генерує (опціонально, можна використовувати стандартні)
Шлях до файлу kubeconfig, який ще не існує; тут буде збережено конфігураційний файл після початкового завантаження
Шлях до початкового файлу kubeconfig, що містить URL сервера та початкові облікові дані, наприклад, початковий токен
Опціонально: інструкції щодо ротації сертифікатів
Початковий файл kubeconfig має бути в шляху, доступному для kubelet, наприклад /var/lib/kubelet/bootstrap-kubeconfig.
Його формат ідентичний звичайному файлу kubeconfig. Приклад файлу може виглядати наступним чином:
certificate-authority: шлях до файлу CA, використовується для перевірки сертифіката сервера, представленого kube-apiserver
server: URL до kube-apiserver
token: токен для використання
Формат токена не має значення, головне, щоб він відповідав очікуванням kube-apiserver. У наведеному прикладі ми використали початковий токен. Як зазначалося раніше, будь-який дійсний метод автентифікації може бути використаний, а не тільки токени.
Оскільки початковий kubeconfigє стандартним kubeconfig, ви можете використовувати kubectl для його створення. Щоб створити вищезазначений приклад файлу:
Під час запуску kubelet, якщо файл, вказаний через --kubeconfig, не існує, початковий kubeconfig, вказаний через --bootstrap-kubeconfig, використовується для запиту клієнтського сертифіката від API сервера. Після затвердження запиту на сертифікат і його отримання kubelet, конфігураційний файл kubeconfig, що посилається на згенерований ключ і отриманий сертифікат, буде записаний у шлях, вказаний за допомогою --kubeconfig. Файл сертифіката і ключа буде розміщено в теці, вказаній прапорцем --cert-dir.
Клієнтські та серверні сертифікати
Все вищезазначене стосується клієнтських сертифікатів kubelet, зокрема сертифікатів, які kubelet використовує для автентифікації до kube-apiserver.
kubelet також може використовувати серверні сертифікати. Сам kubelet відкриває https-точку доступу для певних функцій. Для їх захисту, kubelet може робити одне з наступного:
використовувати наданий ключ та сертифікат через прапорці --tls-private-key-file та --tls-cert-file
створити самопідписаний ключ та сертифікат, якщо ключ та сертифікат не надані
запитати серверні сертифікати у сервера кластера через API CSR
Клієнтський сертифікат, наданий під час початкового завантаження TLS, стандартно підписується лише для client auth і, отже, не може використовуватися як серверний сертифікат, або server auth.
Однак, ви можете увімкнути його серверний сертифікат, принаймні частково, через ротацію сертифікатів.
Ротація сертифікатів
З версії Kubernetes v1.8 та вище kubelet реалізує функції для увімкнення ротації його клієнтських і/або серверних сертифікатів. Зверніть увагу, що ротація серверного сертифіката є бета функцією та потребує функціональної можливості RotateKubeletServerCertificate на kubelet (стандартно увімкнено).
Ви можете налаштувати kubelet для ротації його клієнтських сертифікатів, створюючи нові CSRs при закінченні терміну дії його поточних облікових даних. Щоб увімкнути цю функцію, використовуйте поле rotateCertificates у файлі конфігурації kubelet або передайте наступний аргумент командного рядка kubelet (застаріло):
--rotate-certificates
Увімкнення RotateKubeletServerCertificate призводить до того, що kubelet одночасно
запитує серверний сертифікат після початкового завантаження своїх клієнтських облікових даних і ротує цей сертифікат. Щоб увімкнути цю поведінку, використовуйте поле serverTLSBootstrap у файлі конфігурації kubelet або передайте наступний аргумент командного рядка kubelet (застаріло):
--rotate-server-certificates
Примітка:
Контролери, що затверджують CSR, реалізовані в ядрі Kubernetes, не затверджують серверні сертифікати вузла з міркувань безпеки. Для використання RotateKubeletServerCertificate операторам потрібно запустити власний контролер затвердження або вручну затвердити запити на серверні сертифікати.
Процес затвердження серверних сертифікатів kubelet, специфічний для розгортання, зазвичай повинен затверджувати лише CSRs, які:
запитані вузлами (забезпечте, що поле spec.username має форму system:node:<nodeName> і spec.groups містить system:nodes)
запитують використання для серверного сертифіката (забезпечте, що spec.usages містить server auth, додатково містить digital signature та key encipherment, і не містить інших використань)
мають лише IP та DNS subjectAltNames, які належать запитуючому вузлу, і не мають URI та Email subjectAltNames (розібрати x509 Certificate Signing Request в spec.request, щоб перевірити subjectAltNames)
Інші складові автентифікації
Усі процеси завантаження TLS, описані у цьому документі, стосуються kubelet. Однак інші компоненти можуть потребувати прямого звʼязку з kube-apiserver. Особливо важливим є kube-proxy, який є частиною компонентів вузла Kubernetes і запускається на кожному вузлі, але може також включати інші компоненти, такі як моніторинг чи роботу з мережею.
Подібно до kubelet, цим іншим компонентам також потрібен метод автентифікації у kube-apiserver. У вас є кілька варіантів для генерації цих облікових даних:
Традиційний спосіб: Створіть і розповсюдьте сертифікати так само як ви це робили для kubelet перед завантаженням TLS.
DaemonSet: Оскільки сам kubelet завантажується на кожний вузол і достатньо для запуску базових служб, ви можете запускати kube-proxy та інші служби, специфічні для вузла, не як самостійний процес, а як daemonset у просторі імен kube-system. Оскільки він буде в кластері, ви можете надати йому відповідний службовий обліковий запис з відповідними дозволами для виконання своїх дій. Це може бути найпростішим способом налаштування таких служб.
Затвердження за допомогою kubectl
Запити на сертифікати можна затвердити поза процесом затвердження, вбудованим у контролер
керування.
Контролер підпису не негайно підписує всі запити на сертифікати. Замість цього він чекає, доки вони не будуть позначені статусом "Approved" відповіднbv привілейованим користувачем. Цей процес призначений для того, щоб дозволити автоматичне затвердження, яке обробляється зовнішнім контролером затвердження або controller-manager, реалізованим в основному controller-manager. Однак адміністратори кластера також можуть вручну затверджувати запити на сертифікати за допомогою kubectl. Адміністратор може отримати перелік CSRs за допомогою kubectl get csr та детально описати один з них за допомогою kubectl describe csr <name>. Адміністратор може затвердити або відхилити CSR за допомогою kubectl certificate approve <name> та kubectl certificate deny <name>.
3.15 - Правила перевірки допуску
СТАН ФУНКЦІОНАЛУ:Kubernetes v1.30 [stable]
Ця сторінка надає огляд правил перевірки допуску.
Що таке правила перевірки допуску?
Правила перевірки допуску пропонують декларативну, вбудовану альтернативу веб-хукам перевірки допуску.
Правила перевірки допуску використовують мову загальних виразів (Common Expression Language, CEL). Правила перевірки допуску мають високу налаштовуваність, що дозволяє авторам визначати правила, які можуть бути параметризовані та обмежені ресурсами за необхідності адміністраторами кластера.
Які ресурси складають правила
Зазвичай правило складається з трьох ресурсів:
ValidatingAdmissionPolicy описує абстрактну логіку правил (наприклад: "ці праивла переконуються, що певна мітка встановлена у певне значення").
ValidatingAdmissionPolicyBinding повʼязує вищезазначені ресурси разом і надає обмеження області дії. Якщо вам потрібно вимагати встановлення мітки owner для Pods, привʼязка визначає, де ви будете вказувати це обмеження.
Ресурс параметра надає інформацію для ValidatingAdmissionPolicy, щоб зробити його конкретним висловленням (наприклад, "мітка owner повинна бути встановлена на щось, що закінчується на .company.com"). Вбудований тип, такий як ConfigMap або CRD, визначає схему ресурсу параметра. Обʼєкти ValidatingAdmissionPolicy вказують, який Kind вони очікують для свого ресурсу параметру.
Для того щоб правила мали ефект, обовʼязково повинні бути визначені принаймні ValidatingAdmissionPolicy та відповідне ValidatingAdmissionPolicyBinding.
Якщо ValidatingAdmissionPolicy не потребує налаштування через параметри, просто залиште
spec.paramKind в ValidatingAdmissionPolicy не вказаним.
Переконайтеся, що API admissionregistration.k8s.io/v1beta1 увімкнено.
Початок роботи з правилами перевірки допуску
Правила перевірки допуску є частиною панелі управління кластера. Ви повинні писати та розгортати їх з великою обережністю. Нижче наведено інструкції щодо швидкого експерименту з правилами перевірки допуску.
spec.validations містить вирази CEL, які використовують Мову загальних виразів (CEL), щоб перевірити запит. Якщо вираз обчислюється як false, перевірка валідації застосовується згідно з полем spec.failurePolicy.
Примітка:
Ви можете швидко перевірити вирази CEL у пісочниці CEL.
Для налаштування правил перевірки допуску для використання в кластері потрібна привʼязка. Нижче наведено приклад ValidatingAdmissionPolicyBinding.:
Вище наведено простий приклад використання ValidatingAdmissionPolicy без налаштованого параметра.
Дії валідації
Кожний ValidatingAdmissionPolicyBinding повинен вказати одну або декілька validationActions, щоб визначити, як validations правила будуть застосовані.
Підтримувані validationActions:
Deny: Невдалий результат валідації призводить до відхиленого запиту.
Warn: Невдалий результат валідації повідомляється клієнту запиту як попередження.
Audit: Невдалий результат валідації включається в подію аудиту для запиту до API.
Наприклад, щоб одночасно попереджувати клієнтів про невдалий результат валідації та аудитувати невдалий результат валідації, використовуйте:
validationActions:[Warn, Audit]
Deny та Warn не можуть бути використані разом, оскільки ця комбінація надмірно дублює невдалий результат валідації як у тілі відповіді API, так і в HTTP заголовках попередження.
validation, який оцінюється як false, завжди застосовується відповідно до цих дій. Невдачі, визначені полем failurePolicy, застосовуються відповідно до цих дій тільки у випадку, якщо failurePolicy встановлено на Fail (або не вказано), інакше невдачі ігноруються.
Ресурси параметрів дозволяють відокремити конфігурацію правил від їх визначення. Правило може визначити paramKind, який визначає GVK ресурсу параметра, а потім привʼязка правила повʼязує його за іменем (через policyName) з певним ресурсом параметра через paramRef.
Якщо потрібна конфігурація параметра, наведено приклад ValidatingAdmissionPolicy з конфігурацією параметра.
Поле spec.paramKind ValidatingAdmissionPolicy вказує на вид використовуваних ресурсів для параметризації цього правила. У цьому прикладі це налаштовано за допомогою ресурсів ReplicaLimit. Зверніть увагу в цьому прикладі, як вираз CEL посилається на параметри через змінну CEL params, наприклад, params.maxReplicas. spec.matchConstraints вказує, для яких ресурсів ця правило призначена для валідації. Зверніть увагу, що як параметр можуть використовуватися і стандартні типи, такі як ConfigMap.
Поля spec.validations містять вирази CEL. Якщо вираз оцінюється як false, то валідаційна перевірка здійснюється відповідно до поля spec.failurePolicy.
Автор правил перевірки допуску відповідає за надання параметра CRD ReplicaLimit.
Для налаштування правил перевірки допуску для використання в кластері створюються привʼязка та ресурс параметра. Наведено приклад ValidatingAdmissionPolicyBinding який використовує кластерний параметр — той самий параметр буде використовуватися для валідації кожного запиту до ресурсу, який відповідає привʼязці:
Цей ресурс параметра правил обмежує Deployments до максимуму 3 репліки.
В правилі допуску може бути кілька привʼязок. Щоб привʼязати всі інші середовища до обмеження maxReplicas 100, створіть інший ValidatingAdmissionPolicyBinding:
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingAdmissionPolicyBindingmetadata:name:"replicalimit-binding-nontest"spec:policyName:"replicalimit-policy.example.com"validationActions:[Deny]paramRef:name:"replica-limit-prod.example.com"namespace:"default"matchResources:namespaceSelector:matchExpressions:- key:environmentoperator:NotInvalues:- test
Зверніть увагу, що ця привʼязка застосовує різний параметр до ресурсів, які не знаходяться в середовищі test.
Для кожного запиту на допуск, сервер API оцінює вирази CEL кожної комбінації (правило, привʼязка, параметр), які відповідають запиту. Для того, щоб запит був прийнятий, він повинен пройти всі оцінки.
Якщо кілька привʼязок відповідають запиту, правило буде оцінено для кожної, і вони всі повинні пройти оцінку, щоб правило вважали пройденим.
Якщо кілька параметрів відповідають одній привʼязці, правила будуть оцінені для кожного параметра, і вони також повинні всі пройти, щоб привʼязка вважалася пройденою. Привʼязки можуть мати критерії відповідності, що перекриваються. Правило оцінюється для кожної відповідної комбінації привʼязка-параметр. Правило може бути оцінено навіть кілька разів, якщо йому відповідає кілька привʼязок, або одна привʼязка, яка відповідає кільком параметрам.
Обʼєкт params, який представляє ресурс параметра, не буде встановлений, якщо ресурс параметра не був привʼязаний, тому для правил, які потребують ресурсу параметра, може бути корисно додати перевірку, щоб забезпечити його привʼязку. Ресурс параметра не буде привʼязаний і params буде null, якщо paramKind правила або paramRef привʼязки не вказані.
Для випадків використання, що потребують конфігурації параметра, ми рекомендуємо додати перевірку параметра в spec.validations[0].expression:
- expression: "params != null"
message: "params missing but required to bind to this policy"
Необовʼязкові параметри
Буває зручно мати можливість мати необовʼязкові параметри як частину ресурсу параметра і валідувати їх лише в разі їх присутності. У CEL є has(), який перевіряє, чи існує переданий ключ. Крім того, CEL реалізує булеве скорочення. Якщо перша половина логічного ОБО відноситься до true, то друга половина не оцінюється (оскільки результат усього ОБО буде true в будь-якому випадку).
Поєднуючи ці дві можливості, ми можемо забезпечити можливість валідації необовʼязкових параметрів:
Тут спочатку ми перевіряємо, що необовʼязковий параметр присутній за допомогою !has(params.optionalNumber).
Якщо optionalNumber не був визначений, то вираз скорочується, оскільки
!has(params.optionalNumber) оцінюється як true.
Якщо optionalNumber був визначений, тоді друга половина CEL виразу буде
оцінена, і optionalNumber буде перевірений, щоб забезпечити, що він містить значення від 5 до 10 включно.
Параметри на рівні простору імен
Як автор ValidatingAdmissionPolicy та його ValidatingAdmissionPolicyBinding, ви можете вибрати, чи вказувати параметри на рівні кластера або на рівні простору імен. Якщо ви вказуєте namespace для paramRef привʼязки, панель управління шукає параметри лише в цьому просторі імен.
Проте, якщо namespace не вказано в ValidatingAdmissionPolicyBinding, сервер API може шукати відповідні параметри в просторі імен, до якого відноситься запит. Наприклад, якщо ви робите запит на зміну ConfigMap у просторі імен default, і існує відповідна ValidatingAdmissionPolicyBinding без вказаного namespace, то сервер API шукає обʼєкт параметра в default. Цей дизайн дозволяє конфігурувати правило, що залежить від простору імен ресурсу, який обробляється, для отримання більш точного контролю.
Селектор параметрів
Крім вказання параметра у привʼязці за допомогою name, ви можете вибрати замість цього вказати селектор міток, таким чином, всі ресурси paramKind правила та namespace параметра (якщо застосовується), які відповідають селектору міток, вибираються для оцінки. Див. селектор для отримання додаткової інформації про те, як селектори міток відбирають ресурси.
Якщо умову виконується для декількох параметрів, правила оцінюються для кожного знайденого параметра, а результати будуть оцінені разом через логічне І (AND).
Якщо надано namespace, для вибору допускаються лише обʼєкти paramKind у вказаному просторі імен. В іншому випадку, коли namespace порожній, а paramKind обмежений простором імен, використовується namespace, використаний у запиті для допуску.
Перевірка авторизації
Ми ввели перевірку авторизації для ресурсів параметрів. Очікується, що користувач матиме доступ на читання до ресурсів, на які посилається paramKind у ValidatingAdmissionPolicy та paramRef у ValidatingAdmissionPolicyBinding.
Зверніть увагу, що якщо ресурс у paramKind не вдасться знайти через restmapper, потрібен доступ на читання до всіх ресурсів груп.
Правило помилок
failurePolicy визначає, як обробляються неправильні конфігурації та вирази CEL, що викликають помилку в правилах перевірки допуску. Допустимі значення: Ignore або Fail.
Ignore означає, що помилка під час виклику ValidatingAdmissionPolicy ігнорується, і запит API може продовжуватися.
Fail означає, що помилка під час виклику ValidatingAdmissionPolicy призводить до відмови в прийнятті та відхилення запиту API.
Зверніть увагу, що failurePolicy визначається всередині ValidatingAdmissionPolicy:
spec.validations[i].expression представляє вираз, який буде оцінений за допомогою CEL. Для отримання додаткової інформації див. Специфікацію мови CEL. Вирази CEL мають доступ до вмісту запиту/відповіді допуску, організованого в змінні CEL, а також деяких інших корисних змінних:
'object' — Обʼєкт з вхідного запиту. Значення null для запитів DELETE.
'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE.
'params' — Ресурс параметра, на який посилається привʼязка правила, яке оцінюється. Значення null, якщо ParamKind не вказано.
namespaceObject — Простір імен, як ресурс Kubernetes, до якого належить вхідний обʼєкт. Значення null, якщо вхідний обʼєкт має область видимості кластера.
authorizer — Авторизатор CEL. Може використовуватися для виконання перевірок авторизації для принципала (автентифікованого користувача) запиту. Див. Authz в документації бібліотеки Kubernetes CEL для отримання додаткових відомостей.
authorizer.requestResource — Скорочення для перевірки авторизації, налаштоване з ресурсом запиту (група, ресурс, (субресурс), простір імен, імʼя).
apiVersion, kind, metadata.name і metadata.generateName завжди доступні з кореня обʼєкта. Інші властивості метаданих не доступні.
Рівність у масивах із типом списку 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація у масивах з x-kubernetes-list-type використовує семантику типу списку:
'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів в X зберігаються, а
неперетинаючися елементи в Y додаються, зберігаючи їх частковий порядок.
'map': X + Y виконує злиття, де позиції масиву всіх ключів в X зберігаються, але значення
перезаписуються значеннями в Y, коли множини ключів X і Y перетинаються. Елементи в Y з неперетинаючимися ключами додаються, зберігаючи їх частковий порядок.
spec.validation[i].reason представляє машинночитаний опис причини невдачі цієї валідації. Якщо це перша валідація в списку, яка завершується невдачею, ця причина, а також відповідний код відповіді HTTP використовуються у відповіді HTTP клієнту. Підтримувані зараз причини: Unauthorized, Forbidden, Invalid, RequestEntityTooLarge. Якщо не встановлено, StatusReasonInvalid використовується у відповіді клієнту.
Відповідність запитів: matchConditions
Ви можете визначити умови відповідності для ValidatingAdmissionPolicy, якщо вам потрібно дотримуватися детального фільтрування запитів. Ці умови корисні, якщо ви виявите, що правила відповідності, objectSelectors та namespaceSelectors все ще не забезпечують потрібного фільтрування. Умови відповідності — це вирази CEL. Усі умови відповідності повинні оцінюватися як true для ресурсу, який має бути оцінений.
Нижче наведено приклад, що ілюструє кілька різних використань умов відповідності:
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingAdmissionPolicymetadata:name:"demo-policy.example.com"spec:failurePolicy:FailmatchConstraints:resourceRules:- apiGroups:["*"]apiVersions:["*"]operations:["CREATE","UPDATE"]resources:["*"]matchConditions:- name:'exclude-leases'# Імʼя кожної умови має бути унікальнимexpression:'!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")'# Шукати збіг із запитами non-lease.- name:'exclude-kubelet-requests'expression:'!("system:nodes" in request.userInfo.groups)'# Шукати збіг із запитами від користувачів, які не є користувачами вузла.- name:'rbac'# Оминати запити RBAC.expression:'request.resource.group != "rbac.authorization.k8s.io"'validations:- expression:"!object.metadata.name.contains('demo') || object.metadata.namespace == 'demo'"
Умови відповідності мають доступ до тих самих змінних CEL, що й вирази валідації.
У випадку помилки при оцінці умови відповідності правило не оцінюється. Рішення про відхилення запиту визначається наступним чином:
Якщо будь-яка умова відповідності оцінюється як false (незалежно від інших помилок), сервер API пропускає політику.
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingAdmissionPolicymetadata:name:"demo-policy.example.com"spec:failurePolicy:FailmatchConstraints:resourceRules:- apiGroups:["apps"]apiVersions:["v1"]operations:["CREATE","UPDATE"]resources:["deployments"]validations:- key:"high-replica-count"expression:"object.spec.replicas > 50"messageExpression:"'Deployment spec.replicas set to ' + string(object.spec.replicas)"
Коли запит API перевіряється за цим правилом допуску, отримана подія аудиту буде виглядати так:
#Записанаподіяаудиту{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"annotations": {
"demo-policy.example.com/high-replica-count": "Deployment spec.replicas set to 128"#іншіанотації... }
#іншіполя...}
У цьому прикладі анотація буде включена лише тоді, коли spec.replicas у Deployment більше 50, в іншому випадку вираз CEL оцінюється як null, і анотація не буде включена.
Зверніть увагу, що ключі анотацій аудиту мають префікс з імʼям ValidatingAdmissionWebhook та /. Якщо інший контролер допуску, такий як вебхук допуску, використовує точно такий самий ключ анотації аудиту, то значення першого контролера допуску, який включає анотацію аудиту, буде включено в аудит-подію, а всі інші значення будуть ігноруватися.
Вираз повідомлення
Щоб повертати більш дружнє повідомлення, коли правило відхиляє запит, ми можемо використовувати вираз CEL для створення повідомлення з spec.validations[i].messageExpression. Подібно до виразу валідації, вираз повідомлення має доступ до object, oldObject, request, params та namespaceObject. На відміну від валідації, вираз повідомлення має повертати рядок.
Наприклад, щоб краще інформувати користувача про причину відхилення, коли правило посилається на параметр, ми можемо мати наступну валідацію:
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingAdmissionPolicymetadata:name:"deploy-replica-policy.example.com"spec:paramKind:apiVersion:rules.example.com/v1kind:ReplicaLimitmatchConstraints:resourceRules:- apiGroups:["apps"]apiVersions:["v1"]operations:["CREATE","UPDATE"]resources:["deployments"]validations:- expression:"object.spec.replicas <= params.maxReplicas"messageExpression:"'object.spec.replicas must be no greater than ' + string(params.maxReplicas)"reason:Invalid
Після створення обʼєкту параметрів, який обмежує репліки до 3 та налаштування привʼязки, коли ми спробуємо створити Deployment з 5 репліками, ми отримаємо наступне повідомлення.
$ kubectl create deploy --image=nginx nginx --replicas=5error: failed to create deployment: deployments.apps "nginx" is forbidden: ValidatingAdmissionPolicy 'deploy-replica-policy.example.com' with binding 'demo-binding-test.example.com' denied request: object.spec.replicas must be no greater than 3
Це більш інформативно, ніж статичне повідомлення "занадто багато реплік".
Вираз повідомлення має перевагу над статичним повідомленням, визначеним у spec.validations[i].message, якщо обидва визначені. Однак, якщо вираз повідомлення не вдається оцінити, буде використано статичне повідомлення. Крім того, якщо вираз повідомлення оцінюється як багаторядковий рядок, результат оцінки буде відкинутий, і використовуватиметься статичне повідомлення, якщо воно присутнє. Зауважте, що статичне повідомлення перевіряється на відповідність багаторядковим рядкам.
Перевірка типів
Під час створення або оновлення визначення правил валідації процес валідації аналізує вирази, які він містить, та повідомляє про будь-які синтаксичні помилки, відхиляючи визначення, якщо виявлено помилки. Потім перевіряються змінні, на які є посилання, на наявність помилок типів, включаючи відсутні поля та плутанину типів, відносно відповідних типів spec.matchConstraints. Результат перевірки типів можна отримати з status.typeChecking. Наявність status.typeChecking вказує на завершення перевірки типів, а порожнє status.typeChecking означає, що помилок не виявлено.
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingAdmissionPolicymetadata:name:"deploy-replica-policy.example.com"spec:matchConstraints:resourceRules:- apiGroups:["apps"]apiVersions:["v1"]operations:["CREATE","UPDATE"]resources:["deployments"]validations:- expression:"object.replicas > 1"# має бути "object.spec.replicas > 1"message:"must be replicated"reason:Invalid
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingAdmissionPolicymetadata:name:"replica-policy.example.com"spec:matchConstraints:resourceRules:- apiGroups:["apps"]apiVersions:["v1"]operations:["CREATE","UPDATE"]resources:["deployments","replicasets"]validations:- expression:"object.replicas > 1"# має бути "object.spec.replicas > 1"message:"must be replicated"reason:Invalid
буде мати декілька типів та результат перевірки типів кожного типу у повідомленні про попередження.
Відсутнє зіставлення за шаблоном. Якщо spec.matchConstraints.resourceRules містить "*" у будь-якому з apiGroups, apiVersions або resources, типи, які відповідають "*", не будуть перевірені.
Кількість збігів типів обмежена до 10. Це робиться для запобігання використанню правил, що вручну вказує занадто багато типів, що може споживати занадто багато обчислювальних ресурсів. Порядок спадання групи, версії, а потім ресурсу, 11-а комбінація та після буде ігноруватися.
Перевірка типів не впливає на поведінку правил жодним чином. Навіть якщо під час перевірки типів виявляються помилки, політика буде продовжувати оцінюватися. Якщо під час оцінки виникають помилки, політика вибере свій результат.
Перевірка типів не застосовується до CRD, включаючи відповідні типи CRD та посилання на paramKind. Підтримка CRD зʼявиться у майбутній версії.
Склад змінних
Якщо вираз стає занадто складним або частина виразу повторно використовується та має високі обчислювальні витрати, ви можете винести частину виразів у змінні. Змінна — це вираз з назвою, на який можна посилатися пізніше в variables в інших виразах.
Змінна оцінюється ліниво (lazily), під час першого посилання на неї. Про будь-яку помилку, що виникає під час оцінки, буде повідомлено під час оцінки вказаного виразу, на який посилається змінна. Як результат, так і можлива помилка запамʼятовуються і лише один раз враховуються при оцінці під час виконання.
Порядок змінних важливий, оскільки змінна може посилатися на інші змінні, які визначені перед нею. Це упорядкування запобігає циклічним посиланням.
Наведено більш складний приклад змінних, що забезпечує відповідність імен репозиторіїв образів середовищу, визначеному у просторі імен.
# Це правило забезпечує виконання умови, що всі контейнери deployment повинні мати збіг репозиторієв образів з міткою середовища його простору імен.# За винятком deployment, позначених як "exempt", або будь-яких контейнерів, які не належать організації "example.com" (наприклад, загальні sidecar).# Наприклад, якщо у просторі імен є мітка {"environment": "staging"}, всі контейнери повинні мати репозиторій, який є або staging.example.com/*# або не містить "example.com" взагалі, якщо deployment має мітку {"exempt": "true"}.apiVersion:admissionregistration.k8s.io/v1kind:ValidatingAdmissionPolicymetadata:name:"image-matches-namespace-environment.policy.example.com"spec:failurePolicy:FailmatchConstraints:resourceRules:- apiGroups:["apps"]apiVersions:["v1"]operations:["CREATE","UPDATE"]resources:["deployments"]variables:- name:environmentexpression:"'environment' in namespaceObject.metadata.labels ? namespaceObject.metadata.labels['environment'] : 'prod'"- name:exemptexpression:"'exempt' in object.metadata.labels && object.metadata.labels['exempt'] == 'true'"- name:containersexpression:"object.spec.template.spec.containers"- name:containersToCheckexpression:"variables.containers.filter(c, c.image.contains('example.com/'))"validations:- expression:"variables.exempt || variables.containersToCheck.all(c, c.image.startsWith(variables.environment + '.'))"messageExpression:"'only ' + variables.environment + ' images are allowed in namespace ' + namespaceObject.metadata.name"
З правилом, привʼязаним до простору імен default, який має мітку environment: prod, спроба створити Deployment буде відхилена.
error: failed to create deployment: deployments.apps "invalid" is forbidden: ValidatingAdmissionPolicy 'image-matches-namespace-environment.policy.example.com' with binding 'demo-binding-test.example.com' denied request: only prod images are allowed in namespace default
4 - Відомі мітки, анотації та позначення
Kubernetes зберігає всі мітки та анотації в просторах імен kubernetes.io і k8s.io.
Цей документ одночасно є і довідником, і точкою для призначення значень.
Мітки, анотації та позначення, використані в обʼєктах API
Якщо ця анотація встановлена в значення true для FlowSchema або PriorityLevelConfiguration, то spec для цього обʼєкта управляється kube-apiserver. Якщо сервер API не розпізнає обʼєкт APF, а ви анотуєте його для автоматичного оновлення, сервер API видаляє весь обʼєкт. У іншому випадку сервер API не управляє специфікацією обʼєкта. Докладніше читайте Обслуговування обовʼязкових та рекомендованих обʼєктів конфігурації.
Використовується для: Обʼєкти, які використовуються як батьки ApplySet.
Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.30 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.
Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського обʼєкта, який використовується для відстеження ApplySet для розширення області застосування ApplySet поза власним простором імен батьківського обʼєкта (якщо є). Значення — це розділені комами імена просторів імен, в яких знаходяться обʼєкти, відмінні від простору імен батьківського обʼєкта.
Використовується для: Обʼєкти, які використовуються як батьки ApplySet.
Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.30 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.
Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського об’єкта, який використовується для відстеження ApplySet для оптимізації списку об’єктів-членів ApplySet. Не є обовʼязковою у специфікації ApplySet, оскільки інструменти можуть виконувати виявлення або використовувати іншу оптимізацію. Однак, починаючи з версії Kubernetes 1.30, kubectl вимагає її наявності. Якщо присутнє, значення цієї анотації має бути розділеним комами списком типів груп у форматі повної назви, тобто. <resource>.<group>.
Використовується для: Обʼєкти, які використовуються як батьки ApplySet.
Використання цієї мітки є альфа-версією. Для Kubernetes версії 1.30 ви можете використовувати цю мітку на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.
Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця мітка робить об’єкт батьківським об’єктом ApplySet. Його значенням є унікальний ідентифікатор ApplySet, який походить від ідентифікатора самого батьківського об’єкта. Цей ідентифікатор повинен бути кодуванням base64 (з використанням безпечного для URL кодування RFC4648) хешу group-kind-name-namespace обʼєкта, на якому він знаходиться, у вигляді: <base64(sha256(<name>.<namespace>.<kind>.<group>))>. Між значенням цієї мітки та UID обʼєкта немає звʼязку.
Використовується для: Custom Resource Definition (CRD)
Використання цієї мітки є альфа-версією. Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ви можете встановити цю мітку на CustomResourceDefinition (CRD), щоб ідентифікувати тип власного ресурсу, який він визначає (а не сам CRD) як дозволеного батька для ApplySet. Єдиним допустимим значенням для цієї мітки є "true"; якщо ви хочете позначити CRD як такий, що не є дійсним батьком для ApplySets, пропустіть цю мітку.
Використання цієї мітки є альфа-версією. Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця мітка робить обʼєкт членом ApplySet. Значення мітки повинно збігатися зі значенням мітки applyset.kubernetes.io/id у батьківському обʼєкті.
Використовується для: Обʼєкти, які використовуються як батьки ApplySet.
Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.30 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.
Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського обʼєкта, який використовується для відстеження ApplySet, щоб вказати, який інструментарій керує цим ApplySet. Інструментарій повинен відмовлятися змінювати ApplySets, що належать іншим інструментам. Значення має бути у форматі <toolname>/<semver>.
apps.kubernetes.io/pod-index (beta)
Тип: Label
Приклад: apps.kubernetes.io/pod-index: "0"
Використовується для: Pod
Коли контролер StatefulSet створює Pod для StatefulSet, він встановлює цю мітку на Pod. Значення мітки є порядковим індексом створюваного Podʼа.
Дивіться Мітка індексу Podʼа в темі StatefulSet для отримання більш детальної інформації. Зверніть увагу на PodIndexLabel, має бути увімкнено, щоб цю мітку можна було додати до Podʼів.
Коли ця анотація має значення "true", автомасштабувальнику кластера дозволяється виселяти Pod навіть якщо інші правила зазвичай забороняють це робити. Автомасштабувальник кластера ніколи не виселяє Podʼи, для яких ця анотація явно встановлена у значення "false"; ви можете встановити це значення для важливого Podʼа, який ви хочете продовжувати виконувати. Якщо цю анотацію не задано, то автомасштабувальник кластера поводитиметься так, як він поводиться на рівні Podʼа.
Ця анотація використовується у маніфестах для позначення обʼєкта як локальної конфігурації, яку не слід передавати до API Kubernetes.
Значення "true" для цієї анотації вказує, що обʼєкт використовується лише клієнтськими інструментами і не повинен бути надісланий на сервер API.
Значення "false" може бути використане для вказівки, що обʼєкт повинен бути надісланий на сервер API, навіть якщо в іншому випадку він вважався б локальним.
Ця анотація є частиною специфікації функцій Kubernetes Resource Model (KRM), яка використовується Kustomize та подібними сторонніми інструментами. Наприклад, Kustomize видаляє обʼєкти з цією анотацією з кінцевого результату збирання коду.
Ця анотація дозволяє вам вказати профіль безпеки AppArmor для контейнера в межах Podʼа Kubernetes. Починаючи з версії Kubernetes 1.30, це слід налаштовувати за допомогою поля appArmorProfile. Щоб дізнатися більше, перегляньте підручник з AppArmor. У підручнику показано, як використовувати AppArmor для обмеження можливостей і доступу контейнера.
Вказаний профіль визначає набір правил і обмежень, яких повинен дотримуватися процес у контейнері. Це допомагає забезпечити дотримання політик безпеки та ізоляцію ваших контейнерів.
internal.config.kubernetes.io/* (reserved prefix)
Тип: Annotation
Використовується для: Всі обʼєкти
Цей префікс зарезервований для внутрішнього використання інструментами, які діють як оркестратори відповідно до специфікації функцій Моделі Ресурсів Kubernetes (KRM). Анотації з цим префіксом є внутрішніми для процесу оркестрування та не зберігаються в маніфестах у файловій системі. Іншими словами, інструмент-оркестратор повинен встановлювати ці анотації при зчитуванні файлів з локальної файлової системи та видаляти їх при записі результатів роботи функцій назад у файлову систему.
Функція KRM не повинна змінювати анотації з цим префіксом, якщо не зазначено інше для конкретної анотації. Це дозволяє інструментам оркестрування додавати додаткові внутрішні анотації без необхідності вносити зміни в існуючі функції.
Ця анотація записує шлях до файлу маніфесту, з якого було завантажено обʼєкт, у вигляді розділеного слешами, незалежного від ОС, відносного шляху. Шлях є відносним до фіксованого розташування у файловій системі, визначеного інструментом-оркестратором.
Ця анотація є частиною специфікації функцій Моделі Ресурсів Kubernetes (KRM), яка використовується Kustomize та подібними сторонніми інструментами.
Функція KRM не повинна змінювати цю анотацію у вхідних обʼєктах, якщо вона не змінює файли, на які посилається. Функція KRM може включати цю анотацію у обʼєкти, які вона генерує.
internal.config.kubernetes.io/index
Тип: Annotation
Приклад: internal.config.kubernetes.io/index: "2"
Використовується для: Всі обʼєкти
Ця анотація записує позицію (нумерація з нуля) YAML-документа, який містить обʼєкт, у файлі маніфесту, з якого було завантажено обʼєкт. Зазначимо, що YAML-документи розділяються трьома тире (---) і кожен може містити один обʼєкт. Якщо ця анотація не вказана, мається на увазі значення 0.
Ця анотація є частиною специфікації функцій Моделі Ресурсів Kubernetes (KRM), яка використовується Kustomize та подібними сторонніми інструментами.
Функція KRM не повинна змінювати цю анотацію у вхідних обʼєктах, якщо вона не змінює файли, на які посилається. Функція KRM може включати цю анотацію в обʼєкти, які вона генерує.
kubernetes.io/arch
Тип: Label
Приклад: kubernetes.io/arch: "amd64"
Використовується для: Node
Kubelet заповнює це значення за допомогою runtime.GOARCH, як визначено в Go. Це може бути корисним, якщо ви використовуєте змішані вузли ARM і x86.
kubernetes.io/os
Тип: Label
Приклад: kubernetes.io/os: "linux"
Використовується для: Node, Pod
Для вузлів Kubelet заповнює це значення за допомогою runtime.GOOS, як визначено в Go. Це може бути корисним, якщо у вашому кластері використовуються різні операційні системи (наприклад, змішані вузли Linux і Windows).
Ви також можете встановити цю мітку на Pod. Kubernetes дозволяє встановлювати будь-яке значення для цієї мітки; якщо ви використовуєте цю мітку, ви все ж повинні встановити її на рядок Go runtime.GOOS для операційної системи, з якою працює цей Pod.
Якщо значення мітки kubernetes.io/os для Pod не відповідає значенню мітки на вузлі, Kubelet на цьому вузлі не прийме Pod. Проте це не враховується планувальником kube-scheduler. Крім того, Kubelet відмовляється запускати Pod, якщо ви вказали операційну систему Pod, яка не відповідає операційній системі вузла, на якому працює цей Kubelet. Більше деталей можна знайти в розділі Операційна система Podʼу.
API-сервер Kubernetes (частина панелі управління) встановлює цю мітку на всі простори імен. Значення мітки встановлюється на імʼя простору імен. Ви не можете змінити значення цієї мітки.
Це корисно, якщо ви хочете вказати конкретний простір імен за допомогою селектора міток selector.
kubernetes.io/limit-ranger
Тип: Annotation
Приклад: kubernetes.io/limit-ranger: "LimitRanger plugin set: cpu, memory request for container nginx; cpu, memory limit for container nginx"
Використовується для: Pod
Стандартно Kubernetes не надає жодних обмежень на ресурси, тобто, якщо ви явно не визначите обмеження, ваш контейнер може споживати необмежену кількість CPU та памʼяті. Ви можете визначити стандартний запит або обмеження для Podʼів. Це робиться шляхом створення LimitRange у відповідному просторі імен. Podʼи, розгорнуті після визначення LimitRange, матимуть ці обмеження, застосовані до них. Анотація kubernetes.io/limit-ranger фіксує, що стандартні ресурси були вказані для Pod і були успішно застосовані. Для детальнішої інформації читайте про LimitRanges.
Коли kubelet створює статичний Pod на основі заданого маніфесту, він додає цю анотацію до статичного Pod. Значення анотації — це UID Pod. Зверніть увагу, що kubelet також встановлює .spec.nodeName у поточне імʼя вузла, ніби Pod було заплановано на цей вузол.
Для статичного Pod, створеного kubelet на вузлі, на API-сервері створюється дзеркальний Pod. Kubelet додає анотацію, щоб позначити, що цей Pod фактично є дзеркальним Podʼом. Значення анотації копіюється з анотації kubernetes.io/config.hash, яка є UID Pod.
При оновленні Pod з цією встановленою анотацією анотацію не можна змінити або видалити. Якщо у Podʼа немає цієї анотації, її не можна додати під час оновлення Pod.
kubernetes.io/config.source
Тип: Annotation
Приклад: kubernetes.io/config.source: "file"
Використовується для: Pod
Ця анотація додається kubelet, щоб вказати звідки походить Pod. Для статичних Pod значення анотації може бути одним із file або http, залежно від того, де розташований маніфест Podʼа. Для Podʼа, створеного на API-сервері, а потім запланованого на поточний вузол, значення анотації — api.
Для вказання того, як слід керувати надбудовою, ви можете використовувати мітку addonmanager.kubernetes.io/mode. Ця мітка може мати одне з трьох значень: Reconcile, EnsureExists або Ignore.
Reconcile: Ресурси надбудови періодично будуть зведені до очікуваного стану. Якщо є будь-які відмінності, менеджер надбудов буде переробляти, змінювати конфігурацію або видаляти ресурси за потреби. Цей режим є стандартним режимом, якщо мітка не вказана.
EnsureExists: Ресурси надбудов будуть перевірятися лише на наявність, але не будуть змінюватися після створення. Менеджер надбудов створить або переробить ресурси, коли відсутній жоден екземпляр ресурсу з таким імʼям.
Ignore: Ресурси надбудов будуть ігноруватися. Цей режим корисний для надбудов, які не сумісні з менеджером надбудов або керуються іншим контролером.
Для отримання докладнішої інформації див. Addon-manager.
kube-apiserver встановлює цю мітку для будь-якого обʼєкта APIService, який сервер API створив автоматично. Мітка позначає, як панель управління повинна керувати цим APIService. Ви не повинні додавати, змінювати або видаляти цю мітку самостійно.
Примітка:
Обʼєкти APIService, що автоматично керуються, видаляються kube-apiserver, коли він не має вбудованого або власного API ресурсу користувача, який відповідає API-групі/версії APIService.
Є два можливих значення:
onstart: APIService повинен бути зведений до очікуваного стану при старті сервера API, але не під час інших операцій.
true: Сервер API повинен безперервно зводити цей APIService до очікуваного стану.
Ця анотація на Service вказує, чи повинен контролер точок доступу створювати точки доступу для неготових Podʼів. Точки доступу цих Service зберігають свої DNS-записи і продовжують отримувати трафік для Service з моменту, коли kubelet запускає всі контейнери у Pod і позначає його як Running, до моменту, коли kubelet зупиняє всі контейнери і видаляє Pod з сервера API.
Kubelet заповнює цю мітку імʼям хоста вузла. Зверніть увагу, що імʼя хоста може бути змінене з "фактичного" імʼя хоста за допомогою прапорця --hostname-override для kubelet.
Ця мітка також використовується як частина ієрархії топології. Дивіться topology.kubernetes.io/zone для отримання додаткової інформації.
Значення цієї анотації повинно бути true, щоб вона набула чинності. Коли ви встановлюєте цю анотацію у значення "true", Kubernetes застосовує наступні правила для Podʼів, що працюють з цим ServiceAccount:
Secretʼи, змонтовані як томи, повинні бути перелічені в полі secrets ServiceAccount.
Secretʼи, на які посилаються у полі envFrom для контейнерів (включаючи контейнери sidecar і контейнери ініціалізації), також повинні бути перелічені в полі secrets ServiceAccount. Якщо будь-який контейнер в Podʼі посилається на Secret, який не перелічений в полі secrets ServiceAccount (навіть якщо посилання позначене як optional), то Pod не запуститься, і буде згенеровано помилку, що вказує на невідповідне посилання на секрет.
Secretʼи, на які посилається у полі imagePullSecrets Podʼа, повинні бути присутніми в полі imagePullSecrets ServiceAccount, Pod не запуститься, і буде згенеровано помилку, що вказує на невідповідне посилання на секрет для отримання образу.
Під час створення або оновлення Podʼа перевіряються ці правила. Якщо Pod не відповідає їм, він не запуститься, і ви побачите повідомлення про помилку. Якщо Pod уже працює, і ви змінюєте анотацію kubernetes.io/enforce-mountable-secrets на значення true, або ви редагуєте повʼязаний ServiceAccount для видалення посилання на Secret, який вже використовується Podʼом, Pod продовжить працювати.
Ви можете додати мітки до певних робочих вузлів, щоб виключити їх зі списку серверів бекенда, які використовуються зовнішніми балансувальниками навантаження. Наступна команда може бути використана для виключення робочого вузла зі списку серверів бекенда у наборі серверів бекенда:
Ця анотація використовується для встановлення Вартості видалення Podʼа, що дозволяє користувачам впливати на порядок зменшення масштабування ReplicaSet. Значення анотації аналізується як тип int32.
Ця анотація контролює, чи повинен бути виселений Pod DaemonSet за допомогою ClusterAutoscaler. Ця анотація повинна бути вказана на Pod DaemonSet у маніфесті DaemonSet. Коли ця анотація встановлена в значення "true", ClusterAutoscaler дозволяє виселити Pod DaemonSet, навіть якщо інші правила зазвичай цього уникнули б. Щоб заборонити ClusterAutoscaler виселяти Pod DaemonSet, ви можете встановити цю анотацію в значення "false" для важливих Pod DaemonSet. Якщо ця анотація не встановлена, тоді ClusterAutoscaler діє згідно своєї загальної поведінки (тобто виселяє Pod DaemonSets на основі своєї конфігурації).
Примітка:
Ця анотація впливає тільки на Podʼи DaemonSet.
kubernetes.io/ingress-bandwidth
Тип: Annotation
Приклад: kubernetes.io/ingress-bandwidth: 10M
Використовується для: Pod
Ви можете застосувати обмеження пропускної здатності відповідно для якості обслуговування до Pod щоб ефективно обмежити його доступну пропускну здатність. Вхідний трафік до Podʼа обробляється за допомогою упорядкованої черги пакетів для ефективного керування даними. Щоб обмежити пропускну здатність Podʼа, напишіть файл визначення обʼєкта JSON і вкажіть швидкість передачі даних за допомогою анотації kubernetes.io/ingress-bandwidth. Одиницею, яка використовується для вказівки швидкості вхідної передачі, є біти на секунду, в форматі Кількості. Наприклад, 10M означає 10 мегабіт на секунду.
Примітка:
Анотація формування трафіку вхідного напрямку є експериментальною функцією. Якщо ви хочете ввести підтримку формування трафіку, вам слід додати втулок bandwidth до конфігураційного файлу CNI (стандартно /etc/cni/net.d) і переконатися, що відповідний виконавчий файл включений у теку CNI bin (стандартно /opt/cni/bin).
kubernetes.io/egress-bandwidth
Тип: Annotation
Приклад: kubernetes.io/egress-bandwidth: 10M
Використовується для: Pod
Вихідний трафік з Podʼа обробляється за допомогою застосування політик, які просто відкидають пакети, що перевищують налаштовану швидкість. Обмеження, які ви встановлюєте на Pod, не впливають на пропускну здатність інших Podʼів. Щоб обмежити пропускну здатність Podʼа, напишіть файл визначення обʼєкта JSON і вкажіть швидкість передачі даних за допомогою анотації kubernetes.io/egress-bandwidth. Одиницею, яка використовується для вказівки швидкості вихідної передачі, є біти на секунду, в форматі Кількості. Наприклад, 10M означає 10 мегабіт на секунду.
Примітка:
Анотація формування трафіку вихідного напрямку є експериментальною функцією. Якщо ви хочете ввести підтримку формування трафіку, вам слід додати втулок bandwidth до конфігураційного файлу CNI (стандартно /etc/cni/net.d) і переконатися, що відповідний виконавчий файл включений у теку CNI bin (стандартно /opt/cni/bin).
Kubelet заповнює це значенням типу екземпляра, як визначено постачальником хмарних послуг. Це буде встановлено лише в разі використання постачальника хмарних послуг. Це налаштування є зручним, якщо ви хочете спрямувати певні робочі навантаження на певні типи екземплярів, але, як правило, ви хочете покладатися на планувальник Kubernetes для виконання планування на основі ресурсів. Ви повинні намагатися планувати на основі властивостей, а не на основі типів екземплярів (наприклад, потребувати GPU, замість потреби в g2.2xlarge).
Коли ця анотація встановлена на PersistentVolumeClaim (PVC), це вказує на те, що життєвий цикл PVC пройшов через початкове налаштування звʼязування. Коли вона присутня, ця інформація змінює те, як панель управління тлумачить стан обʼєктів PVC. Значення цієї анотації не має значення для Kubernetes.
Використовується для: PersistentVolume, PersistentVolumeClaim
Якщо ця анотація встановлена на PersistentVolume або PersistentVolumeClaim, це вказує на те, що звʼязка зберігання (PersistentVolume → PersistentVolumeClaim або PersistentVolumeClaim → PersistentVolume) була встановлена контролером. Якщо анотація не встановлена, а звʼязка зберігання вже існує, відсутність цієї анотації означає, що звʼязка була встановлена вручну. Значення цієї анотації не має значення.
Ця анотація додається до PersistentVolume (PV), який був динамічно розподілений Kubernetes. Її значення — це імʼя втулка тому, який створив том. Вона служить як користувачам (щоб показати, звідки походить PV), так і Kubernetes (щоб визначити динамічно розподілені PV у своїх рішеннях).
Використовується для: PersistentVolume, PersistentVolumeClaim
Ця анотація додається до PersistentVolume (PV) та PersistentVolumeClaim (PVC), які мають бути динамічно розподілені або видалені відповідним драйвером CSI через власну функціональну можливість CSIMigration. Коли ця анотація встановлена, компоненти Kubernetes "припиняють боротьбу", і external-provisioner діятиме з обʼєктами.
На Node: kubelet або зовнішній cloud-controller-manager заповнюють мітку інформацією від постачальника хмарних послуг. Мітку буде встановлено лише в разі використання постачальника хмарних послуг. Однак ви можете розглянути можливість встановлення її на вузлах, якщо це має сенс у вашій топології.
На PersistentVolume: постачальники томів, що мають відомості про топологію, автоматично встановлюють обмеження на спорідненість вузла для PersistentVolume.
Зона представляє собою логічний домен невдачі. Для підвищення доступності звичайно, кластери Kubernetes охоплюють декілька зон. Хоча точне визначення зони залишається на вибір реалізацій інфраструктури, загальні властивості зон включають дуже низьку мережеву затримку всередині зони, відсутність вартості мережевого трафіку всередині зони та незалежність від невдач інших зон. Наприклад, вузли всередині зони можуть використовувати один мережевий комутатор, але вузли в різних зонах цього робити не повинні.
Регіон представляє собою більшу область, що складається з однієї або декількох зон. Кластери Kubernetes, що охоплюють декілька регіонів, є не звичайним явищем. Хоча точне визначення зони або регіону залишається на вибір реалізацій інфраструктури, загальні властивості регіону включають в себе вищу мережеву затримку між ними, ненульову вартість мережевого трафіку між ними та незалежність від невдач інших зон або регіонів. Наприклад, вузли всередині регіону можуть використовувати спільну інфраструктуру живлення (наприклад, джерело безперебійного живлення або генератор), але вузли в різних регіонах зазвичай ні.
Kubernetes робить кілька припущень щодо структури зон та регіонів:
регіони та зони є ієрархічними: зони є строгими підмножинами регіонів, і жодна зона не може бути в двох регіонах;
імена зон є унікальними у всіх регіонах; наприклад, регіон "africa-east-1" може складатися з зон "africa-east-1a" та "africa-east-1b".
Можна вважати за безпечне припущення, що мітки топології не змінюються. Навіть якщо мітки є строго змінюваними, споживачі можуть припускати, що данний вузол не буде переміщений між зонами без знищення та перестворення.
Kubernetes може використовувати цю інформацію різними способами. Наприклад, планувальник автоматично намагається розподілити Podʼи в ReplicaSet по вузлах в однозонному кластері (щоб зменшити вплив відмови вузла, див. kubernetes.io/hostname). З кластерами, які охоплюють кілька зон, ця поведінка розподілу також застосовується до зон (для зменшення впливу відмови зони). Це досягається за допомогою SelectorSpreadPriority.
SelectorSpreadPriority — це найкраще розміщення. Якщо зони у вашому кластері є гетерогенними (наприклад, різна кількість вузлів, різні типи вузлів або різні вимоги до ресурсів Podʼа), це розміщення може завадити рівномірному розподілу ваших Podʼів між зонами. Якщо це потрібно, ви можете використовувати однорідні зони (однакова кількість і типи вузлів), щоб зменшити ймовірність нерівномірного розподілу.
Планувальник (за допомогою предиката VolumeZonePredicate) також буде забезпечувати, що Podʼи, які вимагають певного тома, будуть розміщені лише в тій же зоні, що й цей том. Томи не можуть бути підключені в різних зонах.
Якщо PersistentVolumeLabel не підтримує автоматичне додавання міток до ваших PersistentVolume, варто розглянути можливість додавання міток вручну (або підтримку PersistentVolumeLabel). З PersistentVolumeLabel планувальник перешкоджає Podʼам монтувати томи в інших зонах. Якщо ваша інфраструктура не має цього обмеження, вам не потрібно додавати мітки зони до томів взагалі.
Використовується для: PersistentVolume, PersistentVolumeClaim
Ця анотація може використовуватися для PersistentVolume(PV) або PersistentVolumeClaim(PVC), щоб вказати імʼя StorageClass. Коли обидва атрибути storageClassName та анотація volume.beta.kubernetes.io/storage-class вказані, анотація volume.beta.kubernetes.io/storage-class має перевагу над атрибутом storageClassName.
Ця анотація застаріла. Замість цього встановіть поле storageClassName для PersistentVolumeClaim або PersistentVolume.
Якщо вузол має анотацію volumes.kubernetes.io/controller-managed-attach-detach, його операції прикріплення та відʼєднання зберігання керуються контролеромприкріплення/відʼєднання тому.
Коли kubelet працює на операційній системі Microsoft Windows, він автоматично позначає міткою свій вузол, щоб зафіксувати версію Windows Server, що використовується.
Значення мітки має формат "MajorVersion.MinorVersion.BuildNumber".
service.kubernetes.io/headless
Тип: Label
Приклад: service.kubernetes.io/headless: ""
Використовується для: Service
Панель управління додає цю мітку до об’єкта Endpoints, коли Service-власник є headless. Щоб дізнатися більше, прочитайте Headless Services.
Ця анотація використовувалася для увімкнення підказок про топологію на Serviceʼах. Підказки щодо топології з тих пір були перейменовані: концепцію зараз називають Маршрутизацією з урахуванням топології. Встановлення анотації на Auto для Service налаштовує панель управління Kubernetes додавати підказки про топологію на EndpointSlices, повʼязані з цим Service. Ви також можете явно встановити анотацію на Disabled.
Якщо ви використовуєте версію Kubernetes, старішу за 1.30, перевірте документацію для цієї версії Kubernetes, щоб побачити, як працює маршрутизація на основі топології в цьому випуску.
Інших дійсних значень для цієї анотації немає. Якщо вам не потрібні підказки щодо топології для Service, не додавайте цю анотацію.
service.kubernetes.io/topology-mode
Тип: Annotation
Приклад: service.kubernetes.io/topology-mode: Auto
Використовується для: Service
Ця анотація надає спосіб визначення того, як Serviceʼи обробляють топологію мережі; наприклад, ви можете налаштувати Service так, щоб Kubernetes віддавав перевагу збереженню трафіку між клієнтом і сервером в межах однієї топологічної зони. У деяких випадках це може допомогти зменшити витрати або покращити роботу мережі.
Панель управління додає цю мітку лише до Secretʼів, які мають тип kubernetes.io/service-account-token. Значення цієї мітки записує дату (в форматі ISO 8601, в часовому поясі UTC), коли панель управління востаннє бачила запит, де клієнт автентифікувався за допомогою токена службового облікового запису.
Якщо легасі-токен використовувався останній раз до того, як кластер отримав цю функцію (додану у Kubernetes v1.26), то мітка не встановлена.
Панель управління автоматично додає цю мітку до автогенерованих Secretʼів з типом kubernetes.io/service-account-token, за умови, що у вас увімкнено функціональну можливістьLegacyServiceAccountTokenCleanUp. У Kubernetes 1.30 ця поведінка включена стандартно. Ця мітка позначає токен на основі Secret як недійсний для автентифікації. Значення цієї мітки записує дату (в форматі ISO 8601, в часовому поясі UTC), коли панель управління виявляє, що автогенерований Secret не використовувався протягом вказаного періоду (стандартно, один рік).
Ця мітка використовується для позначення контролера або сутності, яка керує EndpointSlice. Мета цієї мітки — забезпечити можливість керувати різними обʼєктами EndpointSlice різними контролерами або сутностями в межах одного та самого кластера.
Цю мітку можна встановити на значення "true" для ресурсу Endpoints, щоб позначити, що контролер EndpointSliceMirroring не повинен дублювати цей ресурс за допомогою EndpointSlices.
Якщо ресурс IngressClass має цю анотацію встановлену на значення "true", новий ресурс Ingress без вказаного класу буде призначено цей стандартний клас.
kubernetes.io/ingress.class (deprecated)
Тип: Annotation
Використовується для: Ingress
Примітка:
Починаючи з v1.18, ця анотація застаріла на користь spec.ingressClassName.
Якщо один ресурс StorageClass має цю анотацію встановлену на значення "true", новий ресурс PersistentVolumeClaim без вказаного класу буде призначено цей стандартний клас.
Kubelet може встановити цю анотацію на вузлі, щоб вказати його налаштовану адресу IPv4 та/або IPv6.
Коли kubelet запускається з прапорцем --cloud-provider, встановленим на будь-яке значення (включає як зовнішні, так і застарілі постачальники хмарних служб у вбудованому коді), він встановлює цю анотацію на вузлі, щоб вказати IP-адресу, встановлену з командного рядка за допомогою прапорця --node-ip. Цей IP перевіряється постачальником хмарних послуг на дійсність за допомогою cloud-controller-manager.
Контролер Job у kube-controller-manager встановлює це як мітку та анотацію для Podʼів, створених з режимом завершення Indexed.
Зверніть увагу, що для того, щоб це було додано як мітку Podʼа, необхідно увімкнути функціональну можливість PodIndexLabel, інакше це буде просто анотацією.
Використовується для: Jobs and Pods controlled by CronJobs
Ця анотація використовується для запису оригінального (очікуваного) часу створення для завдання, коли це завдання є частиною CronJob. Панель управління встановлює значення цього часового позначення у форматі RFC3339. Якщо завдання належить до CronJob з вказаною часовою зоною, тоді мітка часу знаходиться в цій часовій зоні. В іншому випадку мітка часу відображається в локальному часі controller-manager.
Значення анотації — це імʼя контейнера, яке є типовим для цього Podʼа. Наприклад, команди kubectl logs або kubectl exec без прапорця -c або --container використовуватимуть цей типовий контейнер.
Значення анотації — це імʼя контейнера, яке є типовим для логування для цього Podʼа. Наприклад, команда kubectl logs без прапорця -c або --container використовуватиме цей типовий контейнер.
Примітка:
Ця анотація є застарілою. Замість цього, слід використовувати анотацію kubectl.kubernetes.io/default-container. Версії Kubernetes 1.25 і новіші ігнорують цю анотацію.
Командний рядок інструменту kubectl використовує цю анотацію як застарілий механізм для відстеження змін. Цей механізм був замінений на Server-Side Apply.
Панель управління додає цю анотацію до обʼєкта Endpoints, якщо повʼязаний Service має більше 1000 резервних точок доступу. Анотація вказує на те, що обʼєкт Endpoints перевищив потужність, і кількість точок доступу була скорочена до 1000.
Якщо кількість резервних точок доступу опускається нижче 1000, то панель управління видаляє цю анотацію.
Ця анотація встановлює обʼєкт Endpoints, який представляє мітку часу (Мітка часу зберігається у форматі дата-часового рядка RFC 3339. Наприклад, '2018-10-22T19:32:52.1Z'). Це позначка часу останньої зміни в деякому обʼєкті Pod або Service, яка спричинила зміну в обʼєкті Endpoints.
Раніше панель управління встановлювала анотацію на обʼєкті Endpoints. Ця анотація містила наступну інформацію:
Хто є поточним лідером.
Час, коли було здобуто поточне лідерство.
Тривалість оренди (лідерства) у секундах.
Час, коли поточна оренда (поточне лідерство) повинна бути продовжена.
Кількість переходів лідерства, які сталися у минулому.
Тепер Kubernetes використовує Leases для керування призначенням лідера для панелі управління Kubernetes.
batch.kubernetes.io/job-tracking (deprecated)
Тип: Annotation
Приклад: batch.kubernetes.io/job-tracking: ""
Використовується для: Jobs
Раніше наявність цієї анотації на обʼєкті Job вказувала на те, що панель управління відстежує статус Job за допомогою завершувачів. Додавання або видалення цієї анотації більше не має впливу (з версії Kubernetes v1.27 і пізніше). Всі Jobs відстежуються за допомогою завершувачів.
job-name (deprecated)
Тип: Label
Приклад: job-name: "pi"
Використовується для: Jobs та Pods, що керуються через Jobs
Примітка:
Починаючи з Kubernetes 1.27, ця мітка застаріла. Kubernetes 1.27 та новіші версії ігнорують цю мітку і використовують мітку з префіксом job-name.
controller-uid (deprecated)
Тип: Label
Приклад: controller-uid: "$UID"
Використовується для: Jobs та Pods, що керуються через Jobs
Примітка:
Починаючи з Kubernetes 1.27, ця мітка застаріла. Kubernetes 1.27 та новіші версії ігнорують цю мітку і використовують мітку з префіксом controller-uid.
batch.kubernetes.io/job-name
Тип: Label
Приклад: batch.kubernetes.io/job-name: "pi"
Використовується для: Jobs та Pods, що керуються через Jobs
Ця мітка використовується як зручний спосіб для отримання Podʼів, що належать Job. Мітка job-name походить від імені Job і надає простий спосіб отримати Podʼи, що належать Job.
Використовується для: Jobs та Pods, що керуються через Jobs
Ця мітка використовується як програмний спосіб отримати всі Podʼи, що належать Job. controller-uid є унікальним ідентифікатором, який встановлюється в поле selector, щоб контролер Job міг отримати всі відповідні Podʼи.
Ця анотація вимагає активування контролера допуску PodTolerationRestriction. Ключ цієї анотації дозволяє призначати толерантності для простору імен, і будь-які нові створені в цьому просторі імен Podʼи отримають ці толерантності.
Ця анотація корисна лише тоді, коли активований контролер допуску (Alpha) PodTolerationRestriction. Значення анотації — це JSON-документ, який визначає список допустимих толерантностей для простору імен, який анотується. Під час створення Pod або зміни його толерантностей, сервер API перевіряє толерантності, щоб переконатися, що вони згадуються у списку дозволених. Pod буде прийнятий лише у випадку успішної перевірки.
Kubelet виявляє тиск на памʼять на основі значень memory.available і allocatableMemory.available, спостережуваних на вузлі. Потім спостережені значення порівнюються з відповідними пороговими значеннями, які можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.
Kubelet виявляє тиск на дискову памʼять на основі значень imagefs.available, imagefs.inodesFree, nodefs.available і nodefs.inodesFree (тільки для Linux), спостережуваних на вузлі. Потім спостережені значення порівнюються з відповідними пороговими значеннями, які можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.
Це спочатку встановлюється kubelet, коли використовуваний хмарний постачальник вказує на потребу в додатковій конфігурації мережі. Тільки коли маршрут на хмарі налаштований належним чином, хмарний постачальник видаляє позначення.
Kubelet перевіряє D-значення розміру /proc/sys/kernel/pid_max та PID, використані Kubernetes на вузлі, щоб отримати кількість доступних PID, які вказуються метрикою pid.available. Потім цю метрику порівнюють з відповідним пороговим значенням, яке можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.
Користувач може вручну додати позначення на вузол, відмітивши його як такий що вийшов з ладу. Якщо у kube-controller-manager увімкнути функціональну можливість NodeOutOfServiceVolumeDetach, і вузол позначений як такий, що вийшов з ладу з цим позначенням, то при відсутності відповідних толерантностей на ньому, Podʼи на вузлі будуть примусово видалені, і операції відʼєднання томів для Podʼів, які завершуються на вузлі, відбудуться негайно. Це дозволяє Podʼам, що є в стані виходу з ладу на одному вузлі швидко відновитися на іншому вузлі.
Увага:
Дивіться Невідповідне вимкнення вузла для отримання додаткових відомостей про те, коли і як використовувати це позначення.
Встановлює цю позначку на вузлі, щоб позначити його як непридатний для використання, коли kubelet запускається з "зовнішнім" хмарним постачальником, доки контролер з cloud-controller-manager ініціалізує цей вузол, а потім видаляє позначку.
Якщо вузол перебуває у визначеному хмарним постачальником стані вимкнення, вузол отримує відповідну позначку з node.cloudprovider.kubernetes.io/shutdown і ефект позначки NoSchedule.
Ці мітки використовуються компонентом виявлення функцій вузла (NFD), щоб оголошувати функції на вузлі. Усі вбудовані мітки використовують простір імен мітки feature.node.kubernetes.io та мають формат feature.node.kubernetes.io/<назва-функції>: "true". NFD має багато точок розширення для створення міток, специфічних для постачальника або застосунку. Для отримання детальної інформації дивіться посібник з налаштування.
Для вузлів, на яких заплановано master виявлення функцій вузла (NFD) , ця анотація записує версію майстра NFD. Вона використовується лише для інформаційних цілей.
Ця анотація записує список міток функцій вузла, розділених комами, керованих виявленням функцій вузла (NFD). NFD використовує це для внутрішнього механізму. Ви не повинні редагувати цю анотацію самостійно.
Ця анотація зберігає розділені комами список розширених ресурсів, керованих виявленням функцій вузла (NFD). NFD використовує це для внутрішнього механізму. Ви не повинні редагувати цю анотацію самостійно.
nfd.node.kubernetes.io/node-name
Тип: Label
Приклад: nfd.node.kubernetes.io/node-name: node-1
Використовується для: Nodes
Мітка вказує, який вузол націлений обʼєкт NodeFeature. Творці обʼєктів NodeFeature повинні встановлювати цю мітку, а споживачі обʼєктів повинні використовувати її для фільтрації особливостей, призначених для певного вузла.
Примітка:
Ці мітки або анотації Node Feature Discovery (NFD) застосовуються лише до вузлів, де працює NFD. Щоб дізнатися більше про NFD та його компоненти, перейдіть до його офіційної документації.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Значення визначає, як часто балансувальник навантаження записує записи логу. Наприклад, якщо ви встановите значення на 5, записи логу будуть відбуватися з інтервалом у 5 секунд.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Ведення логу доступу активується, якщо ви встановите анотацію на значення "true".
Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: example
Використовується для: Service
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Балансувальник навантаження записує логи до корзини S3 з іменем, яке ви вказуєте.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Балансувальник навантаження записує обʼєкти журналів з префіксом, який ви вказуєте.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує теґи (концепція AWS) для балансувальника навантаження на основі розділених комами пар ключ/значення у значенні цієї анотації.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує прослуховувач балансувальника навантаження на основі значення цієї анотації.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Налаштування затримки зʼєднання балансувальника навантаження залежить від значення, яке ви встановлюєте.
Якщо ви налаштовуєте затримку зʼєднання для Service з type: LoadBalancer, і ви використовуєте хмару AWS, інтеграція налаштовує період затримки на основі цієї анотації. Значення, яке ви встановлюєте, визначає тайм-аут затримки у секундах.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Балансувальник має налаштований період тайм-ауту бездіяльності (у секундах), який застосовується до його зʼєднань. Якщо протягом періоду тайм-ауту бездіяльності не було відправлено або отримано жодних даних, балансувальник закриває зʼєднання.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Якщо ви встановите цю анотацію в значення "true", кожен вузол балансувальника навантаження розподіляє запити рівномірно серед зареєстрованих цілей у всіх увімкнених зонах доступності. Якщо ви вимкнете перехресне балансування зон, кожен вузол балансувальника навантаження розподіляє запити рівномірно серед зареєстрованих цілей лише у своїй зоні доступності.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення є розділеним комами списком ідентифікаторів виділення еластичних IP-адрес.
Ця анотація має сенс тільки для Service з type: LoadBalancer, де балансувальник навантаження є мережевим балансувальником AWS.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації є розділеним комами списком додаткових груп безпеки AWS VPC для налаштування балансувальника навантаження.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає кількість послідовних успішних перевірок стану для бекенду, щоб вважати його справним для передавання трафіку.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає інтервал, в секундах, між запитами перевірки стану, які виконує балансувальник навантаження.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає частину шляху URL, яка використовується для HTTP перевірок стану.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає порт, до якого підключається балансувальник навантаження під час виконання перевірок стану.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає спосіб, яким балансувальник навантаження перевіряє стан бекендів.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації вказує кількість секунд до того, як запит, який ще не вдався, автоматично вважається неуспішним.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає кількість послідовних невдалих перевірок стану, необхідних для того, щоб бекенд вважася несправним для передачі трафіку.
Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Коли ви встановлюєте цю анотацію у значення "true", інтеграція налаштовує внутрішній балансувальник навантаження.
Якщо ви встановлюєте цю анотацію на Service, і також анотуєте цей Service з service.beta.kubernetes.io/aws-load-balancer-type: "external", і ви використовуєте контролер балансувальника навантаження AWS у вашому кластері, тоді контролер балансувальника навантаження AWS встановлює назву цього балансувальника на значення, яке ви встановлюєте для цієї анотації.
Дивіться анотації у документації контролера балансувальника навантаження AWS.
Офіційна інтеграція Kubernetes з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Єдине допустиме значення — "*", що вказує на те, що балансувальник навантаження повинен обгортати TCP-зʼєднання до бекенду Pod за допомогою протоколу PROXY.
Контролер балансувальника навантаження AWS використовує цю анотацію для вказівки розділеного комами списку груп безпеки, які ви хочете прикріпити до балансувальника навантаження AWS. Підтримуються як імʼя, так і ID груп безпеки, де імʼя відповідає тегу Name, а не атрибуту groupName.
Коли ця анотація додається до Service, контролер балансувальника навантаження прикріплює групи безпеки, на які вказує анотація, до балансувальника навантаження. Якщо ви пропускаєте цю анотацію, контролер балансувальника навантаження AWS автоматично створює нову групу безпеки і прикріплює її до балансувальника навантаження.
Примітка:
Починаючи з Kubernetes v1.27, ця анотація більше не встановлюється або не читається безпосередньо. Однак контролер балансувальника навантаження AWS (частина проекту Kubernetes) все ще використовує анотацію service.beta.kubernetes.io/aws-load-balancer-security-groups.
Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації — це імʼя ресурсу AWS (ARN) сертифіката X.509, який повинен використовувати прослуховувач балансувальника навантаження.
(Протокол TLS базується на старій технології, яка скорочується до SSL.)
Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації — це імʼя політики AWS для взаємодії TLS з клієнтом.
Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації може бути або "*", що означає, що всі порти балансувальника навантаження повинні використовувати TLS, або це може бути розділений комами список номерів портів.
Офіційна інтеграція Kubernetes з AWS використовує цю анотацію для налаштування балансувальника навантаження та визначення, в яких зонах доступності AWS розгорнути керовану службу балансування навантаження. Значення може бути або розділений комами список імен підмереж, або розділений комами список ідентифікаторів підмереж.
Офіційна інтеграція Kubernetes з AWS використовує цю анотацію для визначення, які вузли у вашому кластері повинні бути розглянуті як дійсні цілі для балансувальника навантаження.
Офіційні інтеграції Kubernetes з AWS використовують цю анотацію для визначення того, чи має інтеграція з хмарним провайдером AWS керувати Service з type: LoadBalancer.
Є два допустимі значення:
nlb
менеджер контролера хмарних послуг налаштовує мережевий балансувальник навантаження
external
менеджер контролера хмарних послуг не налаштовує жодного балансувальника навантаження
Якщо ви розгортаєте Service з type: LoadBalancer на AWS і не встановлюєте жодної анотації service.beta.kubernetes.io/aws-load-balancer-type, інтеграція з AWS розгортатиме класичний балансувальник навантаження Elastic Load Balancer. Ця поведінка, коли анотація відсутня, є типовою, якщо ви не вказуєте інше.
Коли ви встановлюєте цю анотацію на значення external на Service з type: LoadBalancer, а у вашому кластері є працюючий deployment контролера балансувальника навантаження AWS, то контролер балансувальника навантаження AWS намагатиметься розгорнути балансувальник навантаження на основі специфікації Service.
Увага:
Не змінюйте або додавайте анотацію service.beta.kubernetes.io/aws-load-balancer-type на існуючий обʼєкт Service. Для отримання додаткових відомостей дивіться документацію AWS з цього питання.
Ця анотація працює лише для Service, підтримуваних стандартним балансувальником навантаження Azure. Вона використовується у Service для вказівки, чи слід вимикати або вмикати скидання TCP при бездіяльності. Якщо увімкнено, це допомагає застосункам працювати більш передбачувано, виявляти обриви зʼєднання, видаляти застарілі зʼєднання та ініціювати нові. Ви можете встановити значення як true або false.
Значення обовʼязково повинно бути одним із privileged, baseline або restricted, що відповідає рівням стандарту безпеки для Podʼів. Зокрема, мітка enforceзабороняє створення будь-якого Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні.
Значення має бути latest або дійсна версія Kubernetes у форматі v<major>.<minor>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються при перевірці Podʼа.
Значення має бути одним із privileged, baseline або restricted, що відповідають рівням стандарту безпеки для Podʼів. Зокрема, мітка audit не перешкоджає створенню Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні, але додає цю анотацію до Podʼа.
Значення повинно бути latest або дійсна версія Kubernetes у форматі v<major>.<minor>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються під час перевірки Podʼа.
Значення має бути одним із privileged, baseline або restricted, що відповідають рівням стандарту безпеки для Podʼів. Зокрема, мітка warn не перешкоджає створенню Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні, але повертає попередження користувачу після цього.
Зверніть увагу, що попередження також відображаються при створенні або оновленні обʼєктів, які містять шаблони Podʼа, такі як Deployments, Jobs, StatefulSets тощо.
Значення повинно бути latest або дійсна версія Kubernetes у форматі v<основний>.<додатковий>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються при перевірці поданих Podʼів. Зверніть увагу, що попередження також відображаються при створенні або оновленні обʼєктів, які містять шаблони Podʼа, такі як Deployments, Jobs, StatefulSets тощо.
Використовується для: ClusterRole, ClusterRoleBinding, Role, RoleBinding
Коли ця анотація встановлена на стандартне значення "true" на обʼєктах RBAC, створених сервером API, вони автоматично оновлюються при запуску сервера для додавання відсутніх дозволів та субʼєктів (додаткові дозволи та субʼєкти залишаються на місці). Щоб запобігти автоматичному оновленню певної ролі або привʼязки ролі, встановіть цю анотацію у значення "false". Якщо ви створюєте власні обʼєкти RBAC і встановлюєте цю анотацію у значення "false", kubectl auth reconcile (який дозволяє узгоджувати довільні обʼєкти RBAC у маніфесті) враховує цю анотацію і автоматично не додає відсутні дозволи та субʼєкти.
kubernetes.io/psp (deprecated)
Тип: Annotation
Приклад: kubernetes.io/psp: restricted
Використовується для: Pod
Ця анотація була актуальною лише у випадку використання обʼєктів PodSecurityPolicy. Kubernetes v1.30 не підтримує API PodSecurityPolicy.
Коли контролер допуску PodSecurityPolicy дав дозвіл Podʼу, він модифікував Pod так, щоб мати цю анотацію. Значення анотації було імʼям PodSecurityPolicy, яке використовувалось для валідації.
Значення може бути або true, або false. Це визначає, чи може користувач змінювати режим джерельного тому при створенні PersistentVolumeClaim із VolumeSnapshot.
Анотація, яку kubeadm використовує для збереження інформації про сокет CRI, наданої kubeadm під час init/join для подальшого використання. kubeadm додає цю інформацію як анотацію до обʼєкта Node. Ця анотація залишається "альфа", оскільки в ідеалі це має бути поле в KubeletConfiguration.
Анотація, яку kubeadm додає до локально керованих Podʼів etcd для відстеження списку URL-адрес, до яких повинні підключатися клієнти etcd. Це використовується головним чином для перевірки стану справності кластера etcd.
Анотація, яку kubeadm додає до ConfigMapʼів, що ним керуються для налаштування компонентів. Вона містить хеш (SHA-256), який використовується для визначення, чи застосував користувач налаштування, відмінні від стандартних налаштувань для конкретного компонента.
node-role.kubernetes.io/control-plane
Тип: Label
Використовується для: Node
Мітка-маркер, що вказує, що вузол використовується для запуску компонентів панелі управління. Інструмент kubeadm застосовує цю мітку до вузлів панелі управління, якими він керує. Інші інструменти управління кластером зазвичай також встановлюють це позачення.
Ви можете позначити вузли панелі управління цією міткою, щоб спростити розміщення Podʼів лише на цих вузлах або уникнути запуску Podʼів на панелі управління. Якщо ця мітка встановлена, контролер EndpointSlice ігнорує цей вузол під час розрахунку підказок, що враховують топологію.
Позначення, що kubeadm накладає на вузли панелі управління для обмеження розміщення Podʼів і дозволяє розміщувати на них лише певні Podʼи.
Якщо це позначення застосовано, вузли панелі управління дозволяють розміщувати у себе лише критичні навантаження. Ви можете видалити це позначення вручну за допомогою такої команди на відповідному вузлі.
Позначення, що раніше kubeadm застосовував на вузли панелі управління, щоб дозволити розміщувати на них лише критичні навантаження. Замінений позначенням node-role.kubernetes.io/control-plane. kubeadm більше не встановлює або не використовує це застаріле позначення.
4.1 - Анотації аудиту
Ця сторінка служить довідником по анотаціях аудиту простору імен kubernetes.io. Ці анотації застосовуються до обʼєктів Event з API-групи audit.k8s.io.
Примітка:
Наступні анотації не використовуються в межах Kubernetes API. Коли ви вмикаєте аудит у своєму кластері, дані аудиту подій записуються за допомогою Event з API-групи audit.k8s.io. Ці анотації застосовуються до подій аудиту. Події аудиту відрізняються від обʼєктів у API подій (API-група events.k8s.io).
Значення повинно бути одним із user, namespace або runtimeClass, що відповідає вимогам виключень безпеки Pod. Ця анотація вказує на те, на чому засновано виключення з дотримання безпеки Pod.
Значення повинно бути privileged:<version>, baseline:<version>,
restricted:<version>, що відповідає рівням стандарту безпеки Pod, супроводжуваних версією, яка повинна бути latest або дійсною версією Kubernetes у форматі v<MAJOR>.<MINOR>. Ця анотація надає інформацію про рівень виконання, який дозволив або відхилив Pod під час допуску PodSecurity.
Приклад: pod-security.kubernetes.io/audit-violations: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), ...
Значення деталізує порушення аудиту політики, воно містить рівень стандарту безпеки Pod, який був порушений, а також конкретні політики з полів, які були порушені з дотримання безпеки Pod.
Приклад: missing-san.invalid-cert.kubernetes.io/example-svc.example-namespace.svc: "покладається на застаріле поле загального імені замість розширення SAN для перевірки субʼєкта"
Використовується у Kubernetes версії v1.24 та пізніше.
Ця анотація вказує, що вебхук або агрегований API-сервер використовує недійсний сертифікат, у якого відсутні subjectAltNames. Підтримка цих сертифікатів відключена у Kubernetes 1.19 та видалена у Kubernetes 1.23.
Запити до точок доступу, які використовують ці сертифікати, будуть невдалими. Serviceʼи, які використовують ці сертифікати, повинні замінити їх якомога швидше, щоб уникнути перерви у роботі при використанні середовищ Kubernetes 1.23+.
Використовується у Kubernetes версії v1.24 та пізніше.
Ця анотація вказує, що вебхук або агрегований API-сервер використовує недійсний сертифікат, підписаний небезпечним хешем SHA-1. Підтримка цих небезпечних сертифікатів відключена у Kubernetes 1.24 та буде видалена в майбутніх версіях.
Serviceʼи, які використовують ці сертифікати, повинні замінити їх якнайшвидше, щоб забезпечити належну безпеку зʼєднань та уникнути перебоїв у майбутніх випусках.
Використовується у Kubernetes версії v1.27 та пізніше.
Ця анотація вказує, що перевірка політики допуску не вдалася для запиту API або що перевірка призвела до помилки, коли політика була налаштована з failurePolicy: Fail.
Значення анотації є обʼєктом JSON. message у JSON надає повідомлення про невдачу перевірки.
policy, binding і expressionIndex в JSON ідентифікують імʼя ValidatingAdmissionPolicy, імʼя ValidatingAdmissionPolicyBinding та індекс у політиці validations виразів CEL, які не вдалося, відповідно.
validationActions показують, які дії були вжиті для цієї невдачі перевірки. Див. Політика валідації допуску для отримання додаткових відомостей щодо validationActions.
5 - API Kubernetes
API Kubernetes це застосунок, який обслуговує функціонал Kubernetes через RESTful інтерфейс та зберігає стан кластера.
Ресурси Kubernetes та "записи про наміри" зберігаються як обʼєкти API та модифікуються за допомогою RESTful викликів до API. API дозволяє керувати конфігурацією декларативним способом. Користувачі можуть взаємодіяти з API Kubernetes безпосередньо або за допомогою інструментів, таких як kubectl. Ядро API Kubernetes є гнучким та може бути розширено для підтримки власних ресурсів користувачів.
5.1 - Ресурси робочих навантажень
5.1.1 - Pod
Pod — це колекція контейнерів, які можуть запускатися на одному хості.
apiVersion: v1
import "k8s.io/api/core/v1"
Pod
Pod є колекцією контейнерів, які можуть працювати на одному хості. Цей ресурс створюється клієнтами та розміщується на хостах.
Останній спостережуваний статус Podʼа. Ці дані можуть бути застарілими. Заповнюється системою. Тільки для читання. Додаткова інформація: Специфікації API Kubernetes
Список контейнерів, що належать Podʼу. Зараз контейнери не можуть бути додані або видалені. В Podʼі повинен бути принаймні один контейнер. Не може бути оновлено.
Список контейнерів ініціалізації, що належать Podʼу. Контейнери ініціалізації виконуються у визначеному порядку перед запуском звичайних контейнерів. Якщо будь-який контейнер ініціалізації зазнає збою, Pod вважається збійним та обробляється відповідно до restartPolicy. Імʼя контейнера ініціалізації або звичайного контейнера повинно бути унікальним серед усіх контейнерів. Контейнери ініціалізації не можуть мати дій Lifecycle, Readiness probes, Liveness probes, або Startup probes. resourceRequirements контейнера ініціалізації враховуються під час планування, знаходячи найбільше значення запиту/ліміту для кожного типу ресурсів, а потім використовуючи максимум цього значення або суму цих значень для звичайних контейнерів. Ліміти застосовуються до контейнерів ініціалізації аналогічним чином. Контейнери ініціалізації зараз не можуть бути додані або видалені. Не може бути оновлено. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
Список ефемерних контейнерів, що запущені у цьому Pod. Ефемерні контейнери можуть бути запущені в наявному Podʼі для виконання дій, ініційованих користувачем, таких як налагодження. Цей список не може бути вказаний при створенні Podʼа, і його не можна змінити, оновивши специфікацію Podʼа. Щоб додати ефемерний контейнер до наявного Podʼа, використовуйте субресурс ефемерних контейнерів Podʼа.
ImagePullSecrets — це необовʼязково список посилань на Secretʼи у тому ж просторі імен, які використовуються для отримання будь-яких образів, що використовуються у цьому PodSpec. Якщо вказано, ці Secretʼи будуть передані індивідуальним реалізаціям отримувачів для їх використання. Додаткова інформація: https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod
enableServiceLinks (boolean)
EnableServiceLinks вказує, чи слід впроваджувати інформацію про Serviceʼи у змінні середовища Pod, відповідно до синтаксису Docker посилань. Необовʼязково: стандартне значення — true.
os (PodOS)
PodOS визначає параметри операційної системи Pod.
Якщо в поле OS встановлено значення linux, наступні поля не повинні бути встановлені:
securityContext.windowsOptions
Якщо в поле OS встановлено значення windows, наступні поля не повинні бути встановлені:
NodeName — це запит на планування цього Podʼа на конкретному вузлі. Якщо він не порожній, планувальник просто призначає цей Pod на цей вузол, за умови, що він відповідає вимогам до ресурсів.
affinity (Affinity)
Якщо вказано, це обмеження на планування Podʼа.
Affinity — це група правил планування з урахуванням спорідненості.
Описує правила планування Podʼа з урахуванням спорідненості до інших Podʼів (наприклад, розташувати цей Pod на тому ж вузлі, у тій же зоні тощо, що й інші Podʼи).
Описує правила планування Podʼа з урахуванням анти-спорідненості до інших Podʼів (наприклад, уникати розташування цього Podʼа на тому ж вузлі, у тій же зоні тощо, що й інші Podʼи).
tolerations ([]Toleration)
Якщо вказано, визначає толерантності Podʼа.
Pod, до якого прикріплено цю толерантність, толерує будь-який taint, який відповідає трійці <key,value,effect> за допомогою оператора зіставлення .
tolerations.key (string)
Ключ taint, до якого застосовується толерантність. Порожнє значення означає відповідність усім ключам taint. Якщо ключ порожній, оператор має бути Exists; ця комбінація означає відповідність усім значенням та ключам.
tolerations.operator (string)
Оператор, що представляє стосунок ключа до значення. Допустимі оператори — Exists та Equal. Стандартне значення — Equal. Exists еквівалентний знаку підстановки для значення, щоб Pod міг толерувати всі taint певної категорії.
tolerations.value (string)
Значення taint, до якого застосовується толерантність. Якщо оператор Exists, значення має бути порожнім, в іншому випадку — це звичайний рядок.
tolerations.effect (string)
Ефект, до якого застосовується толерантність. Порожнє значення означає відповідність усім ефектам taint. Допустимі значення: NoSchedule, PreferNoSchedule та NoExecute.
tolerations.tolerationSeconds (int64)
TolerationSeconds визначає період часу, протягом якого толерантність (яка має бути з ефектом NoExecute, інакше це поле ігнорується) толерує taint. Стандартно не встановлюється, що означає виконувати толерування taint назавжди (не видаляти). Нульові та відʼємні значення система обробляє як 0 (негайне видалення).
schedulerName (string)
Якщо вказано, Pod буде оброблено вказаним планувальником. Якщо не вказано, Pod буде оброблено стандартним планувальником.
runtimeClassName (string)
RuntimeClassName посилається на обʼєкт RuntimeClass у групі node.k8s.io, який повинен бути використаний для запуску цього Podʼа. Якщо жоден ресурс RuntimeClass не відповідає названому класу, Pod не буде запущено. Якщо не встановлено або порожнє, буде використано "старий" RuntimeClass, який є неявним класом з порожнім визначенням, що використовує стандартний обробник середовища. Детальніше: https://git.k8s.io/enhancements/keps/sig-node/585-runtime-class
priorityClassName (string)
Якщо вказано, вказує на пріоритет Podʼа. "system-node-critical" та "system-cluster-critical" — це два спеціальні ключові слова, які вказують на найвищі пріоритети, причому перший має найвищий пріоритет. Будь-яке інше імʼя має бути визначене шляхом створення обʼєкта PriorityClass з цим імʼям. Якщо не вказано, пріоритет Podʼа буде стандартним або нульовим, якщо немає стандартного значення.
priority (int32)
Значення пріоритету. Різні системні компоненти використовують це поле для визначення пріоритету Podʼа. Коли включено контролер доступу до пріоритетів (Priority Admission Controller), він не дозволяє користувачам встановлювати це поле. Контролер доступу заповнює це поле з PriorityClassName. Чим вище значення, тим вищий пріоритет.
preemptionPolicy (string)
PreemptionPolicy — це політика випередження для Podʼів з нижчим пріоритетом. Одне з: Never чи PreemptLowerPriority. Стандартне значення — PreemptLowerPriority, якщо не встановлено.
Map: під час об’єднання будуть збережені унікальні значення за ключами topologyKey, whenUnsatisfiable
TopologySpreadConstraints описує, як група Podʼів повинна розподілятися по топологічних доменах. Планувальник розміщуватиме Podʼи таким чином, щоб дотримуватися обмежень. Всі topologySpreadConstraints поєднуються логічним оператором AND.
TopologySpreadConstraint визначає, як розподіляти відповідні Podʼи серед заданої топології.
MaxSkew описує ступінь нерівномірного розподілу Podʼів. Коли whenUnsatisfiable=DoNotSchedule, це максимальна допустима різниця між кількістю відповідних Podʼів у цільовій топології та глобальним мінімумом. Глобальний мінімум — це мінімальна кількість відповідних Podʼів у відповідному домені або нуль, якщо кількість відповідних доменів менша за MinDomains. Наприклад, у кластері з 3 зонами MaxSkew встановлено на 1, і Podʼи з однаковим labelSelector розподіляються як 2/2/1: У цьому випадку глобальний мінімум дорівнює 1.
graph TD;
subgraph zone3["zone 3"]
P3_1("Pod")
end
subgraph zone2["zone 2"]
P2_1("Pod")
P2_2("Pod")
end
subgraph zone1["zone 1"]
P1_1("Pod")
P1_2("Pod")
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class P1_1,P1_2,P2_1,P2_2,P3_1 k8s;
class zone1,zone2,zone3 cluster;
якщо MaxSkew дорівнює 1, новий Pod може бути розміщений тільки в zone3, щоб стати 2/2/2; розміщення його в zone1 (zone2) призведе до порушення MaxSkew (1) через ActualSkew (3-1) в zone1 (zone2).
якщо MaxSkew дорівнює 2, новий Pod може бути розміщений у будь-якій зоні. Коли whenUnsatisfiable=ScheduleAnyway, це використовується для надання більшої переваги топологіям, які задовольняють цю умову. Це обовʼязкове поле. Стандартне значення — 1; 0 не допускається.
TopologyKey — це ключ міток вузлів. Вузли, які мають мітку з цим ключем та ідентичними значеннями, вважаються такими, що належать до однієї топології. Ми розглядаємо кожен <key, value> як "кошик" і намагаємося розмістити збалансовану кількість Podʼів у кожному кошику. Ми визначаємо домен як конкретний екземпляр топології. Також ми визначаємо відповідний домен як домен, чиї вузли відповідають вимогам nodeAffinityPolicy та nodeTaintsPolicy. Наприклад, якщо TopologyKey — це "kubernetes.io/hostname", кожен вузол є доменом цієї топології. І, якщо TopologyKey — це "topology.kubernetes.io/zone", кожна зона є доменом цієї топології. Це обовʼязкове поле.
WhenUnsatisfiable вказує, як діяти з Podʼом, якщо він не відповідає умовам розподілу.
DoNotSchedule (стандартно) наказує планувальнику не розміщувати його.
ScheduleAnyway наказує планувальнику розмістити Pod у будь-якому місці, але з наданням більшої переваги топологіям, які допоможуть зменшити нерівномірність розподілу. Умова вважається "незадовільною" для вхідного Podʼа, якщо і тільки якщо кожне можливе призначення вузла для цього Podʼа порушуватиме "MaxSkew" у деякій топології. Наприклад, у кластері з 3 зонами MaxSkew встановлено на 1, і Podʼи з однаковим labelSelector розподіляються як 3/1/1:
graph TD;
subgraph zone3["zone 3"]
P3_1("Pod")
end
subgraph zone2["zone 2"]
P2_1("Pod")
end
subgraph zone1["zone 1"]
P1_1("Pod")
P1_2("Pod")
P1_3("Pod")
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class P1_1,P1_2,P1_3,P2_1,P3_1 k8s;
class zone1,zone2,zone3 cluster;
Якщо WhenUnsatisfiable встановлено на DoNotSchedule, новий Pod може бути розміщений тільки в zone2 (zone3), щоб стати 3/2/1 (3/1/2), оскільки ActualSkew (2-1) у zone2 (zone3) задовольняє MaxSkew (1). Іншими словами, кластер все ще може бути незбалансованим, але планувальник не зробить його більш незбалансованим. Це обовʼязкове поле.
LabelSelector використовується для знаходження відповідних Podʼів. Podʼи, які відповідають цьому label selector, враховуються для визначення кількості Podʼів у відповідному топологічному домені.
MatchLabelKeys — це набір ключів міток Podʼа для вибору Podʼів, за якими буде розраховано розподіл. Ключі використовуються для пошуку значень у мітках вхідного Podʼа, ці ключ-значення міток поєднуються з labelSelector для вибору групи наявних Podʼів, за якими буде розраховано розподіл для вхідного Podʼа. Той самий ключ заборонено мати як у MatchLabelKeys, так і в LabelSelector. MatchLabelKeys не можна встановлювати, коли LabelSelector не встановлено. Ключі, які не існують у мітках вхідного Podʼа, будуть ігноруватися. Нульовий або порожній список означає збіг тільки з labelSelector.
Це бета-поле і вимагає ввімкнення функції MatchLabelKeysInPodTopologySpread (типово увімкнено).
topologySpreadConstraints.minDomains (int32)
MinDomains вказує мінімальну кількість відповідних доменів. Коли кількість відповідних доменів з відповідними топологічними ключами менша за minDomains, Pod Topology Spread трактує "глобальний мінімум" як 0, і потім виконується розрахунок Skew. І коли кількість відповідних доменів з відповідними топологічними ключами дорівнює або перевищує minDomains, це значення не впливає на розподіл. У результаті, коли кількість відповідних доменів менша за minDomains, планувальник не розміщуватиме більше maxSkew Podʼів у ці домени. Якщо значення дорівнює null, обмеження поводиться так, ніби MinDomains дорівнює 1. Допустимі значення — цілі числа, більші за 0. Коли значення не дорівнює null, WhenUnsatisfiable має бути DoNotSchedule.
Наприклад, у кластері з 3 зонами MaxSkew встановлено на 2, MinDomains встановлено на 5, і Podʼи з однаковим labelSelector розподіляються як 2/2/2:
graph TD;
subgraph zone3["zone 3"]
P3_1("Pod")
P3_2("Pod")
end
subgraph zone2["zone 2"]
P2_1("Pod")
P2_2("Pod")
end
subgraph zone1["zone 1"]
P1_1("Pod")
P1_2("Pod")
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class P1_1,P1_2,P2_1,P2_2,P3_1,P3_2 k8s;
class zone1,zone2,zone3 cluster;
Кількість доменів менша за 5 (MinDomains), тому "глобальний мінімум" трактуватиметься як 0. У цій ситуації новий Pod з тим самим labelSelector не може бути розміщений, оскільки обчислений skew буде 3 (3 - 0), якщо новий Pod буде розміщено в будь-якій з трьох зон, це порушить MaxSkew.
Це бета-функція і вимагає ввімкнення MinDomainsInPodTopologySpread (типово увімкнено).
NodeAffinityPolicy вказує, як ми будемо враховувати nodeAffinity/nodeSelector Podʼа при розрахунку перекосу розподілу топології Pod. Варіанти:
Honor: тільки вузли, що відповідають nodeAffinity/nodeSelector, включаються до розрахунків.
Ignore: nodeAffinity/nodeSelector ігноруються. Всі вузли включаються до розрахунків.
Якщо це значення дорівнює null, поведінка еквівалентна полю Honor. Це функція на рівні бета, типово увімкнена за допомогою прапорця NodeInclusionPolicyInPodTopologySpread.
NodeTaintsPolicy вказує, як ми будемо враховувати node taints при розрахунку перекосу розподілу топології Pod. Варіанти:
Honor: вузли без taints, разом з вузлами з taints, для яких вхідний Pod має толерантність, включаються.
Ignore: node taints ігноруються. Всі вузли включаються.
Якщо це значення дорівнює null, поведінка еквівалентна полю Ignore. Це функція на рівні бета, типово увімкнена за допомогою прапорця NodeInclusionPolicyInPodTopologySpread.
Overhead представляє ресурси, що представляють накладні витрати Podʼа для роботи з конкретним RuntimeClass. Це поле буде автоматично заповнене під час допуску контролером RuntimeClass. Якщо контролер допуску RuntimeClass увімкнено, overhead не повинен бути встановлений у запитах на створення Podʼу. Контролер допуску RuntimeClass відхилить запити на створення Podʼу, у яких overhead вже встановлений. Якщо RuntimeClass налаштований та обраний у PodSpec, Overhead буде встановлено на значення, визначене у відповідному RuntimeClass, в іншому випадку воно залишиться невстановленим та буде вважатися рівним нулю. Докладніше: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.md
Необовʼязкова тривалість у секундах, необхідна для коректного завершення роботи Podʼа. Може бути зменшена у запиті на видалення. Значення повинно бути невідʼємним цілим числом. Значення нуль означає негайне припинення через сигнал kill (без можливості завершити роботу коректно). Якщо це значення є nil, буде використано стандартний період завершення. Період належного завершення — це тривалість у секундах після того, як процеси, що працюють у Podʼі, отримають сигнал про завершення, і до того, як вони будуть примусово зупинені сигналом kill. Встановіть це значення більше, ніж очікуваний час завершення вашого процесу. Стандартне значення — 30 секунд.
activeDeadlineSeconds (int64)
Необовʼязкова тривалість у секундах, протягом якої Pod може бути активним на вузлі відносно StartTime, перш ніж система почне активно намагатися позначити його як несправний та припинити роботу повʼязаних контейнерів. Значення повинно бути додатним цілим числом.
ConditionType належить до стану у списку станів Podʼа з відповідним типом.
Імʼя хосту та розвʼязування імен
hostname (string)
Вказує імʼя хосту Podʼа. Якщо не вказано, імʼя хосту Podʼа буде встановлено в значення визначене системою.
setHostnameAsFQDN (boolean)
Якщо встановлено значення true, імʼя хосту Podʼа буде налаштоване як повне доменне імʼя (FQDN) Podʼа, а не просто коротке імʼя (стандартно). У Linux-контейнерах це означає встановлення FQDN в полі імʼя хосту ядра (поле nodename структури utsname). У Windows-контейнерах це означає встановлення значення реєстру імʼя хосту для ключа реєстру HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters на FQDN. Якщо Pod не має FQDN, це не має ефекту. Стандартне значення — false.
subdomain (string)
Якщо вказано, повне кваліфіковане імʼя хосту Podʼа буде "<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>". Якщо не вказано, Pod не буде мати доменного імені взагалі.
hostAliases ([]HostAlias)
Patch strategy: злиття за ключем ip
HostAliases є необовʼязковим списком хостів та IP, які будуть впроваджені у файл hosts Podʼа, якщо вказано. Це дійсно тільки для Podʼів, що не використовують hostNetwork.
HostAlias містить зітсавлення між IP та іменами хостів, які будуть впроваджені як запис у файл hosts Podʼа.
hostAliases.hostnames ([]string)
Імена хостів для вищевказаної IP-адреси.
hostAliases.ip (string)
Запис IP-адреси у файлі hosts.
dnsConfig (PodDNSConfig)
Вказує параметри DNS Podʼа. Параметри, вказані тут, будуть обʼєднані зі згенерованою DNS-конфігурацією на основі DNSPolicy.
PodDNSConfig визначає параметри DNS Podʼа на додаток до тих, що генеруються з DNSPolicy.
dnsConfig.nameservers ([]string)
Список IP-адрес DNS-серверів імен. Він буде доданий до основних серверів імен, згенерованих з DNSPolicy. Дубльовані сервери імен будуть видалені.
dnsConfig.options ([]PodDNSConfigOption)
Список опцій DNS-резолвера. Він буде обʼєднаний з основними опціями, згенерованими з DNSPolicy. Дубльовані записи будуть видалені. Опції розвʼязування імен, зазначені в Options, замінять ті, що зʼявляються в основній DNSPolicy.
PodDNSConfigOption визначає опції DNS-резольвера Podʼа.
dnsConfig.options.name (string)
Обовʼязкове.
dnsConfig.options.value (string)
dnsConfig.searches ([]string)
Список доменів пошуку DNS для пошуку імен хостів. Він буде доданий до основних шляхів пошуку, згенерованих з DNSPolicy. Дубльовані шляхи пошуку будуть видалені.
dnsPolicy (string)
Встановлює політику DNS для Podʼа. Стандартне значеняя — "ClusterFirst". Допустимі значення: ʼClusterFirstWithHostNetʼ, ʼClusterFirstʼ, ʼDefaultʼ або ʼNoneʼ. Параметри DNS, задані в DNSConfig, будуть обʼєднані з політикою, вибраною за допомогою DNSPolicy. Щоб налаштувати опції DNS разом з hostNetwork, потрібно явно вказати політику DNS як ʼClusterFirstWithHostNetʼ.
Простори імен хоста
hostNetwork (boolean)
Використання мережі хоста для цього Podʼа. Використовує простір імен мережі хоста. Якщо ця опція встановлена, необхідно вказати порти, які будуть використовуватися. Стандартне значення — false.
hostPID (boolean)
Використання простору імен PID хоста. Необовʼязково: стандартне значення — false.
hostIPC (boolean)
Використання простору імен IPC хоста. Необовʼязково: стандартне значення — false.
shareProcessNamespace (boolean)
Спільний процесний простір імен між усіма контейнерами в Podʼі. Якщо це встановлено, контейнери зможуть бачити та надсилати сигнали процесам з інших контейнерів у тому ж Podʼі, і перший процес у кожному контейнері не буде мати PID 1. HostPID та ShareProcessNamespace не можуть бути встановлені одночасно. Необовʼязково: стандартне значення — false.
AutomountServiceAccountToken вказує, чи повинен токен службового облікового запису автоматично монтуватися.
Контекст безпеки
securityContext (PodSecurityContext)
SecurityContext містить атрибути безпеки на рівні Podʼа та загальні налаштування контейнера. Необовʼязково: стандартне значення — порожньо. Див. опис типу для стандартних значень для кожного поля.
PodSecurityContext містить атрибути безпеки на рівні Podʼа та загальні налаштування контейнера. Деякі поля також присутні у container.securityContext. Значення полів container.securityContext мають пріоритет над значеннями полів PodSecurityContext.
securityContext.runAsUser (int64)
UID для запуску точки доступу процесу контейнера. Стандартно використовується користувач, зазначений у метаданих образу, якщо не вказано. Також може бути встановлено в SecurityContext. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет для цього контейнера. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
securityContext.runAsNonRoot (boolean)
Вказує, що контейнер повинен запускатися від імені користувача, який не є root. Якщо true, Kubelet перевірить образ під час виконання, щоб переконатися, що він не запускається як UID 0 (root), і не запускатиме контейнер, якщо він є. Якщо не встановлено або false, така перевірка не виконується. Також може бути встановлено в SecurityContext. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет.
securityContext.runAsGroup (int64)
GID для запуску точки доступу процесу контейнера. Використовується стандартне значення часу виконання, якщо не вказано. Також може бути встановлено в SecurityContext. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет для цього контейнера. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
securityContext.supplementalGroups ([]int64)
Список груп, застосованих до першого процесу, який запускається в кожному контейнері, на додаток до основного GID контейнера, fsGroup (якщо зазначено) та членств у групах, визначених у образі контейнера для uid процесу контейнера. Якщо не вказано, жодні додаткові групи не додаються до жодного контейнера. Зверніть увагу, що членства у групах, визначені в образі контейнера для uid процесу контейнера, все ще діють, навіть якщо вони не включені до цього списку. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
securityContext.fsGroup (int64)
Спеціальна додаткова група, яка застосовується до всіх контейнерів у Podʼі. Деякі типи томів дозволяють Kubelet змінювати право власності на цей том, щоб він належав Podʼу:
GID власника буде FSGroup
Встановлюється біт setgid (нові файли, створені в томі, будуть належати FSGroup)
Біти дозволів обʼєднуються з rw-rw----
Якщо не встановлено, Kubelet не змінює право власності та дозволи будь-якого тому. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
securityContext.fsGroupChangePolicy (string)
fsGroupChangePolicy визначає поведінку зміни прав власності та дозволів тому перед тим, як він буде доступний у Podʼі. Це поле застосовується лише до типів томів, які підтримують права власності на основі fsGroup (та дозволів). Це не впливає на ефемерні типи томів, такі як: secret, configmaps та emptydir. Дійсні значення: "OnRootMismatch" та "Always". Якщо не вказано, використовується "Always". Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
securityContext.seccompProfile (SeccompProfile)
Параметри seccomp для використання контейнерами в цьому Podʼі. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
SeccompProfile визначає налаштування профілю seccomp для Podʼа/контейнера. Може бути встановлено лише одне джерело профілю.
localhostProfile вказує, що має бути використаний профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі, щоб працювати. Має бути низхідний шлях, відносно до налаштованого розташування профілю seccomp kubelet. Має бути встановлено, якщо тип "Localhost". НЕ має бути встановлено для будь-якого іншого типу.
securityContext.seLinuxOptions (SELinuxOptions)
Контекст SELinux, який буде застосовано до всіх контейнерів. Якщо не зазначено, середовище виконання контейнера виділить випадковий контекст SELinux для кожного контейнера. Також може бути встановлено в SecurityContext. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет для цього контейнера. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
SELinuxOptions — це мітки, які будуть застосовані до контейнера
securityContext.seLinuxOptions.level (string)
Level — це мітка рівня SELinux, яка застосовується до контейнера.
securityContext.seLinuxOptions.role (string)
Role — це мітка ролі SELinux, яка застосовується до контейнера.
securityContext.seLinuxOptions.type (string)
Type — це мітка типу SELinux, яка застосовується до контейнера.
securityContext.seLinuxOptions.user (string)
User — це мітка користувача SELinux, яка застосовується до контейнера.
securityContext.sysctls ([]Sysctl)
Sysctls містять список sysctls з простором імен, що використовуються для Podʼа. Podʼи з непідтримуваними sysctl (середовищем виконання контейнера) можуть не запуститися. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.
Sysctl визначає параметр ядра, який потрібно встановити
Параметри, специфічні для Windows, що застосовуються до всіх контейнерів. Якщо не зазначено, використовуються параметри у SecurityContext контейнера. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — linux.
WindowsSecurityContextOptions містять параметри та облікові дані, специфічні для Windows.
HostProcess визначає, чи повинен контейнер запускатися як контейнер ʼHost Processʼ. Усі контейнери Podʼа повинні мати однакове ефективне значення HostProcess (не дозволяється змішування контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess дорівнює true, то HostNetwork також має бути встановлено на true.
Ім’я користувача в Windows для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано. Також можна встановити в PodSecurityContext. Якщо встановлено як у SecurityContext, так і в PodSecurityContext, значення, вказане в SecurityContext, має пріоритет.
Alpha рівень
hostUsers (boolean)
Використання простору імен користувачів хоста. Необовʼязково: стандартне значення — true. Якщо встановлено true або не зазначено, Pod буде виконуватися в просторі імен користувачів хоста, корисно, коли Pod потребує функції, доступної лише в просторі імен користувачів хоста, такої як завантаження модуля ядра з CAP_SYS_MODULE. Коли встановлено false, створюється новий простір імен для користувачів для Podʼа. Встановлення значення false корисно для зниження ризику вразливостей виходу з контейнера, дозволяючи користувачам запускати контейнери з правами root без фактичних привілеїв root на хості. Це поле є рівнем alpha і враховується лише серверами, які включають функцію UserNamespacesSupport.
resourceClaims ([]PodResourceClaim)
Patch strategy: retainKeys, обʼєднання за ключем name
Map: унікальні значення за ключем name будуть збережені під час обʼєднання
ResourceClaims визначає, які ResourceClaims повинні бути виділені та зарезервовані перед тим, як Podʼу буде дозволено почати роботу. Ресурси будуть доступні тим контейнерам, які споживають їх за іменем.
Це поле є альфа-рівнем і вимагає увімкнення функції DynamicResourceAllocation.
Це поле є незмінним.
PodResourceClaim посилається тільки на один ResourceClaim через ClaimSource. Він додає імʼя до нього, яке унікально ідентифікує ResourceClaim всередині Podʼа. Контейнери, які потребують доступу до ResourceClaim, посилаються на нього за цим імʼям.
resourceClaims.name (string), обовʼязкове
Імʼя унікально ідентифікує цей ресурсний запит всередині Podʼа. Це повинно бути DNS_LABEL.
resourceClaims.source (ClaimSource)
Джерело описує, де знайти ResourceClaim.
ClaimSource описує посилання на ResourceClaim.
Одне з цих полів повинно бути встановлено. Споживачі цього типу повинні трактувати порожній обʼєкт так, ніби він має невідоме значення.
resourceClaims.source.resourceClaimName (string)
ResourceClaimName — це імʼя обʼєкта ResourceClaim у тому ж просторі імен, що і цей Pod.
ResourceClaimTemplateName — це імʼя обʼєкта ResourceClaimTemplate у тому ж просторі імен, що і цей Pod.
Шаблон буде використаний для створення нового ResourceClaim, який буде привʼязаний до цього Podʼа. Коли цей Pod буде видалений, ResourceClaim також буде видалений. Імʼя Podʼа та імʼя ресурсу разом з згенерованим компонентом будуть використані для формування унікального імені для ResourceClaim, яке буде записано в pod.status.resourceClaimStatuses.
Це поле є незмінним, і після створення ResourceClaim панель управління не вноситиме жодних змін до відповідного ResourceClaim.
schedulingGates ([]PodSchedulingGate)
Patch strategy: обʼєднання за ключем name
Map: унікальні значення за ключем name будуть збережені під час обʼєднання
SchedulingGates — це непрозорий список значень, які, якщо вказані, блокуватимуть планування Podʼа. Якщо schedulingGates не порожні, Pod залишатиметься в стані SchedulingGated, і планувальник не намагатиметься його розмістити.
SchedulingGates можна встановити лише під час створення Podʼа і видаляти лише згодом.
Це бета-функція, увімкнена функцією PodSchedulingReadiness.
PodSchedulingGate повʼязаний з Podʼом для захисту його планування.
schedulingGates.name (string), обовʼязкове
Імʼя шлюзу планування. Кожен шлюз планування повинен мати унікальне поле name.
Застаріле
serviceAccount (string)
DeprecatedServiceAccount — це застарілий псевдонім для ServiceAccountName. Застаріле: використовуйте serviceAccountName замість цього.
Контейнер
Один контейнер застосунка, який ви хочете запустити в Podʼі.
name (string), обовʼязково
Імʼя контейнера вказується як DNS_LABEL. Кожен контейнер в Podʼі повинен мати унікальне імʼя (DNS_LABEL). Не може бути оновлено.
Образ
image (string)
Назва образу контейнера. Додаткова інформація: https://kubernetes.io/docs/concepts/containers/images. Це поле є необовʼязковим для того, щоб дозволити більш високому рівню управління конфігурацією використовувати стандартний образ або перевизначити образ контейнера в контролері навантаження, такому як Deployments та StatefulSets.
Масив точок входу. Виконується безпосередньо, не у середовищі оболонки. Якщо не надано, буде використано ENTRYPOINT образу контейнера. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Додаткова інформація: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
args ([]string)
Аргументи точки входу. Якщо не надано, буде використано CMD образу контейнера. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Додаткова інформація: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
workingDir (string)
Робоча тека контейнера. Якщо не вказано, буде використано стандартне значення контейнера, яке може бути налаштоване в образі контейнера. Не може бути оновлено.
Порти
ports ([]ContainerPort)
Patch strategy: обʼєднання за ключем containerPort
Map: унікальні значення за ключами containerPort, protocol будуть збережені під час обʼєднання
Список портів, які потрібно відкрити з контейнера. Не вказання порту тут НЕ ЗАПОБІГАЄ його відкриттю. Будь-який порт, який прослуховує стандартну адресу "0.0.0.0" всередині контейнера, буде доступний з мережі. Зміна цього масиву за допомогою стратегічного патча злиття може пошкодити дані. Для отримання додаткової інформації дивіться https://github.com/kubernetes/kubernetes/issues/108255. Не може бути оновлено.
ContainerPort представляє мережевий порт в одному контейнері.
ports.containerPort (int32), обовʼязково
Номер порту для відкриття на IP-адресі контейнера. Це повинен бути дійсний номер порту, 0 < x < 65536.
ports.hostIP (string)
IP-адреса хоста, що звʼязується з зовнішнім портом.
ports.hostPort (int32)
Номер порту для відкриття на хості. Якщо вказано, це повинен бути дійсний номер порту, 0 < x < 65536. Якщо вказано HostNetwork, це значення повинно збігатися з ContainerPort. Більшість контейнерів цього не потребують.
ports.name (string)
Якщо вказано, це повинен бути IANA_SVC_NAME і єдиним в межах Podʼа. Кожен іменований порт в Podʼі повинен мати унікальне імʼя. Назва порту, на яку можна посилатися з Service.
ports.protocol (string)
Протокол для порту. Повинен бути UDP, TCP або SCTP. Стандартне значення — "TCP".
Змінні середовища
env ([]EnvVar)
Patch strategy: обʼєднання за ключем name
Список змінних середовища для встановлення в контейнері. Не може бути оновлено.
EnvVar представляє змінну середовища, присутню в контейнері.
env.name (string), обовʼязково
Назва змінної середовища. Повинно бути C_IDENTIFIER.
env.value (string)
Змінні посилання $(VAR_NAME) розгортаються за допомогою попередньо визначених змінних середовища в контейнері та будь-яких змінних середовища Service. Якщо змінну не вдається розʼязати, посилання відносно введеного рядка буде незмінним. Подвійний $$ зменшується до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): тобто "$$(VAR_NAME)" буде створювати літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгорнуті, незалежно від того, чи існує змінна, чи ні. Стандартне значення — "".
env.valueFrom (EnvVarSource)
Джерело значення змінної середовища. Не може бути використано, якщо значення не є пустим.
Вибирає ресурс контейнера: наразі підтримуються лише обмеження і запити ресурсів (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory та requests.ephemeral-storage).
Зазначає, чи має бути визначений Secret або його ключ
envFrom ([]EnvFromSource)
Список джерел для заповнення змінних середовища в контейнері. Ключі, визначені в межах джерела, повинні бути C_IDENTIFIER. Усі хибні ключі будуть повідомлені як подія при запуску контейнера. Коли ключ існує в декількох джерелах, значення, що асоціюється з останнім джерелом, буде мати пріоритет. Значення, визначене за допомогою Env з дубльованим ключем, буде мати пріоритет. Не може бути оновлено.
EnvFromSource представляє джерело набору ConfigMaps
envFrom.configMapRef (ConfigMapEnvSource)
ConfigMap для вибору з
ConfigMapEnvSource вибирає ConfigMap для заповнення змінними середовища.
Зміст поля Data цільового ConfigMap буде представлено в парах ключ-значення як змінні середовища.
Томи, які будуть змонтовані в файлову систему контейнера. Не може бути оновлено.
VolumeMount описує монтування Тому всередині контейнера.
volumeMounts.mountPath (string), обовʼязково
Шлях всередині контейнера, за яким повинен бути змонтований том. Не повинен містити ':'.
volumeMounts.name (string), обовʼязково
Повинно відповідати імені Тому.
volumeMounts.mountPropagation (string)
mountPropagation визначає, як монтування розповсюджуються від хоста до контейнера і навпаки. Коли не встановлено, використовується MountPropagationNone. Це поле є бета-версією в 1.10.
volumeMounts.readOnly (boolean)
Змонтований як тільки для читання, якщо true, для читання/запису в іншому випадку (false або не вказано). Стандартне значення — false.
volumeMounts.subPath (string)
Шлях всередині тому, з якого має бути змонтований том контейнера. Стандартне значення — "" (корінь тому).
volumeMounts.subPathExpr (string)
Розгорнутий шлях всередині тому, з якого має бути змонтований том контейнера. Поводиться схоже до SubPath, але посилання на змінні середовища $(VAR_NAME) розгортаються за допомогою середовища контейнера. Стандартне значення — "" (корінь тому). SubPathExpr і SubPath є взаємовиключними.
volumeDevices ([]VolumeDevice)
Patch strategy: обʼєднання за ключем devicePath
volumeDevices — це список блочних пристроїв, які будуть використані контейнером.
volumeDevice описує зіставлення необробленого блочного пристрою всередині контейнера.
volumeDevices.devicePath (string), обовʼязково
devicePath — це шлях всередині контейнера, на який буде зіставлено пристрій.
volumeDevices.name (string), обовʼязково
name повинно відповідати імені persistentVolumeClaim в Podʼі.
ResourceRequirements описує вимоги до обчислювальних ресурсів.
resources.claims ([]ResourceClaim)
Map: унікальні значення за ключем будуть збережені під час обʼєднання
Claims містить назви ресурсів, визначених в spec.resourceClaims, які використовуються цим контейнером.
Це поле альфа-версії і вимагає включення функціоналу DynamicResourceAllocation.
Це поле є незмінним. Його можна встановити тільки для контейнерів.
ResourceClaim посилається на один запис в PodSpec.ResourceClaims.
resources.claims.name (string), обовʼязково
Імʼя повинно відповідати імені одного запису в pod.spec.resourceClaims Podʼа, де використовується це поле. Це робить цей ресурс доступним всередині контейнера.
Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється в Limits, якщо це явно вказано, інакше — у значення, визначеного реалізацією. Requests не може перевищувати Limits. Додаткова інформація: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
resizePolicy ([]ContainerResizePolicy)
Atomic: буде замінено під час обʼєднання
Політика зміни розміру ресурсів для контейнера.
ContainerResizePolicy представляє політику зміни розміру ресурсів для контейнера.
resizePolicy.resourceName (string), обовʼязково
Назва ресурсу, до якого застосовується ця політика зміни розміру ресурсу. Підтримувані значення: cpu, memory.
resizePolicy.restartPolicy (string), обовʼязково
Політика перезапуску, яку застосовувати при зміні розміру вказаного ресурсу. Якщо не вказано, то стандартно встановлюється NotRequired.
Життєвий цикл
lifecycle (Lifecycle)
Дії, які система управління повинна виконати у відповідь на події життєвого циклу контейнера. Не може бути оновлено.
Lifecycle описує дії, які система управління повинна виконати у відповідь на події життєвого циклу контейнера. Для обробників життєвого циклу PostStart і PreStop управління контейнером блокується, поки дія не буде завершена, якщо процес контейнера виявляється несправним, тоді обробник переривається.
PreStop викликається негайно перед тим, як контейнер буде завершено через запит API або подію управління, таку як невдача проби справності/запуску, випередження, скорочення ресурсів тощо. Обробник не викликається, якщо контейнер впаде або закінчить роботу. Період перебігу належного завершення підраховується до виконання хуку PreStop. Незалежно від результату обробника, контейнер в кінцевому підсумку завершиться протягом періоду належного завершення Pod (якщо він не буде затриманий завершенням залишкових операцій). Інше управління контейнером блокується, поки хук не завершиться або досягне періоду належного завершення. Додаткова інформація: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks
terminationMessagePath (string)
Необовʼязково: Шлях, за яким файл, до якого буде записано повідомлення про завершення контейнера, буде вмонтовано в файлову систему контейнера. Записане повідомлення, призначено для короткого кінцевого статусу, наприклад, повідомлення про помилку виразу. Якщо воно більше 4096 байт, то вузол скоротить його. Загальна довжина повідомлення по всіх контейнерах буде обмежена 12 кб. Стандартне значення — /dev/termination-log. Не може бути оновлено.
terminationMessagePolicy (string)
Вказує, як має бути заповнене повідомлення про завершення. File використовуватиме вміст terminationMessagePath для заповнення повідомлення про статус контейнера при успіху і невдачі. FallbackToLogsOnError використовуватиме останній шматок виводу логу контейнера, якщо файл повідомлення про завершення пустий і контейнер завершився з помилкою. Вивід логу обмежено 2048 байтами або 80 рядками, якщо це менше. Стандартне значення — File. Не може бути оновлено.
StartupProbe вказує, що Pod успішно ініціалізовано. Якщо вказано, інші проби не виконуються, поки ця не закінчиться успіхом. Якщо цей тест не вдасться, Pod буде перезапущено, так само, як і в разі невдачі livenessProbe. Це може бути використано для надання різних параметрів проби на початку життєвого циклу Podʼа, коли завантаження даних або оновлення кешу може займати довгий час, ніж під час регулярної роботи. Це не може бути оновлено. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
restartPolicy (string)
RestartPolicy визначає поведінку перезапуску окремих контейнерів у Podʼі. Це поле може бути встановлено тільки для контейнерів ініціалізації, і єдине допустиме значення — "Always". Для інших контейнерів, відмінних від контейнерів ініціалізації, або коли це поле не вказано, поведінка перезапуску визначається політикою перезапуску Podʼа і типом контейнера. Встановлення RestartPolicy як "Always" для контейнера ініціалізації матиме наступний ефект: цей контейнер ініціалізації буде постійно перезапускатися при виході, поки всі звичайні контейнери не завершаться. Як тільки всі звичайні контейнери завершаться, всі контейнери ініціалізації з RestartPolicy "Always" будуть вимкнені. Цей життєвий цикл відрізняється від звичайних контейнерів ініціалізації і часто називається "sidecar" контейнер. Хоча цей контейнер ініціалізації все ще запускається у послідовності контейнерів ініціалізації, він не чекає на завершення роботи контейнера, перш ніж переходити до наступного контейнера ініціалізації . Натомість, наступний контейнер ініціалізації запускається одразу після запуску цього контейнера ініціалізації або після успішного завершення будь-якого startupProbe.
SecurityContext містить конфігурацію безпеки, яка буде застосована до контейнера. Деякі поля присутні як у SecurityContext, так і в PodSecurityContext. Якщо обидва встановлені, значення в SecurityContext мають пріоритет.
securityContext.runAsUser (int64)
UID для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо тут не вказано. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.runAsNonRoot (boolean)
Вказує, що контейнер повинен працювати як користувач, що не є root. Якщо true, Kubelet перевірить образ під час виконання, щоб переконатися, що він не працює з UID 0 (root), і не запустить контейнер, якщо це так. Якщо не встановлено або false, така перевірка не виконується. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext.
securityContext.runAsGroup (int64)
GID для запуску точки входу процесу контейнера. Використовує стандартне значення, якщо не встановлено. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.readOnlyRootFilesystem (boolean)
Вказує, чи має цей контейнер кореневу файлову систему тільки для читання. Стандартне значення — false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.procMount (string)
procMount позначає тип монтування proc для використання в контейнерах. Стандартно використовується DefaultProcMount, який використовує стандартні значення для шляхів тільки для читання та маскованих шляхів середовища виконання контейнерів. Це вимагає включення прапорця функції ProcMountType. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.privileged (boolean)
Запуск контейнера в привілейованому режимі. Процеси в привілейованих контейнерах є еквівалентними root на хості. Стандартне значення — false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
AllowPrivilegeEscalation контролює, чи може процес отримати більше привілеїв, ніж його батьківський процес. Це булеве значення безпосередньо контролює, чи буде встановлено прапорець no_new_privs на процесі контейнера. AllowPrivilegeEscalation завжди true, коли контейнер: 1) запускається як привілейований 2) має CAP_SYS_ADMIN. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.capabilities (Capabilities)
Можливості для додавання/видалення під час запуску контейнерів. Стандарто використовується набір можливостей, наданих середовищем виконання контейнера. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
Додає та видаляє можливості POSIX з працюючих контейнерів.
securityContext.capabilities.add ([]string)
Додані можливості.
securityContext.capabilities.drop ([]string)
Видалені можливості.
securityContext.seccompProfile (SeccompProfile)
Параметри seccomp, що використовуються цим контейнером. Якщо параметри seccomp вказані на рівні Pod і контейнера, параметри контейнера мають пріоритет над параметрами Pod. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
SeccompProfile визначає налаштування профілю seccomp для pod/контейнера. Може бути встановлено лише одне джерело профілю.
localhostProfile вказує, що використовується профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі для роботи. Повинен бути низхідним шляхом, відносно до налаштованого місця розташування профілю seccomp kubelet. Повинен бути встановлений, якщо тип є "Localhost". Не повинен бути встановлений для будь-якого іншого типу.
securityContext.seLinuxOptions (SELinuxOptions)
Контекст SELinux, який буде застосований до контейнера. Якщо не вказано, середовище виконання контейнера призначить випадковий контекст SELinux для кожного контейнера. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
SELinuxOptions — це мітки, що застосовуються до контейнера
securityContext.seLinuxOptions.level (string)
Level є міткою рівня SELinux, що застосовується до контейнера.
securityContext.seLinuxOptions.role (string)
Role є міткою ролі SELinux, що застосовується до контейнера.
securityContext.seLinuxOptions.type (string)
Type є міткою типу SELinux, що застосовується до контейнера.
securityContext.seLinuxOptions.user (string)
User є міткою користувача SELinux, що застосовується до контейнера.
Специфічні налаштування для Windows, які застосовуються до всіх контейнерів. Якщо не вказано, використовуються опції з PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є linux.
WindowsSecurityContextOptions містять специфічні для Windows параметри та облікові дані.
HostProcess визначає, чи слід запускати контейнер як контейнер ʼHost Processʼ. Усі контейнери Pod повинні мати однакове значення HostProcess (не дозволено мати суміш контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess є true, то HostNetwork також повинен бути встановлений у true.
Імʼя користувача в Windows для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext.
Налагодження
stdin (boolean)
Чи повинен цей контейнер виділяти буфер для stdin у середовищі виконання контейнера. Якщо це не встановлено, читання з stdin у контейнері завжди буде призводити до EOF. Стандартно — false.
stdinOnce (boolean)
Чи повинне середовище виконання контейнера закрити канал stdin після того, як він був відкритий одним підключенням. Коли stdin дорівнює true, потік stdin залишатиметься відкритим протягом декількох сеансів підключення. Якщо stdinOnce встановлено у true, stdin відкривається під час запуску контейнера, залишається порожнім до першого підключення клієнта до stdin, а потім залишається відкритим і приймає дані до відключення клієнта, після чого stdin закривається і залишається закритим до перезапуску контейнера. Якщо цей прапорець встановлено у false, процеси контейнера, що читають з stdin, ніколи не отримають EOF. Стандартно — false.
tty (boolean)
Чи повинен цей контейнер виділяти для себе TTY, також вимагає, щоб 'stdin' був true. Стандартно — false.
Ефемерний контейнер
Ефемерний контейнер — це тимчасовий контейнер, який ви можете додати до існуючого Pod для ініційованих користувачем дій, таких як налагодження. Ефемерні контейнери не мають гарантій щодо ресурсів або планування, і вони не будуть перезапускатися після завершення роботи або при видаленні чи перезапуску Pod. Kubelet може виселити Pod, якщо ефемерний контейнер спричинить перевищення виділених ресурсів для Pod.
Щоб додати ефемерний контейнер, використовуйте субресурс ephemeralcontainers поточного Pod. Ефемерні контейнери не можуть бути видалені або перезапущені.
name (string), обовʼязкове
Імʼя ефемерного контейнера, вказане як DNS_LABEL. Це імʼя повинно бути унікальним серед усіх контейнерів, контейнерів ініціалізації та ефемерних контейнерів.
targetContainerName (string)
Якщо встановлено, імʼя контейнера з PodSpec, на який націлюється цей ефемерний контейнер. Ефемерний контейнер буде працювати в тих самих просторах імен (IPC, PID тощо), що і цей контейнер. Якщо не встановлено, то ефемерний контейнер використовує простори імен, налаштовані в специфікації Pod.
Середовище виконання контейнера повинно підтримувати цю функцію. Якщо середовище виконання не підтримує націлювання простору імен, то результат налаштування цього поля є невизначеним.
Масив команд для точки входу. Не виконується в оболонці. Використовується ENTRYPOINT образу, якщо це не задано. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Додаткова інформація: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
args ([]string)
Аргументи для точки входу. Якщо не надано, буде використано CMD образу контейнера. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Додаткова інформація: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
workingDir (string)
Робоча тека контейнера. Якщо не вказано, буде використано стандартне значення контейнера, яке може бути налаштоване в образі контейнера. Не може бути оновлено.
Змінні середовища
env ([]EnvVar)
Patch strategy: обʼєднання за ключем name
Список змінних середовища для передачі в контейнер. Не може бути оновлено.
EnvVar представляє змінну середовища, присутню в контейнері.
name (string), обовʼязково
Назва змінної середовища. Повинно бути C_IDENTIFIER.
value (string)
Змінні посилання $(VAR_NAME) розгортаються за допомогою попередньо визначених змінних середовища в контейнері та будь-яких змінних середовища Service. Якщо змінну не вдається розʼязати, посилання відносно введеного рядка буде незмінним. Подвійний $$ зменшується до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): тобто "$$(VAR_NAME)" буде створювати літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгорнуті, незалежно від того, чи існує змінна, чи ні. Стандартне значення — "".
env.valueFrom (EnvVarSource)
Джерело значення змінної середовища. Не може бути використано, якщо значення не є пустим.
Вибирає ресурс контейнера: наразі підтримуються лише обмеження і запити ресурсів (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory та requests.ephemeral-storage).
Зазначає, чи має бути визначений Secret або його ключ
envFrom ([]EnvFromSource)
Список джерел для заповнення змінних середовища в контейнері. Ключі, визначені в межах джерела, повинні бути C_IDENTIFIER. Усі хибні ключі будуть повідомлені як подія при запуску контейнера. Коли ключ існує в декількох джерелах, значення, що асоціюється з останнім джерелом, буде мати пріоритет. Значення, визначене за допомогою Env з дубльованим ключем, буде мати пріоритет. Не може бути оновлено.
EnvFromSource представляє джерело набору ConfigMaps
envFrom.configMapRef (ConfigMapEnvSource)
ConfigMap для вибору з
ConfigMapEnvSource вибирає ConfigMap для заповнення змінними середовища.
Зміст поля Data цільового ConfigMap буде представлено в парах ключ-значення як змінні середовища.
Томи Podʼів для монтування у файлову систему контейнера. Субшляхи монтування в ефемерних контейнерах не дозволяються. Не може бути оновлено.
VolumeMount описує монтування Тому всередині контейнера.
volumeMounts.mountPath (string), обовʼязково
Шлях всередині контейнера, за яким повинен бути змонтований том. Не повинен містити ':'.
volumeMounts.name (string), обовʼязково
Повинно відповідати імені Тому.
volumeMounts.mountPropagation (string)
mountPropagation визначає, як монтування розповсюджуються від хоста до контейнера і навпаки. Коли не встановлено, використовується MountPropagationNone. Це поле є бета-версією в 1.10.
volumeMounts.readOnly (boolean)
Змонтований як тільки для читання, якщо true, для читання/запису в іншому випадку (false або не вказано). Стандартне значення — false.
volumeMounts.subPath (string)
Шлях всередині тому, з якого має бути змонтований том контейнера. Стандартне значення — "" (корінь тому).
volumeMounts.subPathExpr (string)
Розгорнутий шлях всередині тому, з якого має бути змонтований том контейнера. Поводиться схоже до SubPath, але посилання на змінні середовища $(VAR_NAME) розгортаються за допомогою середовища контейнера. Стандартне значення — "" (корінь тому). SubPathExpr і SubPath є взаємовиключними.
volumeDevices ([]VolumeDevice)
Patch strategy: обʼєднання за ключем devicePath
volumeDevices — це список блочних пристроїв, які будуть використані контейнером.
volumeDevice описує зіставлення необробленого блочного пристрою всередині контейнера.
volumeDevices.devicePath (string), обовʼязково
devicePath — це шлях всередині контейнера, на який буде зіставлено пристрій.
volumeDevices.name (string), обовʼязково
name повинно відповідати імені persistentVolumeClaim в Podʼі.
Ресурси
resizePolicy ([]ContainerResizePolicy)
Atomic: буде замінено під час обʼєднання
Політика зміни розміру ресурсів для контейнера.
ContainerResizePolicy представляє політику зміни розміру ресурсів для контейнера.
resizePolicy.resourceName (string), обовʼязково
Назва ресурсу, до якого застосовується ця політика зміни розміру ресурсу. Підтримувані значення: cpu, memory.
resizePolicy.restartPolicy (string), обовʼязково
Політика перезапуску, яку застосовувати при зміні розміру вказаного ресурсу. Якщо не вказано, то стандартно встановлюється NotRequired.
Життєвий цикл
terminationMessagePath (string)
Необовʼязково: Шлях, за яким файл, до якого буде записано повідомлення про завершення контейнера, буде вмонтовано в файлову систему контейнера. Записане повідомлення, призначено для короткого кінцевого статусу, наприклад, повідомлення про помилку виразу. Якщо воно більше 4096 байт, то вузол скоротить його. Загальна довжина повідомлення по всіх контейнерах буде обмежена 12 кб. Стандартне значення — /dev/termination-log. Не може бути оновлено.
terminationMessagePolicy (string)
Вказує, як має бути заповнене повідомлення про завершення. File використовуватиме вміст terminationMessagePath для заповнення повідомлення про статус контейнера при успіху і невдачі. FallbackToLogsOnError використовуватиме останній шматок виводу логу контейнера, якщо файл повідомлення про завершення пустий і контейнер завершився з помилкою. Вивід логу обмежено 2048 байтами або 80 рядками, якщо це менше. Стандартне значення — File. Не може бути оновлено.
restartPolicy (string)
RestartPolicy визначає поведінку перезапуску окремих контейнерів у Podʼі. Це поле може бути встановлено тільки для контейнерів ініціалізації. Ви не можете встановити це поле для ефемерних контейнерів.
Налагодження
stdin (boolean)
Чи повинен цей контейнер виділяти буфер для stdin у середовищі виконання контейнера. Якщо це не встановлено, читання з stdin у контейнері завжди буде призводити до EOF. Стандартно — false.
stdinOnce (boolean)
Чи повинне середовище виконання контейнера закрити канал stdin після того, як він був відкритий одним підключенням. Коли stdin дорівнює true, потік stdin залишатиметься відкритим протягом декількох сеансів підключення. Якщо stdinOnce встановлено у true, stdin відкривається під час запуску контейнера, залишається порожнім до першого підключення клієнта до stdin, а потім залишається відкритим і приймає дані до відключення клієнта, після чого stdin закривається і залишається закритим до перезапуску контейнера. Якщо цей прапорець встановлено у false, процеси контейнера, що читають з stdin, ніколи не отримають EOF. Стандартно — false.
tty (boolean)
Чи повинен цей контейнер виділяти для себе TTY, також вимагає, щоб 'stdin' був true. Стандартно — false.
SecurityContext містить конфігурацію безпеки, яка буде застосована до контейнера. Деякі поля присутні як у SecurityContext, так і в PodSecurityContext. Якщо обидва встановлені, значення в SecurityContext мають пріоритет.
securityContext.runAsUser (int64)
UID для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо тут не вказано. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.runAsNonRoot (boolean)
Вказує, що контейнер повинен працювати як користувач, що не є root. Якщо true, Kubelet перевірить образ під час виконання, щоб переконатися, що він не працює з UID 0 (root), і не запустить контейнер, якщо це так. Якщо не встановлено або false, така перевірка не виконується. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext.
securityContext.runAsGroup (int64)
GID для запуску точки входу процесу контейнера. Використовує стандартне значення, якщо не встановлено. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.readOnlyRootFilesystem (boolean)
Вказує, чи має цей контейнер кореневу файлову систему тільки для читання. Стандартне значення — false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.procMount (string)
procMount позначає тип монтування proc для використання в контейнерах. Стандартно використовується DefaultProcMount, який використовує стандартні значення для шляхів тільки для читання та маскованих шляхів середовища виконання контейнерів. Це вимагає включення прапорця функції ProcMountType. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.privileged (boolean)
Запуск контейнера в привілейованому режимі. Процеси в привілейованих контейнерах є еквівалентними root на хості. Стандартне значення — false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
AllowPrivilegeEscalation контролює, чи може процес отримати більше привілеїв, ніж його батьківський процес. Це булеве значення безпосередньо контролює, чи буде встановлено прапорець no_new_privs на процесі контейнера. AllowPrivilegeEscalation завжди true, коли контейнер: 1) запускається як привілейований 2) має CAP_SYS_ADMIN. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
securityContext.capabilities (Capabilities)
Можливості для додавання/видалення під час запуску контейнерів. Стандарто використовується набір можливостей, наданих середовищем виконання контейнера. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
Додає та видаляє можливості POSIX з працюючих контейнерів.
securityContext.capabilities.add ([]string)
Додані можливості.
securityContext.capabilities.drop ([]string)
Видалені можливості.
securityContext.seccompProfile (SeccompProfile)
Параметри seccomp, що використовуються цим контейнером. Якщо параметри seccomp вказані на рівні Pod і контейнера, параметри контейнера мають пріоритет над параметрами Pod. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
SeccompProfile визначає налаштування профілю seccomp для pod/контейнера. Може бути встановлено лише одне джерело профілю.
localhostProfile вказує, що використовується профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі для роботи. Повинен бути низхідним шляхом, відносно до налаштованого місця розташування профілю seccomp kubelet. Повинен бути встановлений, якщо тип є "Localhost". Не повинен бути встановлений для будь-якого іншого типу.
securityContext.seLinuxOptions (SELinuxOptions)
Контекст SELinux, який буде застосований до контейнера. Якщо не вказано, середовище виконання контейнера призначить випадковий контекст SELinux для кожного контейнера. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.
SELinuxOptions — це мітки, що застосовуються до контейнера
securityContext.seLinuxOptions.level (string)
Level є міткою рівня SELinux, що застосовується до контейнера.
securityContext.seLinuxOptions.role (string)
Role є міткою ролі SELinux, що застосовується до контейнера.
securityContext.seLinuxOptions.type (string)
Type є міткою типу SELinux, що застосовується до контейнера.
securityContext.seLinuxOptions.user (string)
User є міткою користувача SELinux, що застосовується до контейнера.
Специфічні налаштування для Windows, які застосовуються до всіх контейнерів. Якщо не вказано, використовуються опції з PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є linux.
WindowsSecurityContextOptions містять специфічні для Windows параметри та облікові дані.
HostProcess визначає, чи слід запускати контейнер як контейнер ʼHost Processʼ. Усі контейнери Pod повинні мати однакове значення HostProcess (не дозволено мати суміш контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess є true, то HostNetwork також повинен бути встановлений у true.
Імʼя користувача в Windows для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext.
Не дозволяються
ports ([]ContainerPort)
Patch strategy: обʼєднання за ключем containerPort
Map: унікальні значення за ключами containerPort, protocol будуть збережені під час обʼєднання
Для ефемерних контейнерів визначення портів не дозволяється.
ContainerPort представляє мережевий порт в одному контейнері.
ports.containerPort (int32), обовʼязково
Номер порту для відкриття на IP-адресі контейнера. Це повинен бути дійсний номер порту, 0 < x < 65536.
ports.hostIP (string)
IP-адреса хоста, що звʼязується з зовнішнім портом.
ports.hostPort (int32)
Номер порту для відкриття на хості. Якщо вказано, це повинен бути дійсний номер порту, 0 < x < 65536. Якщо вказано HostNetwork, це значення повинно збігатися з ContainerPort. Більшість контейнерів цього не потребують.
ports.name (string)
Якщо вказано, це повинен бути IANA_SVC_NAME і єдиним в межах Podʼа. Кожен іменований порт в Podʼі повинен мати унікальне імʼя. Назва порту, на яку можна посилатися з Service.
ports.protocol (string)
Протокол для порту. Повинен бути UDP, TCP або SCTP. Стандартне значення — "TCP".
resources (ResourceRequirements)
Для ефемерних контейнерів заборонено використовувати ресурси. Ефемерні контейнери використовують вільні ресурси, вже виділені для Podʼа.
resources.claims ([]ResourceClaim)
Map: унікальні значення за ключем будуть збережені під час обʼєднання
Claims містить назви ресурсів, визначених в spec.resourceClaims, які використовуються цим контейнером.
Це поле альфа-версії і вимагає включення функціоналу DynamicResourceAllocation.
Це поле є незмінним. Його можна встановити тільки для контейнерів.
ResourceClaim посилається на один запис в PodSpec.ResourceClaims.
resources.claims.name (string), обовʼязково
Імʼя повинно відповідати імені одного запису в pod.spec.resourceClaims Podʼа, де використовується це поле. Це робить цей ресурс доступним всередині контейнера.
Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється в Limits, якщо це явно вказано, інакше — у значення, визначеного реалізацією. Requests не може перевищувати Limits. Додаткова інформація: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
lifecycle (Lifecycle)
Для ефемерних контейнерів заборонено використовувати lifecycle.
Lifecycle описує дії, які система управління повинна виконати у відповідь на події життєвого циклу контейнера. Для обробників життєвого циклу PostStart і PreStop управління контейнером блокується, поки дія не буде завершена, якщо процес контейнера виявляється несправним, тоді обробник переривається.
PreStop викликається негайно перед тим, як контейнер буде завершено через запит API або подію управління, таку як невдача проби справності/запуску, випередження, скорочення ресурсів тощо. Обробник не викликається, якщо контейнер впаде або закінчить роботу. Період перебігу належного завершення підраховується до виконання хуку PreStop. Незалежно від результату обробника, контейнер в кінцевому підсумку завершиться протягом періоду належного завершення Pod (якщо він не буде затриманий завершенням залишкових операцій). Інше управління контейнером блокується, поки хук не завершиться або досягне періоду належного завершення. Додаткова інформація: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks
Обробник життєвого циклу (LifecycleHandler) визначає конкретну дію, яку слід виконати в хуці життєвого циклу. Має бути вказане тільки одне з полів, за винятком TCPSocket.
exec (ExecAction)
Exec визначає дію, яку слід виконати.
ExecAction описує дію "виконати в контейнері".
exec.command ([]string)
Command — це командний рядок для виконання всередині контейнера, робоча тека для команди — корінь ('/') у файловій системі контейнера. Команда виконується безпосередньо, а не в оболонці, тому традиційні команди оболонки ('|', тощо) не працюватимуть. Для використання оболонки потрібно явно викликати цю оболонку. Статус виходу 0 вважається готовим/справним, а ненульовий — несправним.
httpGet (HTTPGetAction)
HTTPGet визначає HTTP-запит, який слід виконати.
HTTPGetAction описує дію на основі HTTP Get-запитів.
httpGet.port (IntOrString), обовʼязково
Назва або номер порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.
IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.
httpGet.host (string)
Імʼя хосту для підключення, стандартно використовується IP-адреса Podʼа. Ймовірно, вам потрібно встановити "Host" в httpHeaders замість цього.
httpGet.httpHeaders ([]HTTPHeader)
Власні заголовки для встановлення в запиті. HTTP дозволяє повторювані заголовки.
HTTPHeader описує власний заголовок, який буде використовуватись в HTTP-пробах.
httpGet.httpHeaders.name (string), обовʼязково
Назва поля заголовка. Воно буде канонізовано при виведенні, тому імена, що відрізняються регістром, будуть сприйматись як один і той самий заголовок.
httpGet.httpHeaders.value (string), обовʼязково
Значення поля заголовка.
httpGet.path (string)
Шлях для доступу до HTTP-сервера.
httpGet.scheme (string)
Схема для підключення до хоста. Стандартне значення — HTTP.
tcpSocket (TCPSocketAction)
Застаріло. TCPSocket НЕ підтримується як обробник життєвого циклу та зберігається для зворотної сумісності. Валідації цього поля не проводиться, і хуки життєвого циклу зазнають невдачі під час виконання, коли вказано обробник tcp.
TCPSocketAction описує дію на основі відкриття сокета
tcpSocket.port (IntOrString), обовʼязково
Номер або назва порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.
IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.
tcpSocket.host (string)
Додатково: Імʼя хоста для підключення, стандартно використовується IP-адреса Podʼа.
NodeAffinity
Node affinity — це група правил планування вузлів за спорідненістю.
Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо вузол відповідає відповідним matchExpressions; вузол(и) з найвищою сумою є найпріоритетнішими.
Порожній термін пріоритету планування відповідає всім об’єктам з неявною вагою 0 (тобто, він не діє). Нульовий термін пріоритету планування не відповідає жодному обʼєкту (тобто, також не діє).
Термін селектора вузлів, пов’язаний з відповідною вагою.
Нульовий або порожній термін селектора вузлів не відповідає жодному обʼєкту. Вимоги до них обʼєднані за допомогою операції AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.
Якщо вимоги спорідненості, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги спорідненості, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення), система може або не може спробувати врешті-решт виселити Pod з його вузла.
Селектор вузлів представляє обʼєднання результатів одного або кількох запитів за мітками до набору вузлів; тобто він представляє OR селекторів, представлених термінами селектора вузлів.
Обов’язковий. Список термінів селектора вузлів. Терміни обʼєднані за допомогою операції OR.
Нульовий або порожній термін селектора вузлів не відповідає жодному обʼєкту. Вимоги до них обʼєднані за допомогою операції AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.
Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька з цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо на вузлі є Podʼи, які відповідають відповідному podAffinityTerm; вузол(и) з найвищою сумою є найпріоритетнішими.
Ваги всіх відповідних полів WeightedPodAffinityTerm додаються для кожного вузла, щоб знайти найпріоритетніший(і) вузол(и).
Обов’язковий. Термін спорідненості Podʼа, пов’язаний з відповідною вагою.
Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.
Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен, де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.
Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.
Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".
Якщо вимоги спорідненісті, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги спорідненісті, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення міток Podʼа), система може або не може спробувати врешті-решт виселити Pod з його вузла. Коли є кілька елементів, списки вузлів, що відповідають кожному podAffinityTerm, перетинаються, тобто всі терміни мають бути виконані.
Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.
Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен, де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.
Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.
Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".
PodAntiAffinity
Pod anti affinity — це група правил планування між Podʼами за анти-спорідненістю.
Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам анти-спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька з цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази анти-спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо на вузлі є Podʼи, які відповідають відповідному podAffinityTerm; вузол(и) з найвищою сумою є найпріоритетнішими.
Ваги всіх відповідних полів WeightedPodAffinityTerm додаються для кожного вузла, щоб знайти найпріоритетніший(і) вузол(и).
Обов’язковий. Термін спорідненості Podʼа, пов’язаний з відповідною вагою.
Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.
Цей Pod повинен бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен. Розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.
Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.
Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".
Якщо вимоги анти-спорідненості, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги анти-спорідненості, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення міток Podʼа), система може або не може спробувати врешті-решт виселити Pod з його вузла. Коли є кілька елементів, списки вузлів, що відповідають кожному podAffinityTerm, перетинаються, тобто всі терміни мають бути виконані.
Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.
Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен. Розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.
Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.
Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".
Проба
Проба описує перевірку стану, яка виконується для контейнера, щоб визначити, чи він справний або готовий приймати трафік.
exec (ExecAction)
Exec визначає дію, яку потрібно виконати.
ExecAction описує дію "виконати в контейнері".
exec.command ([]string)
Command — це командний рядок для виконання всередині контейнера, робоча тека для команди — корінь ('/') у файловій системі контейнера. Команда виконується безпосередньо, а не в оболонці, тому традиційні команди оболонки ('|', тощо) не працюватимуть. Для використання оболонки потрібно явно викликати цю оболонку. Статус виходу 0 вважається готовим/справним, а ненульовий — несправним.
httpGet (HTTPGetAction)
HTTPGet визначає HTTP-запит для виконання.
HTTPGetAction описує дію на основі HTTP GET запитів.
httpGet.port (IntOrString), обовʼязково
Назва або номер порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.
IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.
httpGet.host (string)
Імʼя хосту для підключення, стандартно використовується IP-адреса Podʼа. Ймовірно, вам потрібно встановити "Host" в httpHeaders замість цього.
httpGet.httpHeaders ([]HTTPHeader)
Власні заголовки для встановлення в запиті. HTTP дозволяє повторювані заголовки.
HTTPHeader описує власний заголовок, який буде використовуватись в HTTP-пробах.
httpGet.httpHeaders.name (string), обовʼязково
Назва поля заголовка. Воно буде канонізовано при виведенні, тому імена, що відрізняються регістром, будуть сприйматись як один і той самий заголовок.
httpGet.httpHeaders.value (string), обовʼязково
Значення поля заголовка.
httpGet.path (string)
Шлях для доступу на HTTP сервері.
httpGet.scheme (string)
Схема для підключення до хоста. Стандартне значення — HTTP.
tcpSocket (TCPSocketAction)
TCPSocket визначає дію, що включає TCP-порт.
TCPSocketAction описує дію на основі відкриття сокету.
tcpSocket.port (IntOrString), обовʼязково
Номер або назва порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.
IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.
tcpSocket.host (string)
Додатково: Імʼя хоста для підключення, стандартно використовується IP-адреса Podʼа.
Необовʼязкова тривалість у секундах, необхідна для завершення роботи Podʼа після збою перевірки. Період належного завершення — це тривалість у секундах після того, як процесам у Podʼі надіслано сигнал про завершення і час до примусової зупинки процесів сигналом kill. Встановіть цю величину більше, ніж очікуваний час завершення вашого процесу. Якщо це значення є nil, буде використано terminationGracePeriodSeconds Podʼа. В іншому випадку, це значення перекриває значення, надане у специфікації Podʼа. Значення має бути невідʼємним числом. Значення нуль означає негайну зупинку через сигнал kill (без можливості завершення). Це поле є бета-функцією і вимагає увімкнення gate ProbeTerminationGracePeriod. Мінімальне значення — 1. Якщо не встановлено, використовується spec.terminationGracePeriodSeconds.
periodSeconds (int32)
Як часто (у секундах) виконувати перевірку. Стандартне значення — 10 секунд. Мінімальне значення — 1.
Мінімальна кількість послідовних збоїв, щоб перевірка вважалася невдалою після того, як вона вже пройшла успішно. Стандартне значення — 3. Мінімальне значення — 1.
successThreshold (int32)
Мінімальна кількість послідовних успішних перевірок, щоб вважати перевірку успішною після того, як вона не вдалася. Стандартне значення — 1. Має бути 1 для liveness та startup. Мінімальне значення — 1.
grpc (GRPCAction)
GRPC визначає дію, що включає GRPC-порт.
**
grpc.port (int32), обовʼязково
Номер порту GRPC сервісу. Номер має бути в діапазоні від 1 до 65535.
Якщо це не вказано, то стандартна поведінка визначається GRPC.
PodStatus
PodStatus представляє інформацію про стан Podʼа. Стан може відставати від фактичного стану системи, особливо якщо вузол, на якому розміщений Pod, не може звʼязатися з панеллю управління.
nominatedNodeName (string)
nominatedNodeName встановлюється тільки тоді, коли цей Pod випереджає інші Podʼи на вузлі, але не може бути негайно розміщений, оскільки жертвам випередження надається час для завершення роботи. Це поле не гарантує, що Pod буде розміщений на цьому вузлі. Планувальник може вирішити розмістити Pod в іншому місці, якщо інші вузли стануть доступними раніше. Планувальник також може вирішити надати ресурси на цьому вузлі Podʼу вищого пріоритету, який створюється після вилучення. В результаті це поле може відрізнятися від PodSpec.nodeName, коли Pod розміщується.
hostIP (string)
hostIP містить IP-адресу хоста, до якого призначено Pod. Пусте, якщо Pod ще не запущено. Pod може бути призначений на вузол, у якого є проблема з kubelet, що означає, що HostIP не буде оновлено, навіть якщо вузол призначено Podʼу.
hostIPs ([]HostIP)
Patch strategy: злиття за ключем ip
Atomic: буде замінено під час злиття
hostIPs містить IP-адреси, виділені хосту. Якщо це поле задано, перший запис повинен відповідати полю hostIP. Цей список пустий, якщо Pod ще не запущено. Pod може бути призначений на вузол, у якого є проблема з kubelet, що означає, що HostIPs не буде оновлено, навіть якщо вузол призначено цьому Podʼу.
HostIP представляє одну IP-адресу, виділену хосту.
hostIPs.ip (string)
IP — це IP-адреса, призначена хосту.
startTime (Time)
RFC 3339 дата і час, коли обʼєкт був підтверджений Kubelet. Це відбувається перед тим, як Kubelet завантажив образ контейнера(ів) для Podʼа.
Time — це обгортка навколо time.Time, яка підтримує правильну серіалізацію в YAML і JSON. Надаються обгортки для багатьох фабричних методів, які пропонує пакет time.
phase (string)
phase Podʼа — це просте, високорівневе резюме про те, на якому етапі свого життєвого циклу знаходиться Pod. Массив умов, поля reason і message, а також масиви статусів окремих контейнерів містять більше деталей про стан Podʼа. Існує пʼять можливих значень фаз:
Pending: Pod прийнято системою Kubernetes, але один або більше образів контейнерів ще не створено. Це включає час до розміщення, а також час, витрачений на завантаження образів через мережу, що може зайняти деякий час.
Running: Pod був привʼязаний до вузла, і всі контейнери були створені. Принаймні один контейнер все ще працює або знаходиться в процесі запуску чи перезапуску.
Succeeded: всі контейнери в Podʼі завершили роботу успішно і не будуть перезапускатися.
Failed: всі контейнери в Podʼі завершили роботу, і принаймні один контейнер завершився з помилкою. Контейнер або завершився з ненульовим статусом, або був завершений системою.
Unknown: з якоїсь причини стан Podʼа не вдалося отримати, зазвичай через помилку у звʼязку з хостом Podʼа.
Повідомлення, зрозуміле людині, що вказує на деталі, чому Pod знаходиться в цьому стані.
reason (string)
Коротке повідомлення у форматі CamelCase, що вказує на деталі, чому Pod знаходиться в цьому стані, наприклад, ʼEvictedʼ.
podIP (string)
podIP — IP-адреса, виділена Podʼу. Доступна для маршрутизації принаймні в межах кластера. Пусте, якщо ще не виділено.
podIPs ([]PodIP)
Patch strategy: злиття за ключем ip
podIPs містить IP-адреси, виділені Podʼу. Якщо це поле задано, 0-й запис повинен відповідати полю podIP. Podʼам може бути виділено не більше одного значення для кожного з IPv4 та IPv6. Цей список пустий, якщо IP-адреси ще не виділено.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.lastTransitionTime (Time)
Останній час, коли стан перейшов з одного статусу в інший.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
Повідомлення, зрозуміле людині, що вказує на деталі останнього переходу.
conditions.reason (string)
Унікальна, однослівна, у CamelCase причина останнього переходу умови.
ContainerStatus містить деталі поточного стану цього контейнера.
ephemeralContainerStatuses ([]ContainerStatus)
Статус будь-яких ефемерних контейнерів, які працювали в цьому Podʼі.
ContainerStatus містить деталі поточного стану цього контейнера.
resourceClaimStatuses ([]PodResourceClaimStatus)
Patch strategies: retainKeys, обʼєднання по ключу name
Map: унікальні значення по ключу name будуть збережені під час обʼєднання
Статус ресурсних заявок.
PodResourceClaimStatus зберігається у PodStatus для кожної PodResourceClaim, яка посилається на ResourceClaimTemplate. Він зберігає згенеровану назву для відповідної ResourceClaim.
resourceClaimStatuses.name (string), обовʼязково
Імʼя унікально ідентифікує цю ресурсну заявку всередині Podʼа. Воно має відповідати імені в pod.spec.resourceClaims, що означає, що рядок повинен бути DNS_LABEL.
resourceClaimStatuses.resourceClaimName (string)
ResourceClaimName — це імʼя ResourceClaim, яке було згенеровано для Podʼа в його просторі імен. Якщо це не встановлено, то генерувати ResourceClaim не було необхідно. В цьому випадку запис pod.spec.resourceClaims можна ігнорувати.
resize (string)
Статус бажаної зміни розміру ресурсів для контейнерів Podʼа. Він порожній, якщо немає очікуваної зміни розміру ресурсів. Будь-які зміни в ресурсах контейнера автоматично встановлять це на "Proposed".
Контейнер, для якого потрібно виводити логи. Стандартно виводяться тільки логи контейнера, якщо в Podʼі є тільки один контейнер.
follow (у запиті): boolean
Слідкувати за потоком логу Podʼа. Стандартне значення — false.
insecureSkipTLSVerifyBackend (у запиті): boolean
insecureSkipTLSVerifyBackend вказує, що apiserver не повинен підтверджувати дійсність сертифікату обслуговуючого програмного забезпечення, з яким він зʼєднується. Це зробить HTTPS-зʼєднання між apiserver та обслуговуючим програмним забезпеченням ненадійним. Це означає, що apiserver не може підтвердити, що дані логу, які він отримує, отримано від реального kubelet. Якщо kubelet налаштований для підтвердження уповноваження TLS apiserver, це не означає, що зʼєднання з реальним kubelet вразливе до атаки посередника (наприклад, зловмисник не зможе перехопити фактичні дані логу, що надходять від реального kubelet).
limitBytes (у запиті): integer
Якщо задано, кількість байтів, які слід прочитати з сервера, перш ніж завершити виведення логу. Це може не показувати повністю останню лінію логу, і може повернути трохи більше або трохи менше, ніж вказаний обмежувач.
Повертати логи попередньо завершених контейнерів. Стандартне значення — false.
sinceSeconds (у запиті): integer
Відносний час у секундах до поточного часу, з якого показувати логи. Якщо це значення передує часу запуску Podʼа, будуть повернуті лише логи з часу запуску Podʼа. Якщо це значення в майбутньому, жодних логів не буде повернено. Можна вказати тільки один з sinceSeconds або sinceTime.
tailLines (у запиті): integer
Якщо задано, кількість рядків з кінця логу, які слід показати. Якщо не вказано, логи показуються з моменту створення контейнера, або відносно sinceSeconds або sinceTime.
timestamps (у запиті): boolean
Якщо true, додаємо часову мітку RFC3339 або RFC3339Nano на початок кожного рядка виводу логу. Стандартне значення — false.
Відповідь
200 (string): OK
401: Unauthorized
get отримати статус вказаного Podʼа
HTTP Запит
GET /api/v1/namespaces/{namespace}/pods/{name}/status
ReplicationControllerSpec — це специфікація контролера реплікації.
selector (map[string]string)
Selector — це запит міток (label query) з Podʼів, які повинні відповідати кількості реплік. Якщо Selector порожній, стандартно встановлюються мітки, які присутні в шаблоні Pod. Ключі та значення міток, які повинні збігатись для контролю цим контролером реплікації, за відсутності стандартних значень встановлюються мітки з шаблону Pod. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)
ReplicationControllerStatus
ReplicationControllerStatus представляє поточний статус контролера реплікації.
Кількість доступних реплік (готових принаймні протягом minReadySeconds) для цього контролера реплікації.
readyReplicas (int32)
Кількість готових реплік для цього контролера реплікації.
fullyLabeledReplicas (int32)
Кількість Podʼів, які мають мітки, що відповідають міткам шаблону Pod контролера реплікації.
conditions ([]ReplicationControllerCondition)
Patch strategy: обʼєднання за ключем type
Представляє останні доступні спостереження поточного стану контролера реплікації.
ReplicationControllerCondition описує стан контролера реплікації в певний момент.
conditions.status (string), обовʼязково
Статус стану, одне з True, False, Unknown.
conditions.type (string), обовʼязково
Тип стану контролера реплікації.
conditions.lastTransitionTime (Time)
Останній час переходу стану з одного статусу в інший.
Time є обгорткою навколо time.Time, яка підтримує правильне перетворення в YAML та JSON. Надаються обгортки для багатьох методів створення, які пропонує пакет time.
conditions.message (string)
Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.
conditions.reason (string)
Причина останнього переходу умови.
observedGeneration (int64)
ObservedGeneration показує покоління останнього спостереження контролера реплікації.
ReplicationControllerList
ReplicationControllerList — це колекція контролерів реплікації.
Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)
ReplicaSetStatus
ReplicaSetStatus відображає поточний стан ReplicaSet.
Кількість доступних реплік (готових протягом принаймні minReadySeconds) для цього набору реплік.
readyReplicas (int32)
readyReplicas — це кількість Podʼів в стані Ready, на які спрямовується цей ReplicaSet.
fullyLabeledReplicas (int32)
Кількість Podʼів, які мають мітки, що відповідають міткам шаблону Podʼа набору реплік.
conditions ([]ReplicaSetCondition)
Patch strategy: злиття за ключем type
Представляє останні доступні спостереження поточного стану набору реплік.
ReplicaSetCondition описує стан набору реплік в певний момент часу.
conditions.status (string), обовʼязково
Статус стану, одне з: True, False, Unknown.
conditions.type (string), обовʼязково
Тип стану набору реплік.
conditions.lastTransitionTime (Time)
Останній раз, коли стан переходив з одного статусу в інший.
Time - це обгортка навколо time.Time, яка підтримує правильне перетворення у YAML і JSON. Надаються обгортки для багатьох методів, які пропонує пакет time.
conditions.message (string)
Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.
conditions.reason (string)
Причина останнього переходу умови.
observedGeneration (int64)
ObservedGeneration показує покоління останнього зафіксованого ReplicaSet.
Селектор міток для Podʼів. Наявні ReplicaSets, чиї Podʼи вибрані за допомогою цього селектора, будуть ті, які будуть змінені цим Deployment. Він повинен відповідати міткам шаблону Podʼа.
Шаблон описує Podʼи, які будуть створені. Єдине допустиме значення для template.spec.restartPolicy — "Always".
replicas (int32)
Кількість бажаних Podʼів. Це вказівник для розрізнення між явним нулем і не вказаним значенням. Стандартне значення — 1.
minReadySeconds (int32)
Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)
strategy (DeploymentStrategy)
Patch strategy: retainKeys
Стратегія розгортання, яку слід використовувати для заміни наявних Podʼів на нові.
DeploymentStrategy описує, як замінити наявні Podʼи новими.
strategy.type (string)
Тип розгортання. Може бути "Recreate" або "RollingUpdate". Стандартне значення — RollingUpdate.
strategy.rollingUpdate (RollingUpdateDeployment)
Параметри конфігурації постійного оновлення. Присутні лише, якщо DeploymentStrategyType = RollingUpdate.
Spec для управління бажаною поведінкою постійного оновлення.
strategy.rollingUpdate.maxSurge (IntOrString)
Максимальна кількість Podʼів, які можуть бути заплановані понад бажану кількість Podʼів. Значення може бути абсолютним числом (наприклад, 5) або відсотком від кількості бажаних Podʼів (наприклад, 10%). Це не може бути 0, якщо MaxUnavailable дорівнює 0. Абсолютне число обчислюється з відсотком, округленим вверх. Стандартне значення — 25%. Наприклад: якщо встановлено 30%, новий ReplicaSet може бути масштабований вгору відразу після початку постійного оновлення, так що загальна кількість старих і нових Podʼів не перевищує 130% від бажаних Podʼів. Після примусового завершення роботи старих Podʼів, новий ReplicaSet можна додатково масштабувати, гарантуючи, що загальна кількість Podʼів, запущених в будь-який момент під час оновлення, становить не більше 130% від бажаної кількості Podʼів
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
Максимальна кількість Podʼів, які можуть бути недоступні під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаних Podʼів (наприклад, 10%). Абсолютне число обчислюється з відсотком шляхом округлення у меншу сторону. Це не може бути 0, якщо MaxSurge дорівнює 0. Стандартне значення — 25%. Наприклад: коли це встановлено на 30%, старий ReplicaSet може бути масштабований вниз до 70% від бажаних Podʼів відразу після початку постійного оновлення. Як тільки нові Podʼи готові, старий ReplicaSet може бути додатково масштабований вниз, разом з масштабованням вгору нового ReplicaSet, забезпечуючи, що загальна кількість Podʼів, доступних у будь-який час під час оновлення, становить принаймні 70% від кількості бажаних Podʼів.
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
revisionHistoryLimit (int32)
Кількість старих ReplicaSets, які слід зберігати для можливості відкату. Це вказівник для розрізнення між явним нулем і не вказаним значенням. Стандартне значення — 10.
progressDeadlineSeconds (int32)
Максимальний час у секундах для Deployment для досягнення прогресу, перш ніж вважати його невдалим. Контролер розгортання буде продовжувати обробляти невдалі Deployment, і у статусі Deployment буде сповіщено причину ProgressDeadlineExceeded. Зверніть увагу, що прогрес не буде оцінюватися під час паузи Deployment. Стандартне значення — 600 с.
paused (boolean)
Показує, що Deployment призупинено.
DeploymentStatus
DeploymentStatus — це найостанніший спостережуваний статус Deployment.
replicas (int32)
Загальна кількість Podʼів, що не завершили роботу, які є ціллю цього Deployment (їх мітки відповідають селектору).
availableReplicas (int32)
Загальна кількість доступних Podʼів (готових принаймні minReadySeconds), які є ціллю цього Deployment.
readyReplicas (int32)
Кількість Podʼів, які є ціллю цього Deployment в стані Ready.
unavailableReplicas (int32)
Загальна кількість недоступних Podʼів, які є ціллю цього Deployment. Це загальна кількість Podʼів, які все ще необхідні для того, щоб Deployment мав 100% доступну потужність. Вони можуть бути Podʼами, які працюють, але ще не доступні, або Podʼами, які ще не були створені.
updatedReplicas (int32)
Загальна кількість незавершених Podʼів, які є ціллю цього Deployment та мають бажаний шаблон специфікацій.
collisionCount (int32)
Кількість колізій хешів для Deployment. Контролер Deployment використовує це поле як механізм уникнення колізій, коли йому потрібно створити імʼя для нового ReplicaSet.
conditions ([]DeploymentCondition)
Patch strategy: злиття за ключем type
Представляє останні доступні спостереження про поточний стан Deployment.
DeploymentCondition описує стан Deployment в певний момент.
conditions.status (string), обовʼязково
Статус стану, одне з True, False, Unknown.
conditions.type (string), обовʼязково
Тип стану Deployment.
conditions.lastTransitionTime (Time)
Останній час, коли стан переходив з одного статусу в інший.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.lastUpdateTime (Time)
Останній раз, коли цей стан було оновлено.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.
conditions.reason (string)
Причина останнього зміни стану.
observedGeneration (int64)
Генерація, що спостерігається контролером Deployment.
Status — це поточний стан Podʼів у цьому StatefulSet. Ці дані можуть бути застарілими на певний проміжок часу.
StatefulSetSpec
StatefulSetSpec — це специфікація StatefulSet.
serviceName (string), обовʼязково
serviceName — це назва Service, який керує цим StatefulSet. Цей сервіс повинен існувати до створення StatefulSet і відповідає за мережеву ідентичність набору. Podʼи отримують DNS/hostnames, які відповідають шаблону: pod-specific-string.serviceName.default.svc.cluster.local, де "pod-specific-string" управляється контролером StatefulSet.
template — це обʼєкт, який описує Pod, що буде створений у випадку недостатньої кількості реплік. Кожен Pod, створений StatefulSet, буде відповідати цьому шаблону, але матиме унікальну ідентичність у порівнянні з іншими Podʼами StatefulSet. Кожен Pod буде названий за форматом <statefulsetname>-<podindex>. Наприклад, Pod у StatefulSet з імʼям "web" з індексом номер "3" буде називатися "web-3". Єдине дозволене значення для template.spec.restartPolicy — "Always".
replicas (int32)
replicas — це бажана кількість реплік даного шаблону. Це репліки в тому сенсі, що вони є екземплярами одного і того ж шаблону, але кожна репліка також має постійну ідентичність. Якщо не вказано, стандартне значення — 1.
updateStrategy (StatefulSetUpdateStrategy)
updateStrategy вказує на StatefulSetUpdateStrategy, яка буде використовуватися для оновлення Podʼів у StatefulSet при внесенні змін до шаблону.
StatefulSetUpdateStrategy вказує стратегію, яку контролер StatefulSet буде використовувати для виконання оновлень. Вона включає будь-які додаткові параметри, необхідні для виконання оновлення для зазначеної стратегії.
updateStrategy.type (string)
Type вказує тип StatefulSetUpdateStrategy. Стандартне значення — RollingUpdate.
Максимальна кількість Podʼів, які можуть бути недоступні під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаної кількості Podʼів (наприклад, 10%). Абсолютна кількість розраховується від відсотків шляхом округлення в більшу сторону. Це не може бути 0. Стандартне значення — 1. Це поле є альфа-рівнем і враховується лише серверами, які підтримують функцію MaxUnavailableStatefulSet. Поле застосовується до всіх Podʼів у діапазоні від 0 до Replicas-1. Це означає, що якщо будь-який Pod у діапазоні від 0 до Replicas-1 недоступний, він буде враховуватися як MaxUnavailable.
IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.
updateStrategy.rollingUpdate.partition (int32)
Partition вказує порядковий номер, на якому StatefulSet повинен бути розділений для оновлень. Під час rolling update всі Podʼи від порядкового номера Replicas-1 до Partition оновлюються. Всі Podʼи від порядкового номера Partition-1 до 0 залишаються незмінними. Це корисно для проведення канаркового розгортання. Стандартне значення — 0.
podManagementPolicy (string)
podManagementPolicy контролює, як Podʼи створюються під час початкового масштабування, при заміні Podʼів на вузлах або при масштабуванні вниз. Стандартне значення — OrderedReady, коли Podʼи створюються в порядку зростання (pod-0, потім pod-1 і т.д.), і контролер чекатиме, поки кожен Pod буде готовий, перш ніж продовжити. При масштабуванні вниз Podʼи видаляються у зворотному порядку. Альтернативною політикою є Parallel, яка створює Podʼи паралельно для досягнення бажаного масштабу без очікування, а при масштабуванні вниз видаляє всі Podʼи одночасно.
revisionHistoryLimit (int32)
revisionHistoryLimit — це максимальна кількість ревізій, які будуть зберігатися в історії ревізій StatefulSet. Історія ревізій складається з усіх ревізій, які не представлені поточною застосованою версією StatefulSetSpec. Стандартне значення — 10.
volumeClaimTemplates — це список запитів, до яких Podʼи можуть звертатися. Контролер StatefulSet відповідає за призначення мережевих ідентичностей запитам таким чином, щоб зберігати ідентичність Podʼа. Кожен запит у цьому списку повинен мати принаймні один відповідний (за імʼям) volumeMount в одному з контейнерів в шаблоні. Запит у цьому списку має пріоритет над будь-якими volumes у шаблоні з таким самим імʼям.
minReadySeconds (int32)
Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)
persistentVolumeClaimRetentionPolicy описує життєвий цикл запитів на постійні томи, створених з volumeClaimTemplates. Стандартно усі запити на постійні томи створюються за необхідності та зберігаються до ручного видалення. Ця політика дозволяє змінювати життєвий цикл, наприклад, видаляючи запити на постійні томи під час видалення їх StatefulSet або при масштабуванні вниз Podʼів. Для цього потрібно включити функцію StatefulSetAutoDeletePVC, яка є альфа-рівнем. +optional
StatefulSetPersistentVolumeClaimRetentionPolicy описує політику, яка використовується для PVC, створених з VolumeClaimTemplates StatefulSet.
WhenDeleted визначає, що відбувається з PVC, створеними з VolumeClaimTemplates StatefulSet, коли StatefulSet видаляється. Стандартна політика Retain призводить до того, що на PVC не впливає видалення StatefulSet. Політика Delete призводить до видалення таких PVC.
WhenScaled визначає, що відбувається з PVC, створеними з VolumeClaimTemplates StatefulSet, коли StatefulSet масштабується вниз. Стандартна політика Retain призводить до того, що на PVC не впливає масштабування вниз. Політика Delete призводить до видалення відповідних PVC для будь-яких зайвих Podʼів, що перевищують кількість реплік.
ordinals (StatefulSetOrdinals)
ordinals контролює нумерацію індексів реплік у StatefulSet. Стандартна поведінка ordinals призначає індекс "0" першій репліці та збільшує індекс на одиницю для кожної додаткової запитаної репліки. Використання поля ordinals вимагає включення функції StatefulSetStartOrdinal, яка є бета-рівнем.
StatefulSetOrdinals описує політику, яка використовується для призначення порядкових номерів реплік у цьому StatefulSet.
ordinals.start (int32)
start — це число, що представляє індекс першої репліки. Його можна використовувати для нумерації реплік з альтернативного індексу (наприклад, з 1) замість стандартної індексації з 0, або для організації поступового переміщення реплік з одного StatefulSet до іншого. Якщо встановлено, індекси реплік будуть у діапазоні:
Якщо не встановлено, стандартне значення — 0. Індекси реплік будуть у діапазоні:
[0, .spec.replicas].
StatefulSetStatus
StatefulSetStatus представляє поточний стан StatefulSet.
replicas (int32), обовʼязково
replicas — це кількість Podʼів, створених контролером StatefulSet.
readyReplicas (int32)
readyReplicas — це кількість Podʼів, створених для цього StatefulSet, які мають стан Ready.
currentReplicas (int32)
currentReplicas — це кількість Podʼів, створених контролером StatefulSet з версії StatefulSet, зазначеної в currentRevision.
updatedReplicas (int32)
updatedReplicas — це кількість Podʼів, створених контролером StatefulSet з версії StatefulSet, зазначеної в updateRevision.
availableReplicas (int32)
Загальна кількість доступних Podʼів (готових принаймні minReadySeconds), на які спрямований цей statefulset.
collisionCount (int32)
collisionCount — це кількість хеш-колізій для StatefulSet. Контролер StatefulSet використовує це поле як механізм уникнення колізій при створенні імені для найновішого ControllerRevision.
conditions ([]StatefulSetCondition)
Patch strategy: злиття за ключем type
Представляє останні доступні спостереження поточного стану StatefulSet.
StatefulSetCondition описує стан StatefulSet у певний момент часу.
conditions.status (string), обовʼязково
Статус стану, один з True, False, Unknown.
conditions.type (string), обовʼязково
Тип стану StatefulSet.
conditions.lastTransitionTime (Time)
Останній час, коли стан переходив з одного статусу в інший.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.
conditions.reason (string)
Причина останнього переходу умови.
currentRevision (string)
currentRevision, якщо не порожній, вказує версію StatefulSet, яка використовується для створення Podʼів у послідовності [0,currentReplicas].
updateRevision (string)
updateRevision, якщо не порожній, вказує версію StatefulSet, яка використовується для створення Podʼів у послідовності [replicas-updatedReplicas,replicas]
observedGeneration (int64)
observedGeneration — останнє покоління, яке спостерігалося для цього StatefulSet. Воно відповідає поколінню StatefulSet, яке оновлюється при зміні сервером API.
ControllerRevision впроваджує незмінюваний знімок даних стану.
apiVersion: apps/v1
import "k8s.io/api/apps/v1"
ControllerRevision
ControllerRevision впроваджує незмінюваний знімок даних стану. Клієнти відповідають за серіалізацію та десеріалізацію обʼєктів, які містять їх внутрішній стан. Після успішного створення ControllerRevision, його не можна оновити. API Server не пройде валідацію всіх запитів, які намагаються змінити поле Data. Однак ControllerRevision може бути видалено. Зверніть увагу, що через використання цього обʼєкта обома контролерами DaemonSet і StatefulSet для оновлення та відкату, він знаходиться на стадії бета-тестування. З усім тим, його назва та представлення можуть змінюватися в майбутніх версіях, і клієнти не повинні покладатися на його стабільність. Він призначений головним чином для внутрішнього використання контролерами.
поле revision показує номер ревізії стану представленого в Data.
data (RawExtension)
Data є серіалізованим представленням стану.
RawExtension використовується для утримання розширень у зовнішніх версіях.
Щоб використовувати це, створіть поле, яке має RawExtension як тип у вашій зовнішній, версійній структурі, і Object у вашій внутрішній структурі. Вам також потрібно зареєструвати різні типи втулків.
// Внутрішній пакет:
type MyAPIObject struct {
runtime.TypeMeta `json:",inline"` MyPlugin runtime.Object `json:"myPlugin"`}
type PluginA struct {
AOption string`json:"aOption"`}
// Зовнішній пакет:
type MyAPIObject struct {
runtime.TypeMeta `json:",inline"` MyPlugin runtime.RawExtension `json:"myPlugin"` }
type PluginA struct {
AOption string`json:"aOption"`}
Що ж відбувається? Спочатку декодування використовує json або yaml для перетворення серіалізованих даних у вашу зовнішню структуру MyAPIObject. Це призводить до збереження сирого JSON, але не до його розпакування. Наступним кроком є копіювання (використовуючи pkg/conversion) у внутрішню структуру. У пакеті runtime, функції перетворення, встановлені в DefaultScheme, розпакують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, якщо обʼєкт невідомого типу, буде створено обʼєкт runtime.Unknown і збережено.)
ControllerRevisionList
ControllerRevisionList — це ресурс, що містить список обʼєктів ControllerRevision.
Обʼєкт, який описує Pod, який буде створено. DaemonSet створює рівно одну копію цього Pod на кожному вузлі, який відповідає селектору вузлів шаблону (або на кожному вузлі, якщо селектор вузлів не вказано). Єдине допустиме значення параметра restartPolicy шаблону — "Always". Докладніше: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template
minReadySeconds (int32)
Мінімальна кількість секунд, протягом яких новий Pod DaemonSet має бути готовим без збоїв будь-якого з його контейнерів, щоб вважатися доступним. Стандартне значення — 0 (Pod вважається доступним, як тільки він буде готовим).
updateStrategy (DaemonSetUpdateStrategy)
Стратегія оновлення для заміни поточних Podʼів DaemonSet новими Podʼами.
DaemonSetUpdateStrategy є структурою, що використовується для управління стратегією оновлення для DaemonSet.
updateStrategy.type (string)
Тип оновлення набору демонів. Може бути "RollingUpdate" або "OnDelete". Стандартне значення — RollingUpdate.
Максимальна кількість вузлів з навним доступним Pod DaemonSet, яка може мати оновлений Pod DaemonSet під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаних Podʼів (наприклад, 10%). Це не може бути 0, якщо MaxUnavailable дорівнює 0. Абсолютне число обчислюється з відсотка, округленого в більшу сторону до мінімуму 1. Стандартне значення — 0. Наприклад: коли це встановлено на 30%, як максимум 30% від загальної кількості вузлів, повинні мати Pod демона (тобто status.desiredNumberScheduled), можуть мати свій новий Pod створений до того, як старий Pod буде видалений. Оновлення починається з запуску нових Podʼів на 30% вузлів. Як тільки оновлений Pod доступний (готовий протягом принаймні minReadySeconds), старий Pod DaemonSet на цьому вузлі позначається як видалений. Якщо старий Pod стає недоступним з будь-якої причини (готовність переходить у false, його виселяють або переносять з вузла), на цьому вузлі негайно створюється оновлений Pod без урахування обмежень по сплеску навантаження. Дозвіл на сплеск означає можливість подвоєння ресурсів, які використовуються DaemonSet на будь-якому вузлі, якщо перевірка готовності не вдається, тому ресурсомісткі DaemonSet повинні враховувати, що вони можуть спричинити виселення під час розладу.
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
Максимальна кількість Podʼів DaemonSet, які можуть бути недоступні під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від загальної кількості Podʼів DaemonSet на початок оновлення (наприклад, 10%). Абсолютне число обчислюється з відсотка, округленого в більшу сторону. Це не може бути 0, якщо MaxSurge дорівнює 0. Стандартне значення — 1. Наприклад: коли це встановлено на 30%, максимум 30% від загальної кількості вузлів, які повинні виконувати Pod демона (тобто status.desiredNumberScheduled), можуть мати свої Pod зупинені для оновлення в будь-який час. Оновлення починається з зупинки не більше 30% цих Podʼів DaemonSet і потім запускає нові Pod DaemonSet на їх місця. Після того, як нові Pod стануть доступними, вони продовжують роботу з іншими Podʼами DaemonSet, забезпечуючи тим самим, що принаймні 70% від початкової кількості Podʼів DaemonSet доступні.
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
revisionHistoryLimit (int32)
Кількість версій історії, яку потрібно зберегти, щоб дозволити відкат. Це вказівник для розрізнення між явним нулем та не вказаним значенням. Стандартне значення — 10.
DaemonSetStatus
DaemonSetStatus представляє поточний стан DaemonSet.
numberReady (int32), обовʼязково
Кількість вузлів, на яких має бути запущений Pod демона й один або кілька з них у стані Ready.
numberAvailable (int32)
Кількість вузлів, на яких має бути запущений Pod демона й один або кілька з них запущені та доступні (готові щонайменше протягом spec.minReadySeconds).
numberUnavailable (int32)
Кількість вузлів, на яких має бути запущений Pod демона, але жоден з них не запущений і доступний (готовий щонайменше протягом spec.minReadySeconds).
Загальна кількість вузлів, на яких запущено оновлений Pod демона.
collisionCount (int32)
Кількість колізій хешів для DaemonSet. Контролер DaemonSet використовує це поле як механізм уникнення колізій при створенні імені для найновішого ControllerRevision.
conditions ([]DaemonSetCondition)
Patch strategy: злиття за ключем type
Представляє останні доступні спостереження поточного стану DaemonSet.
DaemonSetCondition описує стан DaemonSet у певний момент часу.
conditions.status (string), обовʼязково
Статус стану, один із True, False, Unknown.
conditions.type (string), обовʼязково
Тип стану DaemonSet.
conditions.lastTransitionTime (Time)
Час останнього зміни стану з одного статусу до іншого.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.
conditions.reason (string)
Причина останньої зміни стану.
observedGeneration (int64)
Останнє покоління, яке спостерігається контролером набору демонів.
Визначає максимальну бажану кількість Podʼів, які завдання повинно виконувати в будь-який момент часу. Фактична кількість Podʼів, що працюють в стабільному стані, буде меншою за цю кількість, коли ((.spec.completions - .status.successful) < .spec.parallelism), тобто коли залишилося менше роботи, ніж максимально дозволена паралельність. Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
Життєвий цикл
completions (int32)
Визначає бажану кількість успішно завершених Podʼів, які має виконати завдання. Встановлення null означає, що успіх будь-якого Podʼа сигналізує про успіх усіх Podʼів і дозволяє паралельності мати будь-яке позитивне значення. Встановлення значення 1 означає, що паралельність обмежується до 1 і успіх цього Podʼа сигналізує про успіх завдання. Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
completionMode (string)
completionMode визначає, як відстежуються завершення Podʼів. Може бути NonIndexed (стандартно) або Indexed.
NonIndexed означає, що завдання вважається завершеним, коли успішно завершено кількість Podʼів вказана у .spec.completions. Кожне завершення Podʼа є аналогічним до іншого.
Indexed означає, що Podʼи завдання отримують асоційований індекс завершення від 0 до (.spec.completions — 1), доступний в анотації batch.kubernetes.io/job-completion-index. Завдання вважається завершеним, коли для кожного індексу є один успішно завершений Pod. Коли значення Indexed, .spec.completions має бути вказано, а .spec.parallelism має бути менше або дорівнювати 10^5. Крім того, імʼя Podʼа має форму $(job-name)-$(index)-$(random-string), а імʼя хоста Podʼа має форму $(job-name)-$(index).
У майбутньому можуть бути додані інші режими завершення. Якщо контролер завдання спостерігає режим, який він не розпізнає, що можливо під час оновлень через різницю версій, контролер пропускає оновлення для завдання.
backoffLimit (int32)
Визначає кількість спроб перед тим, як відзначити завдання таким, що не вдалося. Стандартне значення — 6.
activeDeadlineSeconds (int64)
Визначає тривалість у секундах відносно startTime, протягом якої завдання може бути активним, перш ніж система спробує його завершити; значення має бути додатним цілим числом. Якщо завдання призупинено (під час створення або через оновлення), цей таймер фактично зупиняється і скидається, коли завдання знову відновлюється.
ttlSecondsAfterFinished (int32)
ttlSecondsAfterFinished обмежує термін життя завдання, яке завершило виконання (або Complete, або Failed). Якщо це поле встановлено, то через ttlSecondsAfterFinished після завершення завдання воно може бути автоматично видалене. Коли завдання видаляється, його життєвий цикл (наприклад, завершувачі) буде враховуватись. Якщо це поле не встановлено, завдання не буде автоматично видалено. Якщо це поле встановлено на нуль, завдання може бути видалене відразу після завершення.
suspend (boolean)
suspend визначає, чи повинен контролер завдання створювати Podʼи чи ні. Якщо завдання створюється з параметром suspend, встановленим на true, контролер завдання не створює Podʼи. Якщо завдання призупиняється після створення (тобто прапорець змінюється з false на true), контролер завдання видалить усі активні Podʼи, повʼязані з цим завданням. Користувачі повинні спроєктувати своє робоче навантаження так, щоб воно могло правильно обробляти це. Призупинення завдання скине поле StartTime завдання, фактично скидаючи таймер ActiveDeadlineSeconds. Стандартне значення — false.
manualSelector керує генерацією міток Podʼів і селекторів Podʼів. Залиште manualSelector невстановленим, якщо ви не впевнені, що робите. Коли значення false або невстановлене, система вибирає унікальні мітки для цього завдання та додає ці мітки до шаблону Podʼа. Коли значення true, користувач відповідає за вибір унікальних міток і вказування селектора. Невдача у виборі унікальної мітки може спричинити некоректну роботу цього та інших завдань. Однак ви можете побачити manualSelector=true у завданнях, створених за допомогою старого API extensions/v1beta1. Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector
Бета-рівень
podFailurePolicy (PodFailurePolicy)
Визначає політику обробки невдалих Podʼів. Зокрема, дозволяє вказати набір дій та умов, які повинні бути виконані для виконання повʼязаної дії. Якщо це поле порожнє, застосовується стандартна поведінка — лічильник невдалих Podʼів, представлений полем .status.failed завдання, збільшується і перевіряється з backoffLimit. Це поле не можна використовувати в комбінації з restartPolicy=OnFailure.
Це поле рівня бета. Воно може бути використане, коли ввімкнено прапорець JobPodFailurePolicy (стандартно увімкнено).
PodFailurePolicy описує, як невдалі Podʼи впливають на backoffLimit.
Список правил політики невдач Podʼів. Правила оцінюються послідовно. Як тільки правило відповідає невдачі Podʼа, решта правил ігнорується. Якщо жодне правило не відповідає невдачі Podʼа, застосовується стандартна обробка — лічильник невдач Podʼів збільшується і перевіряється з backoffLimit. Максимально дозволено 20 елементів.
PodFailurePolicyRule описує, як обробляється невдача Podʼа, коли виконуються вимоги. Одне з onExitCodes і onPodConditions, але не обидва, можуть бути використані в кожному правилі.
Визначає дію, яка виконується при невдачі Podʼа, коли виконуються вимоги. Можливі значення:
FailJob: означає, що завдання Podʼа позначається як Failed і всі
запущені Podʼи завершуються.
FailIndex: означає, що індекс Podʼа позначається як Failed і не буде
перезапущений. Це значення рівня альфа. Воно може бути використане, коли ввімкнено
прапорець JobBackoffLimitPerIndex (стандартно вимкнено).
Ignore: означає, що лічильник по відношенню до .backoffLimit не збільшується і створюється Pod заміна.
Count: означає, що Pod обробляється стандартним способом — лічильник .backoffLimit збільшується.
Додаткові значення можуть бути додані в майбутньому. Клієнти повинні реагувати на невідому дію, пропускаючи правило.
Представляє вимогу до стану Podʼа. Вимога представлена як список шаблонів стан Podʼа. Вимога задовольняється, якщо хоча б один шаблон відповідає фактичному стану Podʼа. Максимально дозволено 20 елементів.
PodFailurePolicyOnPodConditionsPattern описує шаблон для відповідності фактичний стан Podʼа.
Визначає необхідний статус стану Podʼа. Для відповідності стану Podʼа потрібно, щоб зазначений статус відповідав статусу стану Podʼа. Стандартне значення — True.
Представляє вимогу до кодів завершення контейнера.
PodFailurePolicyOnExitCodesRequirement описує вимогу для обробки невдалого Podʼа на основі кодів завершення його контейнера. Зокрема, перевіряється .state.terminated.exitCode для кожного контейнера застосунку та init-контейнера, представленого полями .status.containerStatuses і .status.initContainerStatuses у статусі Podʼа відповідно. Контейнери, завершені успішно (код завершення 0), виключаються з перевірки вимоги.
Представляє стосунок між кодом(ами) завершення контейнера та зазначеними значеннями. Контейнери, завершені успішно (код завершення 0), виключаються з перевірки вимоги. Можливі значення:
In: вимога задовольняється, якщо хоча б один код завершення контейнера (може бути кілька, якщо є кілька контейнерів, не обмежених полем 'containerName') входить до набору зазначених значень.
NotIn: вимога задовольняється, якщо хоча б один код завершення контейнера (може бути кілька, якщо є кілька контейнерів, не обмежених полем 'containerName') не входить до набору зазначених значень.
Додаткові значення можуть бути додані в майбутньому. Клієнти повинні реагувати на невідомий оператор, вважаючи, що вимога не задоволена.
Set: унікальні значення зберігатимуться під час обʼєднання
Визначає набір значень. Кожен повернутий код завершення контейнера (може бути кілька у випадку кількох контейнерів) перевіряється щодо цього набору значень з урахуванням оператора. Список значень має бути впорядкованим і не містити дублікатів. Значення '0' не може бути використано для оператора In. Потрібен принаймні один елемент. Максимально дозволено 255 елементів.
Обмежує перевірку кодів завершення контейнера контейнером з зазначеним імʼям. Коли null, правило застосовується до всіх контейнерів. Коли зазначено, воно має відповідати одному з імен контейнерів або init-контейнерів у шаблоні Podʼа.
Альфа-рівень
backoffLimitPerIndex (int32)
Визначає ліміт кількості повторних спроб в межах індексу перед тим, як позначити цей індекс як невдалий. Коли цей параметр увімкнений, кількість невдач по індексу зберігається в анотації Podʼа batch.kubernetes.io/job-index-failure-count. Це поле можна встановити лише при completionMode=Indexed для завдання, і політика перезапуску Podʼа повинна бути Never. Поле незмінне. Це поле на рівні альфа. Воно може бути використане, коли ввімкнено прапорець JobBackoffLimitPerIndex (стандартно вимкнено).
maxFailedIndexes (int32)
Визначає максимальну кількість невдалих індексів перед тим, як позначити завдання як невдале, коли backoffLimitPerIndex встановлено. Як тільки кількість невдалих індексів перевищує це число, все завдання позначається як Failed і його виконання припиняється. Якщо залишити null, завдання продовжує виконання всіх своїх індексів і позначається станом завдання Complete. Це поле можна вказати лише, коли встановлено backoffLimitPerIndex. Воно може бути null або дорівнювати кількості completions. Воно обовʼязково і повинно бути менше або дорівнювати 10^4, коли кількість completions більша за 10^5. Це поле на рівні альфа. Воно може бути використане, коли ввімкнено прапорець JobBackoffLimitPerIndex (стандартно вимкнено).
podReplacementPolicy (string)
podReplacementPolicy визначає, коли створювати нові Podʼи на заміну. Можливі значення:
TerminatingOrFailed означає, що ми створюємо Podʼи повторно, коли вони завершуються (мають metadata.deletionTimestamp) або не зазнали збою.
Failed означає, що потрібно чекати, поки раніше створений Pod повністю завершиться (має phase Failed або Succeeded) перед створенням нового Podʼа на заміну.
При використанні podFailurePolicy, Failed є єдиним допустимим значенням. TerminatingOrFailed і Failed є допустимими значеннями, коли podFailurePolicy не використовується. Це поле на рівні альфа. Увімкніть JobPodReplacementPolicy, щоб мати змогу використовувати це поле.
JobStatus
JobStatus представляє поточний стан Job.
startTime (Time)
Представляє час, коли контролер Job почав обробку завдання. Коли Job створюється в призупиненому стані, це поле не встановлюється до першого відновлення. Це поле скидається кожного разу, коли Job відновлюється після призупинення. Воно представлене у форматі RFC3339 і є в UTC.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
completionTime (Time)
Представляє час, коли завдання було завершено. Це поле може не встановлюватися в порядку "відбувається перед" у різних операціях. Воно представлене у форматі RFC3339 і є в UTC. Час завершення встановлюється лише тоді, коли завдання успішно завершується.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
active (int32)
Кількість Podʼів в стані очікування та працюючих Podʼів.
failed (int32)
Кількість Podʼів, які досягли фази Failed.
succeeded (int32)
Кількість Podʼів, які досягли фази Succeeded.
completedIndexes (string)
completedIndexes містить завершені індекси, коли .spec.completionMode = "Indexed" у текстовому форматі. Індекси представлені у вигляді десяткових чисел, розділених комами. Числа перелічені у порядку зростання. Три або більше послідовних числа стискаються і представлені першим і останнім елементами серії, розділеними дефісом. Наприклад, якщо завершені індекси 1, 3, 4, 5 і 7, вони представлені як "1,3-5,7".
conditions ([]JobCondition)
Patch strategy: обʼєднання за ключем type
Atomic: буде замінено під час обʼєднання
Останні доступні спостереження за поточним станом обʼєкта. Коли Job не вдається, один зі станів матиме тип "Failed" і статус true. Коли Job призупинено, один зі станів матиме тип "Suspended" і статус true; коли Job відновлюється, статус цього стану стає false. Коли Job завершено, один з станів матиме тип "Complete" і статус true. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
JobCondition описує поточний стан завдання.
conditions.status (string), обовʼязково
Статус стану, одне з True, False, Unknown.
conditions.type (string), обовʼязково
Тип стану завдання, Complete або Failed.
conditions.lastProbeTime (Time)
Останній раз, коли стан було перевірено.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.lastTransitionTime (Time)
Останній раз, коли стан переходила з одного статусу в інший.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
Повідомлення, зрозуміле людині, із зазначенням деталей останнього переходу.
conditions.reason (string)
(коротка) причина останнього переходу стану.
uncountedTerminatedPods (UncountedTerminatedPods)
uncountedTerminatedPods містить UID Podʼів, які завершили роботу, але контролер завдань ще не врахував їх у статусних лічильниках.
Контролер завдань створює Podʼи з завершувачем. Коли Pod завершується (успішно або з помилкою), контролер виконує три кроки для врахування його у статусі завдання:
Додає UID Podʼа до масивів у цьому полі.
Видаляє завершувач Podʼа.
Видаляє UID Podʼа з масивів, збільшуючи відповідний лічильник.
Старі завдання можуть не відстежуватися з використанням цього поля, у такому випадку поле залишається порожнім.
UncountedTerminatedPods містить UID Podʼів, які завершили роботу, але ще не враховані в лічильниках статусу завдання.
uncountedTerminatedPods.failed ([]string)
Set: унікальні значення зберігатимуться під час обʼєднання
failed містить UID Podʼів, що завершилися з помилкою.
uncountedTerminatedPods.succeeded ([]string)
Set: унікальні значення зберігатимуться під час обʼєднання
succeeded містить UID Podʼів, що завершилися успішно.
Бета-рівень
ready (int32)
Кількість Podʼів, які мають стан Ready.
Це поле знаходиться на бета-рівні. Контролер завдань заповнює це поле, коли ввімкнено функцію JobReadyPods (стандартно увімкнено).
Альфа-рівень
failedIndexes (string)
FailedIndexes зберігає невдалі індекси, коли backoffLimitPerIndex=true. Індекси представлені у текстовому форматі, аналогічному до поля completedIndexes, тобто вони зберігаються як десяткові цілі числа, розділені комами. Числа подані в порядку зростання. Три або більше послідовних числа стискаються і представлені першим та останнім елементом серії, розділеними дефісом. Наприклад, якщо невдалі індекси: 1, 3, 4, 5 і 7, вони представлені як "1,3-5,7". Це поле знаходиться на альфа-рівні. Його можна використовувати, коли ввімкнено функцію JobBackoffLimitPerIndex (стандартно вимкнено).
terminating (int32)
Кількість Podʼів, які завершуються (у фазі Pending або Running та мають deletionTimestamp).
Це поле знаходиться на альфа-рівні. Контролер завдань заповнює це поле, коли ввімкнено функцію JobPodReplacementPolicy (стандартно вимкнено).
Назва часового поясу для вказаного розкладу, див. https://en.wikipedia.org/wiki/List_of_tz_database_time_zones. Якщо не вказано, то буде використовуватись часовий пояс процесу kube-controller-manager. Допустимі назви часових поясів і зміщення завантажуються з системної бази даних часових поясів API-сервером під час валідації CronJob і контролером під час виконання. Якщо системна база даних часових поясів недоступна, використовується вбудована версія цієї бази. Якщо назва часового поясу стає недійсною протягом життєвого циклу CronJob або через зміну конфігурації хосту, контролер перестане створювати нові задачі та створить системну подію з причиною UnknownTimeZone. Додаткову інформацію можна знайти в https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zones.
concurrencyPolicy (string)
Визначає, як обробляти одночасні виконання задачі. Допустимі значення:
"Allow" (стандартно): дозволяє CronJobs запускати задачі одночасно;
"Forbid": забороняє одночасні виконання, пропускаючи наступний запуск, якщо попередній ще не завершився;
"Replace": скасовує поточну задачу і замінює її новою.
startingDeadlineSeconds (int64)
Необовʼязковий термін у секундах для запуску задачі, якщо вона пропустить запланований час з будь-якої причини. Пропущені виконання задач будуть вважатися неуспішними.
suspend (boolean)
Цей прапорець каже контролеру призупиняти подальші виконання, він не застосовується до вже запущених виконань. Стандартне значення — false.
successfulJobsHistoryLimit (int32)
Кількість успішно завершених задач, які потрібно зберегти. Значення повинно бути не відʼємним цілим числом. Стандартне значення — 3.
failedJobsHistoryLimit (int32)
Кількість невдало завершених задач, які потрібно зберегти. Значення повинно бути не відʼємним цілим числом. Стандартне значення — 1.
Інформація про час останнього успішного запуску задачі.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
lastSuccessfulTime (Time)
Інформація про час останнього успішного завершення задачі.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
посилання на масштабований ресурс; горизонтальний автомасштабувальник Podʼів буде вивчати поточне використання ресурсу і встановлювати бажану кількість Podʼів за допомогою його субресурсу Scale (масштаб).
CrossVersionObjectReference містить достатньо інформації для ідентифікації зазначеного ресурсу.
minReplicas — нижня межа для кількості реплік, до яких може масштабуватися автомасштабувальник. Стандартне значення — 1 Pod. minReplicas може бути 0, якщо увімкнутий альфа-функціонал HPAScaleToZero і налаштовано принаймні одну метрику Object або External. Масштабування активне, поки є принаймні значення однієї метрики.
targetCPUUtilizationPercentage (int32)
targetCPUUtilizationPercentage — це цільове середнє використання CPU (представлене як відсоток від запитаного показника CPU) для всіх Podʼів; якщо не вказано, буде використана стандартна політика автоматичного масштабування.
HorizontalPodAutoscalerStatus
Поточний статус горизонтального автомасштабування Podʼів.
currentReplicas (int32), обовʼязково
currentReplicas — поточна кількість реплік Podʼів, що керуються цим автомасштабувальником.
desiredReplicas (int32), обовʼязково
desiredReplicas — бажана кількість реплік Podʼів, що керуються цим автомасштабувальником.
currentCPUUtilizationPercentage (int32)
currentCPUUtilizationPercentage — поточне середнє використання CPU у всіх Podʼах, виражене як відсоток від запитаної кількості CPU; наприклад, значення 70 означає, що в середньому Pod використовує зараз 70% свого запитаного CPU.
lastScaleTime (Time)
lastScaleTime — час останнього масштабування HorizontalPodAutoscaler кількості Podʼів; використовується автомасштабувальником для контролю частоти змін кількості Podʼів.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
observedGeneration (int64)
observedGeneration — останнє покоління, сяке спостерігається цим автомасштабувальником.
HorizontalPodAutoscalerList
Список обʼєктів горизонтального автомасштабування Podʼів.
HorizontalPodAutoscaler — це конфігурація для горизонтального автомасштабування, яка автоматично керує кількістю реплік будь-якого ресурсу, що реалізує субресурс масштабування, на основі вказаних метрик.
apiVersion: autoscaling/v2
import "k8s.io/api/autoscaling/v2"
HorizontalPodAutoscaler
HorizontalPodAutoscaler — це конфігурація для горизонтального автомасштабування, яка автоматично керує кількістю реплік будь-якого ресурсу, що реалізує субресурс масштабування, на основі вказаних метрик.
minReplicas — нижня межа кількості реплік, до якої може масштабуватись автомасштабувальник. Стандартне значення — 1 Pod. minReplicas може бути 0, якщо ввімкнути альфа-функцію HPAScaleToZero і налаштувати щонайменше одну метрику типу Object або External. Масштабування активне, поки є принаймні одне значення метрики.
behavior (HorizontalPodAutoscalerBehavior)
behavior — налаштовує поведінку масштабування цільового ресурсу як в напрямку збільшення, так і в напрямку зменшення (поля scaleUp та scaleDown відповідно). Якщо не вказано, будуть використані типові правила масштабування HPAScalingRules для збільшення і зменшення.
HorizontalPodAutoscalerBehavior налаштовує поведінку масштабування цільового ресурсу як в напрямку збільшення, так і в напрямку зменшення (поля scaleUp та scaleDown відповідно).
behavior.scaleDown (HPAScalingRules)
scaleDown — політика масштабування для зменшення. Якщо не встановлено, типове значення дозволяє зменшувати до minReplicas Podʼів з вікном стабілізації 300 секунд (тобто використовується найкраще рекомендоване значення за останні 300 секунд).
HPAScalingRules налаштовує поведінку масштабування для одного напрямку. Ці правила застосовуються після обчислення бажаної кількості реплік з метрик для HPA. Вони можуть обмежувати швидкість масштабування, вказуючи політики масштабування, та запобігати "повзучості" за допомогою визначення вікна стабілізації, щоб кількість реплік не встановлювалась миттєво, а вибирався найбезпечніше значення з вікна стабілізації.
behavior.scaleDown.policies ([]HPAScalingPolicy)
Atomic: will be replaced during a merge
policies — список потенційних політик масштабування, які можуть використовуватись під час масштабування. Принаймні одна політика повинна бути вказана, інакше HPAScalingRules буде відкинуто як недійсне
HPAScalingPolicy — це одна політика, яка повинна виконуватися для вказаного інтервалу в минулому.
periodSeconds — визначає вікно часу, протягом якого політика повинна бути true. PeriodSeconds повинен бути більше нуля і менше або рівний 1800 (30 хвилин).
behavior.scaleDown.selectPolicy (string)
selectPolicy — використовується для зазначення того, яка політика повинна бути використана. Якщо не встановлено, використовується типове значення Max.
stabilizationWindowSeconds — кількість секунд, протягом яких враховуються попередні рекомендації під час збільшення або зменшення масштабування. stabilizationWindowSeconds повинен бути більше або рівний нулю і менше або рівний 3600 (одна година). Якщо не встановлено, використовуються типові значення:
Для збільшення масштабування: 0 (тобто стабілізація не виконується).
Для зменшення масштабування: 300 (тобто вікно стабілізації 300 секунд).
behavior.scaleUp (HPAScalingRules)
scaleUp — це політика масштабування вгору. Якщо не встановлено, використовується стандартне значення, яке є найбільшим з:
збільшення не більше ніж на 4 Podʼи за 60 секунд
подвоєння кількості Podʼів за 60 секунд
Стабілізація не використовується.
HPAScalingRules налаштовує поведінку масштабування в одному напрямку. Ці правила застосовуються після обчислення DesiredReplicas з метрик для HPA. Вони можуть обмежити швидкість масштабування, вказуючи політики масштабування. Вони можуть запобігти нестабільному масштабуванню, вказуючи вікно стабілізації, щоб кількість реплік не змінювалася миттєво, а вибиралося найбезпечніше значення з вікна стабілізації.
behavior.scaleUp.policies ([]HPAScalingPolicy)
Atomic: буде замінено під час обʼєднання
policies — це список можливих політик масштабування, які можуть бути використані під час масштабування. Має бути вказана принаймні одна політика, інакше HPAScalingRules буде вважатися недійсним.
HPAScalingPolicy — це окрема політика, якої треба має бути true протягом заданого інтервалу в минулому.
periodSeconds визначає вікно часу, протягом якого політика має бути true. PeriodSeconds має бути більше нуля та менше або дорівнювати 1800 (30 хвилин).
behavior.scaleUp.selectPolicy (string)
selectPolicy використовується для вказівки, яка політика має бути використана. Якщо не встановлено, використовується стандартне значення Max.
stabilizationWindowSeconds — це кількість секунд, протягом яких минулі рекомендації мають враховуватися під час масштабування вгору або вниз. StabilizationWindowSeconds має бути більше або дорівнювати нулю та менше або дорівнювати 3600 (одна година). Якщо не встановлено, використовуються стандартні значення:
Для масштабування вгору: 0 (тобто стабілізація не виконується).
Для масштабування вниз: 300 (тобто вікно стабілізації триває 300 секунд).
metrics ([]MetricSpec)
Atomic: буде замінено під час обʼєднання
metrics містить специфікації для обчислення бажаної кількості реплік (буде використана максимальна кількість реплік за всіма метриками). Бажана кількість реплік обчислюється множенням відношення між цільовим значенням та поточним значенням на поточну кількість Podʼів. Таким чином, метрики, що використовуються, мають зменшуватися зі збільшенням кількості Podʼів, і навпаки. Дивіться індивідуальні типи джерел метрик для отримання додаткової інформації про те, як кожен тип метрик має реагувати. Якщо не встановлено, стандартна метрика з буде встановлена на 80% середнього використання CPU.
MetricSpec визначає, як масштабуватися на основі однієї метрики (лише type та одне інше відповідне поле мають бути встановлені одночасно).
metrics.type (string), обовʼязково
type — тип джерела метрики. Має бути одним з "ContainerResource", "External", "Object", "Pods" або "Resource", кожен з яких відповідає відповідному полю в обʼєкті. Примітка: тип "ContainerResource" доступний лише за умови, що увімкнено функцію HPAContainerMetrics.
containerResource стосується метрики ресурсу (наприклад, ті, що вказані в запитах і лімітах), відомої Kubernetes, яка описує один контейнер у кожному Podʼі поточного цільового масштабу (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен Pod за допомогою джерела "pods". Це альфа-функція і може бути увімкнена прапорцем функції HPAContainerMetrics.
ContainerResourceMetricSource вказує, як масштабуватися на основі метрики ресурсу, відомої Kubernetes, як вказано в запитах і лімітах, описуючи кожен Pod у поточному цільовому масштабі (наприклад, CPU або памʼять). Значення будуть усереднені перед порівнянням з цільовим значенням. Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен Pod за допомогою джерела "pods". Має бути встановлений лише один тип "target".
averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.
value — це цільове значення метрики (як кількість).
metrics.external (ExternalMetricSource)
external стосується глобальної метрики, яка не повʼязана з жодним обʼєктом Kubernetes. Це дозволяє автоматичне масштабування на основі інформації, що надходить від компонентів, які працюють за межами кластера (наприклад, довжина черги у хмарному сервісі обміну повідомленнями або QPS від балансувальника навантаження, що працює за межами кластера).
ExternalMetricSource вказує, як масштабуватися на основі метрики, не повʼязаної з жодним обʼєктом Kubernetes (наприклад, довжина черги у хмарному сервісі обміну повідомленнями або QPS від балансувальника навантаження, що працює за межами кластера).
selector — це строкове кодування стандартного селектора міток Kubernetes для даної метрики. Якщо встановлено, він передається як додатковий параметр серверу метрик для більш специфічного вибору метрик. Якщо не встановлено, для збору метрик буде використовуватися лише назва метрики.
averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.
value – це цільове значення метрики (як кількість).
metrics.object (ObjectMetricSource)
object — стосується метрики, що описує один обʼєкт Kubernetes (наприклад, кількість запитів на секунду на обʼєкті Ingress).
ObjectMetricSource вказує, як масштабуватися на основі метрики, що описує обʼєкт Kubernetes (наприклад, кількість запитів на секунду на обʼєкті Ingress).
selector — це строкове кодування стандартного селектора міток Kubernetes для даної метрики. Якщо встановлено, він передається як додатковий параметр серверу метрик для більш специфічного вибору метрик. Якщо не встановлено, для збору метрик буде використовуватися лише назва метрики.
metrics.object.target (MetricTarget), обовʼязково
target — визначає цільове значення для даної метрики.
MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.
metrics.object.target.type (string), обовʼязково
type — представляє, чи є тип метрики Utilization, Value або AverageValue.
metrics.object.target.averageUtilization (int32)
averageUtilization — цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.
pods — стосується метрики, що описує кожен Pod у поточному цільовому масштабі (наприклад, кількість транзакцій на секунду). Значення будуть усереднені перед порівнянням з цільовим значенням.
PodsMetricSource вказує, як масштабуватися на основі метрики, що описує кожен Pod у поточному цільовому масштабі (наприклад, кількість транзакцій на секунду). Значення будуть усереднені перед порівнянням з цільовим значенням.
selector — це строкове кодування стандартного селектора міток Kubernetes для даної метрики. Якщо встановлено, він передається як додатковий параметр серверу метрик для більш специфічного вибору метрик. Якщо не встановлено, для збору метрик буде використовуватися лише назва метрики.
metrics.pods.target (MetricTarget), обовʼязково
target визначає цільове значення для даної метрики.
MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.
metrics.pods.target.type (string), обовʼязково
type — представляє, чи є тип метрики Utilization, Value або AverageValue.
metrics.pods.target.averageUtilization (int32)
averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.
value — це цільове значення метрики (як кількість).
metrics.resource (ResourceMetricSource)
resource — стосується метрики ресурсу (наприклад, ті, що вказані в запитах і лімітах), відомої Kubernetes, яка описує кожен у поточному цільовому масштабі (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен за допомогою джерела "pods".
ResourceMetricSource вказує, як масштабуватися на основі метрики ресурсу, відомої Kubernetes, як вказано в запитах і лімітах, описуючи кожен у поточному цільовому масштабі (наприклад, CPU або памʼять). Значення будуть усереднені перед порівнянням з цільовим значенням. Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен под за допомогою джерела "pods". Повинен бути встановлений лише один тип "target".
averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.
value —це цільове значення метрики (як кількість).
HorizontalPodAutoscalerStatus
HorizontalPodAutoscalerStatus описує поточний стан горизонтального автомасштабувальника Podʼів.
desiredReplicas (int32), обовʼязково
desiredReplicas — це бажана кількість реплік Podʼів, якими керує цей автомасштабувальник, відповідно до останнього обчислення автомасштабувальника.
conditions ([]HorizontalPodAutoscalerCondition)
Patch strategy: обʼєднання за ключем type
Map: під час обʼєднання зберігатимуться унікальні значення за ключем type
conditions — це набір станів, необхідних для масштабування цільового обʼєкта автомасштабувальником, та вказує, чи було їх досягнуто.
HorizontalPodAutoscalerCondition описує стан HorizontalPodAutoscaler у певний момент часу.
conditions.status (string), обовʼязково
status — це статус стану (True, False, Unknown)
conditions.type (string), обовʼязково
type описує поточний стан
conditions.lastTransitionTime (Time)
lastTransitionTime — це останній час, коли стан перейшла з одного стану в інший
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
message - це зрозуміле людині пояснення, що містить деталі про зміну стану
conditions.reason (string)
reason — це причина останньї зміни стану.
currentMetrics ([]MetricStatus)
Atomic: буде замінено під час обʼєднання
currentMetrics — це останній прочитаний статус метрик, які використовує цей автомасштабувальник.
MetricStatus описує останній прочитаний статус окремої метрики.
currentMetrics.type (string), обовʼязково
type — це тип джерела метрики. Це буде один з "ContainerResource", "External", "Object", "Pods" або "Resource", кожен з яких відповідає відповідному полю в обʼєкті. Примітка: тип "ContainerResource" доступний лише за увімкненого прапора функції HPAContainerMetrics.
container resource стосується метрики ресурсу (такої як зазначено в запитах та обмеженнях), відомої Kubernetes, що описує окремий контейнер у кожному Podʼі в поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".
ContainerResourceMetricStatus вказує поточне значення метрики ресурсу, відомої Kubernetes, як зазначено в запитах та обмеженнях, що описує окремий контейнер у кожному Podʼі в поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".
currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.
external стосується глобальної метрики, яка не повʼязана з жодним обʼєктом Kubernetes. Вона дозволяє автомасштабування на основі інформації, що надходить від компонентів, що працюють за межами кластера (наприклад, довжина черги у хмарному сервісі обміну повідомленнями або QPS від балансувальника навантаження, що працює за межами кластера).
ExternalMetricStatus вказує поточне значення глобальної метрики, не повʼязаної з жодним обʼєктом Kubernetes.
currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.
selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.
currentMetrics.object (ObjectMetricStatus)
object стосується метрики, що описує окремий обʼєкт Kubernetes (наприклад, кількість запитів на секунду для обʼєкта Ingress).
ObjectMetricStatus вказує поточне значення метрики, що описує обʼєкт Kubernetes (наприклад, кількість запитів на секунду для обʼєкта Ingress).
currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.
selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.
currentMetrics.pods (PodsMetricStatus)
pods — стосується метрики, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, кількість оброблених транзакцій на секунду). Значення буде усереднено перед порівнянням з цільовим значенням.
PodsMetricStatus вказує поточне значення метрики, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, кількість оброблених транзакцій на секунду).
currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.
selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.
currentMetrics.resource (ResourceMetricStatus)
resource — стосується метрики ресурсу (такої як зазначено в запитах та обмеженнях), відомої Kubernetes, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".
ResourceMetricStatus вказує поточне значення метрики ресурсу, відомої Kubernetes, як зазначено в запитах та обмеженнях, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".
currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.
currentReplicas — це поточна кількість реплік Podʼів, якими керує цей автомасштабувальник, як це було останній раз спостережено автомасштабувальником.
lastScaleTime (Time)
lastScaleTime — це останній час, коли HorizontalPodAutoscaler масштабував кількість Podʼів, використовується автомасштабувальником для контролю частоти зміни кількості Podʼів.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
observedGeneration (int64)
observedGeneration — це останнє покоління, яке спостерігав цей автомасштабувальник.
HorizontalPodAutoscalerList
HorizontalPodAutoscalerList — це список обʼєктів горизонтального автомасштабувальника Podʼів.
Представляє ціле значення цього класу пріоритету. Це фактичний пріоритет, який отримують Podʼи, коли вони мають імʼя цього класу у їхній специфікації.
description (string)
Опис є довільним рядком, який зазвичай надає вказівки про те, коли слід використовувати цей клас пріоритету.
globalDefault (boolean)
Визначає, чи слід вважати цей PriorityClass за стандартний пріоритет для Podʼів, які не мають жодного класу пріоритету. Може бути встановлено лише один PriorityClass як globalDefault. Однак, якщо існує більше одного PriorityClass з полем globalDefault, встановленим на true, то за стандартний пріоритет буде використовувати найменше значення серед таких глобальних пріоритетних класів.
preemptionPolicy (string)
Політика для випередження Podʼів з нижчим пріоритетом. Один із варіантів: Never, PreemptLowerPriority. Стандартно використовується PreemptLowerPriority, якщо не встановлено жодного значення.
Обʼєкти PodSchedulingContext містять інформацію, необхідну для планування Pod з ResourceClaims, що використовують режим виділення "WaitForFirstConsumer".
apiVersion: resource.k8s.io/v1alpha2
import "k8s.io/api/resource/v1alpha2"
PodSchedulingContext
Обʼєкти PodSchedulingContext містять інформацію, необхідну для планування Pod з ResourceClaims, що використовують режим виділення "WaitForFirstConsumer".
Це тип альфа-версії та потребує включення функціональних можливостей DynamicResourceAllocation.
Статус описує, де можуть бути виділені ресурси для Pod.
PodSchedulingContextSpec
PodSchedulingContextSpec описує, де потрібні ресурси для Pod.
potentialNodes ([]string)
Set: унікальні значення зберігаються під час обʼєднання
PotentialNodes перелічує вузли, де можливий запуск Pod.
Розмір цього поля обмежений 128. Цього достатньо для багатьох кластерів. В більших кластерах може знадобитися більше спроб для знаходження вузла, що відповідає всім очікуваним ресурсам. В майбутньому це обмеження може бути збільшено, але не зменшено.
selectedNode (string)
SelectedNode — це вузол, для якого буде виконана спроба виділити ресурси, на які посилається Pod і які використовують виділення "WaitForFirstConsumer".
PodSchedulingContextStatus
PodSchedulingContextStatus описує, де можуть бути виділені ресурси для Pod.
resourceClaims ([]ResourceClaimSchedulingStatus)
Map: унікальні значення за ключем будуть збережені під час обʼєднання
ResourceClaims описує доступність ресурсів для кожного входження pod.spec.resourceClaims, де відповідний ResourceClaim використовує режим виділення "WaitForFirstConsumer".
ResourceClaimSchedulingStatus містить інформацію про конкретний ResourceClaim з режимом виділення "WaitForFirstConsumer".
resourceClaims.name (string)
Імʼя відповідає полю pod.spec.resourceClaims[*].Name.
resourceClaims.unsuitableNodes ([]string)
Set: унікальні значення зберігаються під час обʼєднання
UnsuitableNodes перелічує вузли, для яких ResourceClaim не може бути виділено.
Розмір цього поля обмежений 128, так само як і для PodSchedulingSpec.PotentialNodes. Це обмеження може бути збільшено в майбутньому, але не зменшено.
PodSchedulingContextList
PodSchedulingContextList є колекцією обʼєктів планування Pod.
Статус описує, чи доступний ресурс та з якими атрибутами.
ResourceClaimSpec
ResourceClaimSpec визначає, як має бути виділений ресурс.
resourceClassName (string), обовʼязково
ResourceClassName посилається на драйвер та додаткові параметри через імʼя ResourceClass, яке було створено в рамках розгортання драйвера.
allocationMode (string)
Виділення може розпочатися негайно або коли Pod захоче використовувати ресурс. Стандартно використовується "WaitForFirstConsumer".
parametersRef (ResourceClaimParametersReference)
ParametersRef посилається на окремий обʼєкт із довільними параметрами, які будуть використані драйвером під час виділення ресурсу для запиту.
Обʼєкт повинен знаходитися в тому ж самому просторі імен, що і ResourceClaim.
ResourceClaimParametersReference містить достатньо інформації, щоб дозволити знайти параметри для ResourceClaim. Обʼєкт повинен знаходитися в тому ж самому просторі імен, що і ResourceClaim.
parametersRef.kind (string), обовʼязково
Kind — це тип ресурсу, на який робиться посилання. Це те саме значення, що і в метаданих обʼєкта параметрів, наприклад "ConfigMap".
parametersRef.name (string), обовʼязково
Name — це імʼя ресурсу, на який робиться посилання.
parametersRef.apiGroup (string)
APIGroup — це група для ресурсу, на який робиться посилання. Вона порожня для основного API. Це відповідає групі в APIVersion, яка використовується під час створення ресурсів.
ResourceClaimStatus
ResourceClaimStatus відстежує, чи було виділено ресурс і які атрибути отримано в результаті.
allocation (AllocationResult)
Allocation встановлюється драйвером ресурсу, коли ресурс або набір ресурсів було успішно виділено. Якщо це поле не вказане, ресурси ще не були виділені.
AllocationResult містить атрибути виділеного ресурсу.
allocation.availableOnNodes (NodeSelector)
Це поле встановлюється драйвером ресурсу після виділення ресурсу, щоб інформувати планувальник, де можна розміщувати Podʼи, що використовують ResourceClaim.
Встановлення цього поля є необовʼязковим. Якщо воно має значення null, ресурс доступний всюди.
Node selector представляє обʼєднання результатів одного або кількох запитів за мітками по набору вузлів; тобто представляє OR вибірок, представлених термінами вибірки вузлів.
Обовʼязково. Список термінів вибірки вузлів. Терміни поєднуються логічним OR.
Нульовий або порожній термін вибірки вузлів не відповідає жодним обʼєктам. Їхні вимоги поєднуються логічним AND. Тип TopologySelectorTerm реалізує підмножину типу NodeSelectorTerm.
ResourceHandles містять стан, повʼязаний з виділенням, який слід підтримувати протягом усього терміну запиту. Кожен ResourceHandle містить дані, які слід передати певному втулку kubelet після його розміщення на вузлі. Ці дані повертаються драйвером після успішного виділення та є непрозорими для Kubernetes. Документація драйвера може пояснити користувачам, як інтерпретувати ці дані, якщо це необхідно.
Встановлення цього поля є необовʼязковим. Воно має максимальний розмір у 32 записи. Якщо null (або порожній), припускається, що це виділення буде оброблено одним втулком kubelet без доданих даних ResourceHandle. Імʼя втулка kubelet, що викликається, збігається з DriverName, встановленим у ResourceClaimStatus, у якому вбудовано цей AllocationResult.
ResourceHandle містить непрозорі дані ресурсу для обробки певним втулком kubelet.
allocation.resourceHandles.data (string)
Data містить непрозорі дані, повʼязані з цим ResourceHandle. Їх встановлює компонент контролера драйвера ресурсу, імʼя якого збігається з DriverName, встановленим у ResourceClaimStatus, у якому вбудовано цей ResourceHandle. Встановлюється під час виділення та призначено для обробки втулком kubelet, імʼя якого збігається з DriverName, встановленим у цьому ResourceHandle.
Максимальний розмір цього поля становить 16 КіБ. У майбутньому це може бути збільшено, але не зменшено.
allocation.resourceHandles.driverName (string)
DriverName вказує імʼя драйвера ресурсу, втулок kubelet якого слід викликати для обробки даних цього ResourceHandle після його розміщення на вузлі. Це може відрізнятися від DriverName, встановленого у ResourceClaimStatus, у якому вбудовано цей ResourceHandle.
allocation.shareable (boolean)
Shareable визначає, чи підтримує ресурс одночасне використання більше ніж одним споживачем.
deallocationRequested (boolean)
DeallocationRequested вказує, що ResourceClaim має бути відкликана.
Драйвер повинен потім відкликати цей запит і скинути поле разом з очищенням поля Allocation.
Поки DeallocationRequested встановлено, нові споживачі не можуть бути додані до ReservedFor.
driverName (string)
DriverName — це копія імені драйвера з ResourceClass на момент початку виділення.
reservedFor ([]ResourceClaimConsumerReference)
Map: унікальні значення за ключем uid зберігаються під час злиття
ReservedFor вказує, яким обʼєктам наразі дозволено використовувати запит. Pod, який посилається на ResourceClaim, що не зарезервований для цього Pod, не буде запущено.
Може бути максимум 32 таких резервування. У майбутньому це може бути збільшено, але не зменшено.
ResourceClaimConsumerReference містить достатньо інформації, щоб знайти споживача ResourceClaim. Споживач має бути ресурсом у тому ж просторі імен, що і ResourceClaim.
reservedFor.name (string), обовʼязково
Name — це імʼя ресурсу, на який робиться посилання.
reservedFor.resource (string), обовʼязково
Resource — це тип ресурсу, на який робиться посилання, наприклад "pods".
reservedFor.uid (string), обовʼязково
UID однозначно ідентифікує один екземпляр ресурсу.
reservedFor.apiGroup (string)
APIGroup — це група для ресурсу, на який робиться посилання. Вона порожня для основного API. Це відповідає групі в APIVersion, яка використовується під час створення ресурсів.
Специфікація для ResourceClaim. Весь вміст копіюється без змін в ResourceClaim, який створюється з цього шаблону. Ті ж самі поля, що й в ResourceClaim, є дійсними тут.
ObjectMeta може містити мітки та анотації, які будуть скопійовані до PVC при створенні його. Інші поля не дозволені і будуть відхилені під час перевірки на валідність.
ResourceClaimTemplateList
ResourceClaimTemplateList є колекцією шаблонів заявок.
DriverName визначає імʼя динамічного драйвера ресурсів, який використовується для виділення ResourceClaim, що використовує цей клас.
Ресурсні драйвери мають унікальне імʼя у прямому порядку домену (acme.example.com).
parametersRef (ResourceClassParametersReference)
ParametersRef посилається на довільний окремий обʼєкт, який може містити параметри, які будуть використані драйвером при виділенні ресурсу, що використовує цей клас. Динамічний драйвер ресурсів може відрізняти параметри, збережені тут, від тих, що зберігаються в ResourceClaimSpec.
ResourceClassParametersReference містить достатньо інформації для пошуку параметрів ResourceClass.
parametersRef.kind (string), обовʼязково
Kind — це тип ресурсу, на який робиться посилання. Це те саме значення, що й у метаданих обʼєкта параметрів.
parametersRef.name (string), обовʼязково
Name — це назва ресурсу, на який робиться посилання.
parametersRef.apiGroup (string)
APIGroup — це група для ресурсу, на який робиться посилання. Вона порожня для основного API. Це відповідає групі в APIVersion, яке використовується при створенні ресурсів.
parametersRef.namespace (string)
Namespace — це простір імен, який містить ресурс, на який робиться посилання. Для ресурсів з областю видимості на рівні кластера повинно бути порожнім, а для ресурсів з іменованою областю видимості — непорожнім.
suitableNodes (NodeSelector)
Тільки вузли, що відповідають селектору, будуть враховані планувальником при спробі знайти вузол, який підходить для Pod, коли цей Pod використовує ResourceClaim, який ще не був виділений.
Налаштування цього поля є необовʼязковим. Якщо воно null, всі вузли є кандидатами.
Селектор вузла представляє обʼєднання результатів одного або декількох запитів міток на заданий набір вузлів; іншими словами, він представляє OR селекторів, які представлені термінами селектора вузла.
Service — це іменована абстракція служб програмного забезпечення (наприклад, mysql), що складається з локального порту (наприклад, 3306), який прослуховує проксі, і селектора, який визначає, які Podʼи будуть відповідати на запити, надіслані через проксі.
apiVersion: v1
import "k8s.io/api/core/v1"
Service
Service — це іменована абстракція служб програмного забезпечення (наприклад, mysql), що складається з локального порту (наприклад, 3306), який прослуховує проксі, і селектора, який визначає, які Podʼи будуть відповідати на запити, надіслані через проксі.
ServiceSpec описує атрибути, які користувач створює для служби.
selector (map[string]string)
Направляє трафік до Podʼів з ключами та значеннями міток, які відповідають цьому селектору. Якщо селектор порожній або не вказаний, передбачається, що Service має зовнішній процес, який керує його точками доступу, і Kubernetes не буде їх змінювати. Застосовується лише до типів ClusterIP, NodePort і LoadBalancer. Ігнорується, якщо тип — ExternalName. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/
ports ([]ServicePort)
Patch strategy: злиття по ключу port
Map: унікальні значення за ключами port, protocol зберігатимуться під час злиття
Номер або імʼя порту для доступу до Podʼів, на які спрямовано Service. Номер повинен бути в діапазоні від 1 до 65535. Імʼя повинно бути IANA_SVC_NAME. Якщо це рядок, він буде шукатися як іменований порт у портах контейнера цільового Podʼа. Якщо не вказано, використовується значення поля ʼportʼ (identity map). Це поле ігнорується для Service із clusterIP=None і має бути пропущене або встановлене рівним полю ʼportʼ. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
ports.protocol (string)
IP-протокол для цього порту. Підтримуються "TCP", "UDP" і "SCTP". Стандартне значення — TCP.
ports.name (string)
Імʼя цього порту в Service. Воно повинно бути DNS_LABEL. Усі порти в межах ServiceSpec повинні мати унікальні імена. При аналізі точок доступу для Service, вони повинні відповідати полю ʼnameʼ в EndpointPort. Необовʼязкове, якщо визначено лише один ServicePort для цього Service.
ports.nodePort (int32)
Порт на кожному вузлі, на якому цей Service буде доступний, коли тип — NodePort або LoadBalancer. Зазвичай призначається системою. Якщо значення вказано, знаходиться в діапазоні та не використовується, воно буде використано, інакше операція завершиться невдачею. Якщо не вказано, порт буде виділено, якщо Service його потребує. Якщо це поле вказано під час створення Service, яка не потребує його, створення не вдасться. Це поле буде видалено під час оновлення Service, щоб більше не потребувати його (наприклад, змінюючи тип з NodePort на ClusterIP). Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
ports.appProtocol (string)
Протокол застосунків для цього порту. Він використовується як підказка для реалізацій, щоб запропонувати багатший функціонал для протоколів, які вони розуміють. Це поле відповідає стандартному синтаксису міток Kubernetes. Допустимі значення - або:
Інші протоколи повинні використовувати імена з префіксами, визначеними реалізацією, такі як mycompany.com/my-custom-protocol.
type (string)
Тип визначає, як Service буде відкрито. Стандартне значення — ClusterIP. Допустимі варіанти: ExternalName, ClusterIP, NodePort та LoadBalancer. "ClusterIP" виділяє точкам доступу внутрішню IP-адресу кластера для балансування навантаження. Точки доступу визначаються селектором або, якщо його не вказано, ручним створенням обʼєкта Endpoints або обʼєктів EndpointSlice. Якщо clusterIP має значення "None", жодна віртуальна IP-адреса не виділяється, і точки доступу публікуються як набір точок доступу, а не віртуальна IP-адреса. "NodePort" базується на ClusterIP і виділяє порт на кожному вузлі, який маршрутизується до тих самих точок доступу, що і clusterIP. "LoadBalancer" базується на NodePort і створює зовнішній балансувальник навантаження (якщо підтримується в поточній хмарі), який маршрутизується до тих самих точок доступу, що і clusterIP. "ExternalName" привʼязує цей Service до вказаного externalName. Декілька інших полів не застосовуються до Service ExternalName. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
ipFamilies ([]string)
Atomic: буде замінено під час злиття
IPFamilies — це список IP-сімейств (наприклад, IPv4, IPv6), призначених цьому Serviceʼу. Це поле зазвичай призначається автоматично на основі конфігурації кластера та поля ipFamilyPolicy. Якщо це поле вказано вручну, запитане сімейство доступне в кластері, і ipFamilyPolicy дозволяє це, воно буде використане; інакше створення Service не вдасться. Це поле змінюється відповідно до умов: дозволяє додавати або видаляти вторинне IP-сімейство, але не дозволяє змінювати первинне IP-сімейство Service. Допустимі значення: "IPv4" і "IPv6". Це поле застосовується лише до Service типів ClusterIP, NodePort та LoadBalancer, і не застосовується до "headless" Service. Це поле буде очищено під час оновлення Service до типу ExternalName.
Це поле може містити максимум два записи (двостекові сімейство, у будь-якому порядку). Ці сімейства повинні відповідати значенням поля clusterIPs, якщо вказано. Поля clusterIPs та ipFamilies керуються полем ipFamilyPolicy.
ipFamilyPolicy (string)
IPFamilyPolicy представляє вимоги до подвійного стека для цього Service. Якщо значення не надано, це поле буде встановлено на SingleStack. Service можуть бути "SingleStack" (одне IP-сімейство), "PreferDualStack" (два IP-сімейства в конфігураціях з подвійним стеком або одне IP-сімейство в конфігураціях з одним стеком) або "RequireDualStack" (два IP-сімейства в конфігураціях з подвійним стеком, інакше буде збій). Поля ipFamilies та clusterIPs залежать від значення цього поля. Це поле буде очищено під час оновлення Service до типу ExternalName.
clusterIP (string)
clusterIP — це IP-адреса Service, яка зазвичай призначається випадковим чином. Якщо адреса вказана вручну, знаходиться в діапазоні (згідно з конфігурацією системи) і не використовується, вона буде виділена Service; інакше створення Service не вдасться. Це поле не може бути змінено через оновлення, якщо тип поля також не змінюється на ExternalName (що вимагає, щоб це поле було порожнім) або тип поля змінюється з ExternalName (у цьому випадку це поле може бути зазначено опціонально, як описано вище). Допустимі значення: "None", порожній рядок (""), або дійсна IP-адреса. Встановлення цього значення в "None" створює "headless service" (без віртуальної IP-адреси), що корисно, коли потрібні прямі зʼєднання з точками доступу, і проксіювання не потрібне. Застосовується лише до типів ClusterIP, NodePort і LoadBalancer. Якщо це поле вказано під час створення Service типу ExternalName, створення не вдасться. Це поле буде очищено під час оновлення Service до типу ExternalName. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
clusterIPs ([]string)
Atomic: буде замінено під час злиття
ClusterIPs — це список IP-адрес, призначених Service, і зазвичай вони призначаються випадковим чином. Якщо адреса вказана вручну, знаходиться в діапазоні (згідно з конфігурацією системи) і не використовується, вона буде виділена Service; інакше створення Service не вдасться. Це поле не може бути змінено через оновлення, якщо тип поля також не змінюється на ExternalName (що вимагає, щоб це поле було порожнім) або тип поля змінюється з ExternalName (у цьому випадку це поле може бути зазначено опціонально, як описано вище). Допустимі значення: "None", порожній рядок (""), або дійсна IP-адреса. Встановлення цього значення на "None" створює "headless service" (без віртуальної IP-адреси), що корисно, коли потрібні прямі зʼєднання з точками доступу, і проксіювання не потрібно. Застосовується лише до типів ClusterIP, NodePort і LoadBalancer. Якщо це поле вказано під час створення Service типу ExternalName, створення не вдасться. Це поле буде очищено під час оновлення Service до типу ExternalName. Якщо це поле не вказано, воно буде ініціалізовано з поля clusterIP. Якщо це поле вказано, клієнти повинні переконатися, що clusterIPs[0] і clusterIP мають однакове значення.
externalIPs — це список IP-адрес, для яких вузли в кластері також будуть приймати трафік для цього Service. Ці IP-адреси не керуються Kubernetes. Користувач несе відповідальність за забезпечення того, щоб трафік надходив на вузол з цією IP-адресою. Загальний приклад — зовнішні балансувальники навантаження, які не є частиною системи Kubernetes.
Застосовується лише до типу Service: LoadBalancer. Ця функція залежить від того, чи підтримує базовий хмарний провайдер вказівку loadBalancerIP під час створення балансувальника навантаження. Це поле буде ігноруватися, якщо постачальник хмари не підтримує цю функцію. Застаріле: це поле було недостатньо описане, і його значення варіюється залежно від реалізацій. Використання його не є переносимим і може не підтримувати подвійний стек. Користувачам рекомендується використовувати анотації специфічні для реалізації, коли це можливо.
loadBalancerClass — це клас реалізації балансувальника навантаження, до якого належить Service. Якщо вказано, значення цього поля повинно бути ідентифікатором у стилі мітки з опціональним префіксом, наприклад, "internal-vip" або "example.com/internal-vip". Імена без префіксів зарезервовані для кінцевих користувачів. Це поле можна встановити лише при створенні або оновленні Service до типу ʼLoadBalancerʼ. Якщо не встановлено, використовується стандартна реалізація балансувальника навантаження, сьогодні це зазвичай робиться через інтеграцію з постачальником хмари, але має застосовуватися до будь-якої стандартної реалізації. Якщо встановлено, вважається, що реалізація балансувальника навантаження стежить за Service з відповідним класом. Будь-яка стандартна реалізація балансувальника навантаження (наприклад, постачальники хмари) повинна ігнорувати Service, які встановлюють це поле. Це поле можна встановити лише при створенні або оновленні Service до типу ʼLoadBalancerʼ. Після встановлення його не можна змінити. Це поле буде очищено при оновленні Service до типу, відмінного від ʼLoadBalancerʼ.
externalName (string)
externalName — це зовнішнє посилання, яке механізми виявлення будуть повертати як псевдонім для цього Service (наприклад, запис DNS CNAME). Проксіювання не буде. Повинно бути вказано в нижньому регістрі відповідно до RFC-1123 hostname (https://tools.ietf.org/html/rfc1123) і вимагає type бути "ExternalName".
externalTrafficPolicy (string)
externalTrafficPolicy описує, як вузли розподіляють трафік, який вони отримують на одній з "зовнішньо спрямованих" адрес Service (NodePorts, ExternalIPs і LoadBalancer IPs). Якщо встановлено значення "Local", проксі налаштує Service так, що передбачається, що зовнішні балансувальники навантаження будуть піклуватися про балансування трафіку Service між вузлами, і тому кожен вузол буде доставляти трафік лише до локальних точок доступу вузла цього Service, не маскуючи IP-адресу джерела клієнта. (Трафік, помилково надісланий на вузол без точок доступу, буде відхилений.) Стандартне значення "Cluster" використовує стандартну поведінку маршрутизації до всіх точок доступу рівномірно (можливо, змінену топологією та іншими функціями). Зверніть увагу, що трафік, надісланий на External IP або LoadBalancer IP зсередини кластера, завжди буде мати семантику "Cluster", але клієнти, які надсилають на NodePort зсередини кластера, можуть враховувати політику трафіку під час вибору вузла.
internalTrafficPolicy (string)
InternalTrafficPolicy описує, як вузли розподіляють трафік, який вони отримують на ClusterIP. Якщо встановлено значення "Local", проксі вважатиме, що Podʼи хочуть спілкуватися лише з точками доступу Service на тому ж вузлі, що й Pod, відхиляючи трафік, якщо немає локальних точок доступу. Стандартне значення "Cluster" використовує стандартну поведінку маршрутизації до всіх точок доступу рівномірно (можливо, змінено топологією та іншими функціями).
healthCheckNodePort (int32)
healthCheckNodePort визначає порт вузла перевірки справності Service. Це застосовується лише при встановленні типу на LoadBalancer і зовнішньому трафіку політики на Local. Якщо вказане значення, знаходиться в діапазоні і не використовується, воно буде використано. Якщо не вказано, значення буде автоматично призначено. Зовнішні системи (наприклад, балансувальники навантаження) можуть використовувати цей порт, щоб визначити, чи містить певний вузол точки доступу для цього Service чи ні. Якщо це поле вказано під час створення Service, яка цього не потребує, створення не вдасться. Це поле буде очищено при оновленні Service, щоб більше не потребувати його (наприклад, зміна типу). Це поле не можна оновити після встановлення.
publishNotReadyAddresses (boolean)
publishNotReadyAddresses вказує, що будь-який агент, який має справу з точками доступу для цього Service, повинен ігнорувати будь-які індикатори готовності/не готовності. Основний випадок використання цього поля — для Headless Service для StatefulSet, щоб поширювати SRV DNS-записи для своїх Podʼів з метою їх виявлення. Контролери Kubernetes, які генерують ресурси Endpoints і EndpointSlice для Service, інтерпретують це як ознаку того, що всі точки доступу вважаються "готовими", навіть якщо самі Podʼи не готові. Агенти, які використовують тільки точки доступу, створені Kubernetes, через ресурси Endpoints або EndpointSlice, можуть безпечно передбачати цю поведінку.
sessionAffinityConfig (SessionAffinityConfig)
sessionAffinityConfig містить конфігурації сеансової спорідненості.
SessionAffinityConfig представляє конфігурації сеансової спорідненості.
sessionAffinityConfig.clientIP (ClientIPConfig)
clientIP містить конфігурації сеансової спорідненості на основі IP клієнта.
ClientIPConfig представляє конфігурації сеансової спорідненості на основі IP клієнта.
timeoutSeconds задає час залипання сесії типу ClientIP у секундах. Значення повинно бути >0 && <=86400 (для 1 дня), якщо ServiceAffinity == "ClientIP". Стандартне значення — 10800 (3 години).
allocateLoadBalancerNodePorts (boolean)
allocateLoadBalancerNodePorts визначає, чи будуть автоматично виділені NodePorts для Service з типом LoadBalancer. Стандартне значення — "true". Його можна встановити у "false", якщо балансувальник навантаження кластера не покладається на NodePorts. Якщо абонент запитує конкретні NodePorts (вказуючи значення), ці запити будуть виконані, незалежно від цього поля. Це поле можна встановити лише для Service з типом LoadBalancer і воно буде очищено, якщо тип буде змінено на будь-який інший тип.
ServiceStatus
ServiceStatus представляє поточний стан Service.
conditions ([]Condition)
Patch strategy: злиття за ключем type
Map: унікальні значення за ключем type зберігаються під час злиття
Поточний стан Service
Condition містить деталі для одного аспекту поточного стану цього API ресурсу.
conditions.lastTransitionTime (Time), обовʼязково
lastTransitionTime — це останній час, коли стан змінився з одного на інший. Це має бути тоді, коли змінився основний стан. Якщо це невідомо, то можна використати час, коли змінилося поле API.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string), обовʼязково
message — це повідомлення, зрозуміле людині, яке вказує на деталі про зміну стану. Це може бути порожній рядок.
conditions.reason (string), обовʼязково
reason містить програмний ідентифікатор, який вказує на причину останньоїзміни стану. Виробники специфічних типів станів можуть визначати очікувані значення та значення для цього поля, і чи вважаються значення гарантованим API. Значення має бути рядком у CamelCase. Це поле не може бути порожнім.
conditions.status (string), обовʼязково
статус стану, одне з True, False, Unknown.
conditions.type (string), обовʼязково
тип стану у CamelCase або у форматі foo.example.com/CamelCase.
conditions.observedGeneration (int64)
observedGeneration представляє .metadata.generation, на основі якої встановлено стан. Наприклад, якщо .metadata.generation наразі дорівнює 12, але .status.conditions[x].observedGeneration дорівнює 9, то стан не актуальний стосовно поточного стану екземпляра.
loadBalancer (LoadBalancerStatus)
LoadBalancer містить поточний статус балансувальника навантаження, якщо він присутній.
LoadBalancerStatus представляє статус балансувальника навантаження.
loadBalancer.ingress ([]LoadBalancerIngress)
Ingress — це список точок входу для балансувальника навантаження. Трафік, призначений для Service, має надходити до цих точок входу.
LoadBalancerIngress представляє стаnec точки входу балансувальника навантаження: трафік, призначений для Service, має надходити до точки входу.
loadBalancer.ingress.hostname (string)
Hostname встановлюється для точок входу балансувальника навантаження, які базуються на DNS (зазвичай балансувальники навантаження AWS)
loadBalancer.ingress.ip (string)
IP встановлюється для точок входу балансувальника навантаження, які базуються на IP (зазвичай балансувальники навантаження GCE або OpenStack)
loadBalancer.ingress.ipMode (string)
IPMode визначає, як поводиться IP балансувальника навантаження, і може бути вказаний лише тоді, коли вказане поле ip. Встановлення цього значення на "VIP" означає, що трафік доставляється до вузла з встановленим призначенням на IP та порт балансувальника навантаження. Встановлення цього значення на "Proxy" означає, що трафік доставляється до вузла або Pod з встановленим призначенням на IP вузла та порт вузла або на IP Podʼа та порт. Реалізації Service можуть використовувати цю інформацію для налаштування маршрутизації трафіку.
loadBalancer.ingress.ports ([]PortStatus)
Atomic: буде замінено під час злиття
Ports — це список портів Service. Якщо використовується, кожен порт, визначений у Service, повинен мати запис у цьому списку.
Набір всіх точок доступу є обʼєднанням (union) всіх субнаборів. Адреси розміщуються в субнабори відповідно до IP-адрес, які вони поділяють. Одна адреса з кількома портами, деякі з яких готові, а деякі ні (тому що вони належать різним контейнерам), буде відображатися в різних субнаборах для різних портів. Жодна адреса не зʼявиться одночасно в Addresses і NotReadyAddresses в одному субнаборі. Набори адрес і портів, які складають Service.
EndpointSubset – це група адрес з одним набором портів. Розширений набір точок доступу є декартовим добутком Addresses x Ports. Наприклад, задано:
IP-адреси, які пропонують відповідні порти, позначені як готові. Ці точки доступу повинні вважатися безпечними для використання балансувальниками навантаження та клієнтами.
EndpointAddress — це кортеж, що описує одну IP-адресу.
subsets.addresses.ip (string), обовʼязкове
IP цієї точки доступу. Не може бути loopback (127.0.0.0/8 або ::1), link-local (169.254.0.0/16 або fe80::/10), або link-local multicast (224.0.0.0/24 або ff02::/16).
subsets.addresses.hostname (string)
Імʼя хоста цієї точки доступу
subsets.addresses.nodeName (string)
Необовʼязково: Вузол, на якому знаходиться ця точка доступу. Це може бути використано для визначення точок доступу що є локальними для вузла.
IP-адреси, які пропонують відповідні порти, але наразі не позначені як готові, тому що вони ще не завершили запуск, нещодавно не пройшли перевірку готовності або нещодавно не пройшли перевірку на справність.
EndpointAddress — це кортеж, що описує одну IP-адресу.
IP цієї точки доступу. Не може бути loopback (127.0.0.0/8 або ::1), link-local (169.254.0.0/16 або fe80::/10), або link-local multicast (224.0.0.0/24 або ff02::/16).
subsets.notReadyAddresses.hostname (string)
Імʼя хоста цієї точки доступу
subsets.notReadyAddresses.nodeName (string)
Необовʼязково: Вузол, на якому знаходиться ця точка доступу. Це може бути використано для визначення точок доступу що є локальними для вузла.
Номери портів, доступні на відповідних IP-адресах.
EndpointPort — це кортеж, що описує один порт.
subsets.ports.port (int32), обовʼязкове
Номер порту точки доступу.
subsets.ports.protocol (string)
IP-протокол для цього порту. Повинен бути UDP, TCP або SCTP. За замовчуванням TCP.
subsets.ports.name (string)
Імʼя цього порту. Це повинно відповідати полю 'name' у відповідному ServicePort. Повинно бути DNS_LABEL. Необовʼязкове, лише якщо визначено один порт.
subsets.ports.appProtocol (string)
Протокол програми для цього порту. Використовується як підказка для реалізацій, щоб пропонувати багатший функціонал для протоколів, які вони розуміють. Це поле відповідає стандартному синтаксису міток Kubernetes. Дійсні значення:
Ingress — це набір правил, які дозволяють вхідним зʼєднанням досягати точок доступу, визначених бекендом.
apiVersion: networking.k8s.io/v1
import "k8s.io/api/networking/v1"
Ingress
Ingress — це набір правил, які дозволяють вхідним зʼєднанням досягати точок доступу, визначених бекендом. Ingress можна налаштувати так, щоб надавати Service зовнішні адреси, балансувати трафік, закінчувати SSL, пропонувати віртуальний хостинг на основі імен тощо.
defaultBackend — це бекенд, який повинен обробляти запити, що не відповідають жодному правилу. Якщо правила не вказані, необхідно вказати DefaultBackend. Якщо DefaultBackend не встановлено, обробка запитів, що не відповідають жодному з правил, буде відбуватись на розсуд контролера Ingress.
ingressClassName (string)
ingressClassName — це імʼя ресурсу IngressClass у кластері. Реалізації контролера Ingress використовують це поле для визначення, чи повинні вони обслуговувати цей ресурс Ingress, через транзитивний звʼязок (controller -> IngressClass -> Ingress resource). Хоча анотація kubernetes.io/ingress.class (проста константна назва) ніколи не була формально визначена, вона була широко підтримана контролерами Ingress для створення прямого звʼязку між контролером Ingress і ресурсами Ingress. Новостворені ресурси Ingress повинні надавати перевагу використанню цього поля. Однак, попри те, що анотація офіційно застаріла, з міркувань зворотної сумісності контролери Ingress все ще повинні враховувати цю анотацію, якщо вона присутня.
rules ([]IngressRule)
Atomic: буде замінено під час злиття
rules — це список правил для хостів, що використовуються для налаштування Ingress. Якщо не вказано або жодне правило не має збігів, весь трафік надсилається на стандартний бекенд.
IngressRule представляє правила, що зіставляють шляхи для зазначеного хосту з відповідними бекенд-сервісами. Вхідні запити спочатку оцінюються на відповідність хосту, а потім перенаправляються до бекенда, асоційованого з відповідним IngressRuleValue.
rules.host (string)
host — це повне доменне імʼя мережевого хосту, як визначено в RFC 3986. Зверніть увагу на такі відхилення від частини "host" в URI, як визначено в RFC 3986:
IP-адреси не допускаються. Зараз IngressRuleValue може застосовуватися лише до IP-адреси в Spec батьківського Ingress.
Двокрапка (:) як роздільник не використовується, оскільки порти не допускаються. Зараз порт Ingress неявно визначений як :80 для http і :443 для https.
Обидва ці моменти можуть змінитися в майбутньому. Вхідні запити зіставляються з хостом перед IngressRuleValue. Якщо хост не вказано, Ingress маршрутизує весь трафік на основі зазначеного IngressRuleValue.
host може бути "точним" (precise), доменним імʼям без завершальної крапки мережевого хосту (наприклад, "foo.bar.com"), або "wildcard" (маска), що є доменним імʼям з префіксом у вигляді одного символу маски (наприклад, "*.foo.com"). Символ маски '*' повинен зʼявлятися сам по собі як перша мітка DNS і відповідає лише одній мітці. Ви не можете мати мітку маски саму по собі (наприклад, Host == "*"). Запити будуть зіставлятися з полем Host наступним чином:
Якщо host є точним, запит відповідає цьому правилу, якщо заголовок http host дорівнює Host.
Якщо host є маскою, то запит відповідає цьому правилу, якщо заголовок http host дорівнює суфіксу (видаляючи першу мітку) правила маски.
rules.http (HTTPIngressRuleValue)
HTTPIngressRuleValue — це список http-селекторів, що вказують на бекенди. У прикладі: http://<host>/<path>?<searchpart> -> backend, де частини url відповідають RFC 3986, цей ресурс буде використовуватися для зіставлення з усім після останнього '/' і перед першим '?' або '#'.
rules.http.paths ([]HTTPIngressPath), обовʼязкове
Atomic: буде замінено під час злиття
paths — це набір шляхів, що зіставляють запити з бекендами.
HTTPIngressPath асоціює шлях з бекендом. Вхідні URL-адреси, що відповідають шляху, перенаправляються до бекенду.
backend визначає повʼязану точку доступу сервісу, до якого буде перенаправлено трафік.
rules.http.paths.pathType (string), обовʼязкове
pathType визначає інтерпретацію зіставлення шляху. PathType може мати одне з таких значень:
Exact: Точно відповідає URL-шляху.
Prefix: Збіг базується на префіксі шляху URL, розділеному символом '/'. Збіг перевіряється поелементно за елементами шляху. Елемент шляху — це список міток у шляху, розділених роздільником '/'. Запит вважається відповідністю для шляху p, якщо кожен елемент p є попереднім елементом відповідного елемента в кінцевому шляху запиту. Якщо це не так, то це не збіг (наприклад, /foo/bar має збіг з /foo/bar/baz, але не має з /foo/barbaz).
ImplementationSpecific: Інтерпретація зіставлення шляху визначається IngressClass. Реалізації можуть трактувати це як окремий PathType або так само як і типи шляхів Prefix або Exact.
Реалізації повинні підтримувати всі типи шляхів.
rules.http.paths.path (string)
path зіставляється зі шляхом вхідного запиту. Зараз він може містити символи, не дозволені в традиційній частині "path" URL, як визначено в RFC 3986. Шляхи повинні починатися з '/' і повинні бути присутніми при використанні PathType зі значенням "Exact" або "Prefix".
tls ([]IngressTLS)
Atomic: буде замінено під час злиття
tls представляє конфігурацію TLS. Зараз Ingress підтримує лише один TLS-порт, 443. Якщо декілька елементів цього списку вказують різні хости, вони будуть мультиплексовані на одному і тому ж порту відповідно до імені хосту, зазначеного через розширення SNI TLS, якщо контролер Ingress, що виконує Ingress, підтримує SNI.
IngressTLS описує транспортний рівень безпеки, повʼязаний з ingress.
tls.hosts ([]string)
Atomic: буде замінено під час злиття
hosts — це список хостів, включених у сертифікат TLS. Значення в цьому списку повинні відповідати іменам, використаним у tlsSecret. Типово відповідає стандартним налаштуванням хосту для контролера балансування навантаження, що виконує цей Ingress, якщо залишено незазначеним.
tls.secretName (string)
secretName — це імʼя Secret, який використовується для завершення TLS-трафіку на порту 443. Поле залишено необовʼязковим, щоб дозволити маршрутизацію TLS на основі лише імені хосту SNI. Якщо хост SNI у слухачі конфліктує з полем "Host" у заголовку, використаному IngressRule, хост SNI використовується для завершення, а значення поля "Host" використовується для маршрутизації.
IngressBackend
IngressBackend описує всі точки доступу для вказаного Service і порту.
resource — є ObjectRef на інший ресурс Kubernetes у просторі імен обʼєкта Ingress. Якщо вказано resource, не можна вказувати service.Name та service.Port. Це взаємозаперечне налаштування з "Service".
service (IngressServiceBackend)
service — посилається на Service як на бекенд. Це взаємозаперечне налаштування з "Resource".
IngressServiceBackend посилається на Kubernetes Service як на Backend.
service.name (string), обовʼязкове
name — це посилання на сервіс. Сервіс повинен існувати в тому ж просторі імен, що й обʼєкт Ingress.
service.port (ServiceBackendPort)
port вказаного сервіс. Для IngressServiceBackend потрібно вказати імʼя порту або номер порту.
ServiceBackendPort — це порт сервісу, на який посилаються.
service.port.name (string)
name — це імʼя порту на сервісі. Це взаємозаперечне налаштування з "Number".
service.port.number (int32)
number — це числовий номер порту (наприклад, 80) на сервісі. Це взаємозаперечне налаштування з "Name".
IngressStatus
IngressStatus описує поточний стан Ingress.
loadBalancer (IngressLoadBalancerStatus)
loadBalancer містить поточний статус балансувальника навантаження.
IngressLoadBalancerStatus представляє статус балансувальника навантаження.
IngressClass представляє клас Ingress, на який посилається Ingress Spec.
apiVersion: networking.k8s.io/v1
import "k8s.io/api/networking/v1"
IngressClass
IngressClass представляє клас Ingress, на який посилається Ingress Spec. Анотацію ingressclass.kubernetes.io/is-default-class можна використовувати, щоб вказати, що IngressClass слід вважати стандартним класом. Коли для одного ресурсу IngressClass ця анотація має значення true, новим ресурсам Ingress без вказаного класу буде присвоєно цей клас.
IngressClassSpec надає інформацію про клас Ingress.
controller (string)
controller вказує на імʼя контролера, який має обробляти цей клас. Це дозволяє використовувати різні "різновиди", керовані тим самим контролером. Наприклад, для одного імплементованого контролера можуть існувати різні параметри. Це повинно бути вказане як шлях з префіксом домену, не довше ніж 250 символів, наприклад, "acme.io/ingress-controller". Це поле є незмінним.
parameters (IngressClassParametersReference)
parameters це посилання на спеціалізований ресурс, що містить додаткову конфігурацію для контролера. Це необовʼязково, якщо контролер не вимагає додаткових параметрів.
IngressClassParametersReference ідентифікує обʼєкт API. Це може бути використано для вказівки на обʼєкт, що належить кластеру або області простору імен.
parameters.kind (string), обовʼязково
kind це тип ресурсу, на який вказується посилання.
parameters.name (string), обовʼязково
name це імʼя ресурсу, на який вказується посилання.
parameters.apiGroup (string)
apiGroup це група для ресурсу, на який вказується посилання. Якщо apiGroup не вказано, вказаний Kind повинен бути в основній групі API. Для будь-яких інших типів сторонніх ресурсів apiGroup є обовʼязковим.
parameters.namespace (string)
namespace це простір імен для ресурсу, на який вказується посилання. Це поле обовʼязкове, коли scope встановлено на "Namespace", і його не слід встановлювати, коли scope встановлено у "Cluster".
parameters.scope (string)
scope вказує на те, чи відноситься ресурс до кластера або простору імен. Цей параметр може мати значення "Cluster" (типово) або "Namespace".
IngressClassSpec
IngressClassSpec надає інформацію про клас Ingress.
controller (string)
controller вказує на імʼя контролера, який повинен обробляти цей клас. Це дозволяє використовувати різні "різновиди", які контролюються тим самим контролером. Наприклад, у вас можуть бути різні параметри для одного й того ж імплементаційного контролера. Це повинно бути вказано як шлях з префіксом домену довжиною не більше 250 символів, наприклад, "acme.io/ingress-controller". Це поле є незмінним.
parameters (IngressClassParametersReference)
parameters це посилання на власний ресурс, що містить додаткову конфігурацію для контролера. Це необовʼязково, якщо контролер не потребує додаткових параметрів.
IngressClassParametersReference ідентифікує обʼєкт API. Це може бути використано для {#list-list-or-watch-objects-of-kind-ingressclass}вказівки на ресурс, обмежений кластером або простором імен.
{#http-request-1}
parameters.kind (string), обовʼязково
kind це тип ресурсу, на який вказується посилання.
{#parameters-1}
parameters.name (string), обовʼязково
name це імʼя ресурсу, на який вказується посилання.
parameters.apiGroup (string)
apiGroup це група для ресурсу, на який вказується посилання. Якщо apiGroup не вказано, вказаний Kind повинен належати до основної групи API. Для будь-яких інших типів сторонніх ресурсів apiGroup є обовʼязковим.
parameters.namespace (string)
namespace це простір імен для ресурсу, на який вказується посилання. Це поле є обовʼязковим, коли scope встановлено на "Namespace", і його не слід встановлювати, коли scope встановлено на "Cluster".
parameters.scope (string)
scope вказує, чи це посилання на ресурс, обмежений кластером або простором імен. Це може бути встановлено на "Cluster" (стандартно) або "Namespace".
BinaryData містить бінарні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. BinaryData може містити байтові послідовності, які не належать до діапазону UTF-8. Ключі, що зберігаються у BinaryData, не повинні збігатися з ключами у полі Data, це перевіряється під час валідації. Використання цього поля вимагатиме apiserver та kubelet версії 1.10+.
data (map[string]string)
Data містить конфігураційні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. Значення з байтовими послідовностями, що не належать до діапазону UTF-8, повинні використовувати поле BinaryData. Ключі, що зберігаються у Data, не повинні збігатися з ключами у полі BinaryData, це перевіряється під час валідації.
immutable (boolean)
Immutable, якщо встановлено в true, гарантує, що дані, збережені у ConfigMap, не можуть бути оновлені (можна змінювати лише метадані обʼєкта). Якщо не встановлено в true, поле можна змінити у будь-який час. Стандартне значення — nil.
ConfigMapList
ConfigMapList — це ресурс, що містить список обʼєктів ConfigMap.
Data містить секретні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. Сериалізована форма секретних даних є рядком, закодованим у base64, що представляє довільне (можливо, не рядкове) значення даних. Описано в https://tools.ietf.org/html/rfc4648#section-4.
immutable (boolean)
Immutable, якщо встановлено в true, гарантує, що дані, збережені в Secret, не можуть бути оновлені (можна змінювати лише метадані обʼєкта). Якщо не встановлено в true, поле можна змінити у будь-який час. Стандартне значення — nil.
stringData (map[string]string)
stringData дозволяє вказувати небінарні секретні дані у вигляді рядків. Це поле надається як поле вводу лише для запису для зручності. Усі ключі та значення обʼєднуються в поле data при записі, перезаписуючи будь-які наявні значення. Поле stringData ніколи не виводиться при читанні з API.
PersistentVolumeClaimVolumeSource посилається на PVC користувача в тому ж просторі імен. Цей том знаходить привʼязаний PV та монтує цей том для Podʼа. PersistentVolumeClaimVolumeSource, фактично, є обгорткою навколо іншого типу тому, який належить комусь іншому (системі).
readOnly — Встановлює значення ReadOnly у VolumeMounts. Стандартне значення — false.
Проєкції
configMap (ConfigMapVolumeSource)
configMap — представляє configMap, який повинен заповнити цей том.
*Адаптує ConfigMap до тому.
Вміст поля Data цільового ConfigMap буде представлений у томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів, якщо елемент items заповнений конкретними зіставленнями ключів зі шляхами. Томи ConfigMap підтримують керування власністю та перепризначення міток SELinux.
optional — вказує, чи ConfigMap або його ключі мають бути визначені.
configMap.defaultMode (int32)
defaultMode є необовʼязковим параметром: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.
Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного ConfigMap буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у ConfigMap, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.
Вміст поля Data цільового Secret буде представлений у томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів. Томи Secret підтримують керування власністю та перепризначення міток SELinux.*
optional — вказує, чи Secret або його ключі мають бути визначені.
secret.defaultMode (int32)
defaultMode є необовʼязковим параметром: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.
Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного Secret буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у Secret, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.
downwardAPI (DownwardAPIVolumeSource)
downwardAPI — представляє downward API Podʼа, який повинен заповнити цей том.
DownwardAPIVolumeSource представляє том з вмістом з downward API. Томи downward API підтримують керування власністю та перепризначення міток SELinux.
downwardAPI.defaultMode (int32)
Опційно: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.
projected — елементи для ресурсів all-in-one Secret, ConfigMap, downward API
Представляє джерело projected тому
projected.defaultMode (int32)
defaultMode є бітами режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.
projected.sources ([]VolumeProjection)
sources — список джерел, які мають бути спроєцьовані
Проєкція, яка може бути спроєцьована разом з іншими підтримуваними типами томів
projected.sources.configMap (ConfigMapProjection)
configMap — інформація про дані ConfigMap, які мають бути спроєцьовані
*Адаптує ConfigMap для projected тому
Вміст поля Data цільового ConfigMap буде представлений у projected томі у вигляді файлів, використовуючи ключі у полі даних як назви файлів, якщо елемент items заповнений конкретними зіставленнями ключів зі шляхами. Зверніть увагу, що це ідентично джерелу тому ConfigMap без стандартного режиму.*
Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного ConfigMap буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у ConfigMap, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.
downwardAPI — інформація про дані downward API, які мають бути спроєцьовані
Представляє інформацію downward API для проєцювання у projected том. Зверніть увагу, що це ідентично джерелу тому downward API без стандартного режиму.
secret – інформація про дані Secret, які мають бути спроєцьовані
*Адаптує Secret для projected тому.
Вміст поля Data цільового Secret буде представлений у projected томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів. Зверніть увагу, що це ідентично джерелу тому Secret без стандартного режиму.*
Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного Secret буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у Secret, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.
serviceAccountToken — інформація про дані serviceAccountToken, які мають бути спроєцьовані
ServiceAccountTokenProjection представляє projected том токена службового облікового запису. Ця проєкція може бути використана для вставки токена службового облікового запису в файлову систему Podʼа для використання з API (сервера API Kubernetes або іншого).
audience — це призначений отримувач токена. Отримувач токена повинен ідентифікувати себе із вказаним ідентифікатором в аудиторії токена або, в іншому випадку, повинен відхилити токен. Стандартно audience — це ідентифікатор apiserver.
expirationSeconds — це запитаний термін дійсності токена службового облікового запису. В міру наближення до закінчення терміну дії токена, втулок томів kubelet буде працювати у режимі проактивної ротації токена службового облікового запису. Kubelet буде спробувати почати ротацію токена, якщо токен старше 80 відсотків його часу життя або якщо токен старше 24 годин. Стандартне значення — 1 година і повинно бути принаймні 10 хвилин.
Представляє порожню теку для Podʼа. Томи порожніх тек підтримують управління власністю та перепризначення міток SELinux.
emptyDir.medium (string)
medium представляє тип носія для зберігання, який повинен підтримувати цю теку. Стандартне значення — "" (порожній рядок), що означає використання стандартного носія вузла. Повинно бути порожнім рядком (стандартно) або "Memory". Додаткова інформація: Посилання на документацію Kubernetes про EmptyDir
sizeLimit — це загальна кількість локальної памʼяті, необхідна для цього тому EmptyDir. Обмеження розміру також застосовується для носія типу "Memory". Максимальне використання на носії типу "Memory" для EmptyDir буде мінімальним значенням між зазначеним тут SizeLimit та сумою обмежень памʼяті всіх контейнерів у Podʼі. Стандартне значення — nil, що означає, що обмеження не визначено. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#emptydir
hostPath (HostPathVolumeSource)
hostPath представляє попередньо наявний файл або теку на хост-машині, який безпосередньо доступний контейнеру. Це зазвичай використовується для системних агентів або інших привілейованих речей, яким дозволено бачити хост-машину. Більшість контейнерів НЕ потребуватимуть цього. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#hostpath
Представляє шлях хосту зіставлений з Pod. Томи hostPath не підтримують управління власністю або перевизначення міток SELinux.
Диск AWS EBS повинен існувати перед підключенням до контейнера. Диск також повинен знаходитися в тій же зоні AWS, що і kubelet. Диск AWS EBS може бути змонтований з приавами читання/запис тільки один раз. Томи AWS EBS підтримують управління власністю та перепризначення міток SELinux.*
fsType — це тип файлової системи тому, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Якщо не вказано, неявно припускається, що це "ext4". Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore
awsElasticBlockStore.partition (int32)
partition — це розділ у томі, який ви хочете змонтувати. Якщо він не вказаний, то стандартно монтується за назвою тому. Приклади: Для тому /dev/sda1 ви вказуєте розділ "1". Аналогічно, розділ тому для /dev/sda є "0" (або ви можете залишити властивість порожньою).
azureDisk представляє монтування Azure Data Disk на хості та привʼязує монтування до Podʼа.
AzureDisk представляє монтування Azure Data Disk на хості та привʼязане монтування до Podʼа.
azureDisk.diskName (string), обовʼязкове
diskName — це імʼя диска даних у blob-сховищі
azureDisk.diskURI (string), обовʼязкове
diskURI — це URI диска даних у blob-сховищі
azureDisk.cachingMode (string)
cachingMode — це режим кешування хосту: None, Read Only, Read Write.
azureDisk.fsType (string)
fsType — це тип файлової системи для монтування. Повинен бути типом файлової системи, підтримуваним операційною системою хосту. Наприклад, "ext4", "xfs", "ntfs". Неявно припускається, що це "ext4", якщо не вказано інше.
azureDisk.kind (string)
Очікувані значення kind: Shared (кілька blob-дисків на один обліковий запис зберігання), Dedicated (один blob-диск на обліковий запис зберігання), Managed (azure managed data disk, тільки в керованому наборі доступності). Стандартне значення — Shared.
azureDisk.readOnly (boolean)
readOnly стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts.
azureFile (AzureFileVolumeSource)
azureFile представляє монтування служби файлів Azure на хості та привʼязане монтування до Podʼа.
AzureFile представляє монтування служби файлів Azure на хості та привʼязане монтування до Podʼа.
azureFile.secretName (string), обовʼязкове
secretName — це імʼя секрету, що містить імʼя та ключ облікового запису Azure Storage.
azureFile.shareName (string), обовʼязкове
shareName — це імʼя розділу Azure.
azureFile.readOnly (boolean)
readOnly стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts.
cephfs (CephFSVolumeSource)
cephFS представляє монтування Ceph FS на хості, яке діє впродовж життєвого циклу Podʼа.
Представляє монтування файлової системи Ceph, яке діє впродовж життєвого циклу Podʼа. Томи cephfs не підтримують управління власністю або перепризначення міток SELinux.
Представляє ресурс тому Cinder в Openstack. Том Cinder повинен існувати перед монтуванням до контейнера. Том також повинен знаходитися в тому ж регіоні, що і kubelet. Томи Cinder підтримують управління власністю та перепризначення міток SELinux.
fsType — це тип файлової системи для монтування. Повинен бути типом файлової системи, підтримуваним операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно припускається, що це "ext4", якщо не вказано інше. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md
cinder.readOnly (boolean)
readOnly стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md
secretRef є необовʼязковим: вказує на обʼєкт секрету, що містить параметри, які використовуються для підключення до OpenStack.
csi (CSIVolumeSource)
csi (Container Storage Interface) представляє ефемерне сховище, яке обробляється певними зовнішніми драйверами CSI (бета-функція).
Представляє джерело розташування тому для монтування, керованого зовнішнім драйвером CSI
csi.driver (string), обовʼязкове
driver — це імʼя драйвера CSI, який обробляє цей том. Проконсультуйтеся з адміністратором для отримання правильного імені, зареєстрованого в кластері.
csi.fsType (string)
fsType для монтування. Наприклад, "ext4", "xfs", "ntfs". Якщо не вказано, порожнє значення передається відповідному драйверу CSI, який визначить стандартну файлову систему.
nodePublishSecretRef є посиланням на обʼєкт секрету, що містить конфіденційну інформацію, яку потрібно передати драйверу CSI для завершення викликів CSI NodePublishVolume і NodeUnpublishVolume. Це поле є необовʼязковим і може бути порожнім, якщо секрет не потрібен. Якщо обʼєкт секрету містить більше одного секрету, всі посилання на секрети передаються.
csi.readOnly (boolean)
readOnly вказує на конфігурацію тільки для читання для тому. Стандартне значення — false (читання/запис).
csi.volumeAttributes (map[string]string)
volumeAttributes зберігає властивості, специфічні для драйвера, які передаються драйверу CSI. Проконсультуйтеся з документацією вашого драйвера для підтримуваних значень.
ephemeral (EphemeralVolumeSource)
ephemeral представляє том, який обробляється кластерним драйвером зберігання. Життєвий цикл тому привʼязаний до Podʼа, який його визначає — том буде створено перед запуском Podʼа і видалено після видалення Podʼа.
Використовуйте це, якщо: a) том потрібен лише під час роботи Podʼа, b) потрібні функції звичайних томів, такі як відновлення зі знімка або відстеження ємності, c) драйвер зберігання вказується через клас зберігання, і d) драйвер зберігання підтримує динамічне надання томів через PersistentVolumeClaim (див. EphemeralVolumeSource для отримання додаткової інформації про звʼязок між цим типом тому та PersistentVolumeClaim).
Використовуйте PersistentVolumeClaim або один з API, специфічних для постачальника, для томів, які зберігаються довше, ніж життєвий цикл окремого Podʼа.
Використовуйте CSI для легких локальних ефемерних томів, якщо драйвер CSI призначений для такого використання — див. документацію драйвера для отримання додаткової інформації.
Pod може одночасно використовувати як ефемерні томи, так і постійні томи.
Представляє ефемерний том, який обробляється звичайним драйвером зберігання.
Буде використовуватись для створення окремого PVC для надання тому. Pod, в якому вбудовано цей EphemeralVolumeSource, буде власником PVC, тобто PVC буде видалено разом з Podʼом. Назва PVC буде <pod name>-<volume name>, де <volume name> — це назва з масиву PodSpec.Volumes. Валідація Podʼа відхилить Pod, якщо обʼєднана назва не є дійсною для PVC (наприклад, занадто довга).
Існуючий PVC з такою назвою, який не належить Podʼу, не буде використаний для Podʼа, щоб уникнути випадкового використання неповʼязаного тому. Запуск Podʼа буде заблокований до видалення неповʼязаного PVC. Якщо такий попередньо створений PVC призначений для використання Podʼом, PVC має бути оновлено з посиланням на власника Podʼа після створення Podʼа. Зазвичай це не повинно бути необхідним, але може бути корисним при ручному відновленні зламаного кластера.
Це поле є лише для читання, і Kubernetes не вноситиме змін до PVC після його створення.
Обовʼязкове, не може бути nil.
PersistentVolumeClaimTemplate використовується для створення обʼєктів PersistentVolumeClaim як частини EphemeralVolumeSource.
Специфікація для PersistentVolumeClaim. Весь вміст копіюється без змін у PVC, який створюється з цього шаблону. Ті ж самі поля, що й у PersistentVolumeClaim, також дійсні тут.
Може містити мітки та анотації, які будуть скопійовані у PVC під час його створення. Інші поля не дозволені і будуть відхилені під час валідації.
fc (FCVolumeSource)
fc представляє ресурс Fibre Channel, що підключений до хост-машини kubelet і потім експонується для доступу у Podʼі.
Представляє том Fibre Channel. Томи Fibre Channel можуть монтуватися для запису/читання лише один раз. Томи Fibre Channel підтримують керування власністю та перепризначення міток SELinux.
fc.fsType (string)
fsType — це тип файлової системи для монтування. Має бути типом файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.
fc.lun (int32)
lun є необовʼязковим: Номер LUN (логічної одиниці) цілі FC
fc.readOnly (boolean)
readOnly є необовʼязковим: Стандартне значення — false (читання/запис). Значення ReadOnly тут примусово встановить параметр ReadOnly у VolumeMounts.
fc.targetWWNs ([]string)
targetWWNs є необовʼязковими: FC звертається до всесвітніх імен (WWNs)
fc.wwids ([]string)
wwids є необовʼязковими: Всесвітні ідентифікатори томів FC (wwids). Або wwids, або комбінація targetWWNs і lun повинні бути встановлені, але не обидва одночасно.
flexVolume (FlexVolumeSource)
flexVolume представляє загальний ресурс тома, що створюється/підключається за допомогою втулка на основі exec.
FlexVolume представляє загальний ресурс тома, що створюється/підключається за допомогою втулка на основі exec.
flexVolume.driver (string), обовʼязково
driver — це назва драйвера, який використовується для цього тома.
flexVolume.fsType (string)
fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Стандартний тип файлової системи залежить від скрипта FlexVolume.
flexVolume.options (map[string]string)
options є необовʼязковим: це поле містить додаткові командні параметри, якщо такі є.
flexVolume.readOnly (boolean)
readOnly є необовʼязковим: Стандартне значення — false (читання/запис). Значення ReadOnly тут примусово встановить параметр ReadOnly у VolumeMounts.
secretRef є необовʼязковим: secretRef — це посилання на обʼєкт секрету, що містить конфіденційну інформацію для передачі у скрипти втулка. Воно може бути порожнім, якщо обʼєкт секрету не вказаний. Якщо обʼєкт секрету містить більше одного секрету, всі секрети передаються у скрипти втулка.
flocker (FlockerVolumeSource)
flocker представляє том Flocker, приєднаний до хост-машини kubelet. Залежить від роботи служби управління Flocker.
Представляє том Flocker, змонтований агентом Flocker. Повинно бути встановлено тільки щось одне з datasetName і datasetUUID. Томи Flocker не підтримують керування власністю або перепризначення міток SELinux.
flocker.datasetName (string)
datasetName — це назва набору даних, збереженого як метадані -> name на наборі даних для Flocker слід вважати застарілим
flocker.datasetUUID (string)
datasetUUID — це UUID набору даних. Це унікальний ідентифікатор набору даних Flocker.
*Представляє ресурс постійного диска в Google Compute Engine.
Для монтування до контейнера повинен існувати диск GCE PD. Диск також повинен знаходитися в тому ж проекті GCE та зоні, що й kubelet. Диск GCE PD може бути змонтований лише один раз для читання/запису або багато разів для читання. Диски GCE PD підтримують керування власністю та перепризначення міток SELinux.*
fsType — тип файлової системи тома, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk
gcePersistentDisk.partition (int32)
partition — це розділ у томі, який ви хочете змонтувати. Якщо пропущено, стандартно монтується за імʼям тома. Приклади: Для тому /dev/sda1 ви вказуєте розділ як "1". Так само, розділ тому для /dev/sda — "0" (або ви можете залишити властивість порожньою). Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk
Представляє монтування Glusterfs, яке діє впрожовж життєвого циклу Podʼа. Томи Glusterfs не підтримують керування власністю або перепризначення міток SELinux.
iscsi представляє ресурс диска ISCSI, який приєднаний до хост-машини kubelet і потім експонується для доступу у Podʼі. Додаткова інформація: https://examples.k8s.io/volumes/iscsi/README.md
Представляє диск ISCSI. Томи ISCSI можуть бути змонтовані лише один раз для читання/запису. Томи ISCSI підтримують керування власністю та перепризначення міток SELinux.
iscsi.iqn (string), обовʼязково
iqn — це цільове Імʼя ISCSI Qualified Name.
iscsi.lun (int32), обовʼязково
lun представляє номер цільового LUN (логічної одиниці) ISCSI.
iscsi.targetPortal (string), обовʼязково
targetPortal — це цільовий портал ISCSI. Портал — це IP або ip_addr:порт, якщо порт відмінний від типового (зазвичай TCP-порти 860 і 3260).
iscsi.chapAuthDiscovery (boolean)
chapAuthDiscovery визначає, чи підтримується автентифікація CHAP для виявлення ISCSI
iscsi.chapAuthSession (boolean)
chapAuthSession визначає, чи підтримується сесійна автентифікація CHAP для ISCSI
iscsi.fsType (string)
fsType — це тип файлової системи тома, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#iscsi
iscsi.initiatorName (string)
initiatorName — це власне Імʼя Ініціатора ISCSI. Якщо initiatorName вказаний одночасно з iscsiInterface, буде створено новий інтерфейс ISCSI <цільовий портал>:<імʼя тома> для підключення.
iscsi.iscsiInterface (string)
iscsiInterface — це імʼя інтерфейсу, який використовує транспорт ISCSI. Стандартне значення — 'default' (tcp).
iscsi.portals ([]string)
portals — це список цільових порталів ISCSI. Портал — це IP або ip_addr:порт, якщо порт відмінний від типового (зазвичай TCP-порти 860 і 3260).
iscsi.readOnly (boolean)
readOnly тут примусово встановить параметр ReadOnly у VolumeMounts. Стандартне значення — false.
photonPersistentDisk представляє постійний диск PhotonController, приєднаний та змонтований на хост-машині kubelets.
Представляє ресурс постійного диска Photon Controller.
photonPersistentDisk.pdID (string), обовʼязково
pdID — це ідентифікатор, який ідентифікує постійний диск Photon Controller.
photonPersistentDisk.fsType (string)
fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.
portworxVolume (PortworxVolumeSource)
portworxVolume представляє том Portworx, приєднаний та змонтований на хост-машині kubelets.
PortworxVolumeSource представляє ресурс тома Portworx.
portworxVolume.volumeID (string), обовʼязково
volumeID унікально ідентифікує том Portworx.
portworxVolume.fsType (string)
fsType представляє тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs". Неявно вважається "ext4", якщо не вказано інше.
portworxVolume.readOnly (boolean)
readOnly стандартне значення — false (читання/запис). Встановлення readOnly тут примусить встановити параметр ReadOnly у VolumeMounts.
quobyte (QuobyteVolumeSource)
quobyte представляє монтування Quobyte на хості, яке діє впродовж життєвого циклу Podʼа.
Представляє монтування Quobyte, яке діє впродовж життєвого циклу Podʼа. Томи Quobyte не підтримують керування власністю або перепризначення міток SELinux.
quobyte.registry (string), обовʼязково
registry представляє один або кілька служб реєстру Quobyte, вказаних як рядок у вигляді пари host:port (декілька записів розділяються комами), який діє як центральний реєстр для томів.
quobyte.volume (string), обовʼязково
volume — це рядок, який посилається на вже створений том Quobyte за імʼям.
quobyte.group (string)
group — група для відображення доступу до тома. Стандартне знечення — без групи.
quobyte.readOnly (boolean)
readOnly тут примусово змусить монтування тома Quobyte з правами тільки на читання. Стандартне значення — false.
quobyte.tenant (string)
tenant, який володіє вказаним томом Quobyte в Backend. Використовується з динамічно створюваними томами Quobyte, значення встановлюється втулком.
quobyte.user (string)
user — користувач для зіставлення (map) доступу до тома. Стандартне знечення — користувач serivceaccount.
Представляє монтування блочного пристрою Rados, яке діє впродовж життєвого циклу Podʼа. Томи RBD підтримують керування власністю та перепризначення міток SELinux.
fsType — це тип файлової системи тома, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#rbd
rbd.keyring (string)
keyring — це шлях до вʼязки ключів користувача RBDUser. Стандартне значення — /etc/ceph/keyring. Додаткова інформація: htts://examples.k8s.io/volumes/rbd/README.md#how-to-use-it
secretRef посилається на секрет для користувача ScaleIO та іншої конфіденційної інформації. Якщо це не надано, операція входу не вдасться.
scaleIO.system (string), обовʼязково
system — це імʼя системи зберігання, налаштоване в ScaleIO.
scaleIO.fsType (string)
fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Стандартне значення — "xfs".
scaleIO.protectionDomain (string)
protectionDomain — це імʼя ScaleIO Protection Domain для налаштованого зберігання.
scaleIO.readOnly (boolean)
readOnly стандартне значення — false (читання/запис). Встановлення readOnly тут примусить встановити параметр ReadOnly у VolumeMounts.
scaleIO.sslEnabled (boolean)
sslEnabled — прапорець, що ввімкнує/вимикає SSL-звʼязок з шлюзом, станддартне значення — false
scaleIO.storageMode (string)
storageMode вказує, чи повинно бути зберігання для тому ThickProvisioned чи ThinProvisioned. Стандартне значення — ThinProvisioned.
scaleIO.storagePool (string)
storagePool — це пул зберігання ScaleIO, повʼязаний з доменом захисту.
scaleIO.volumeName (string)
volumeName — це імʼя тому, вже створеного в системі ScaleIO, який повʼязаний з цим джерелом тому.
storageos (StorageOSVolumeSource)
storageos представляє том StorageOS, приєднаний та змонтований на вузлах Kubernetes.
Представляє постійний ресурс тому StorageOS.
storageos.fsType (string)
fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.
storageos.readOnly (boolean)
readOnly стандартне значення — false (читання/запис). Встановлення readOnly тут примусить встановити параметр ReadOnly у VolumeMounts.
secretRef вказує секрет для отримання облікових даних API StorageOS. Якщо не вказано, будуть спробовані стандартні значення.
storageos.volumeName (string)
volumeName — це людино-читане імʼя тому StorageOS. Імена томів є унікальними лише в межах простору імен.
storageos.volumeNamespace (string)
volumeNamespace вказує том простору імен в межах StorageOS. Якщо простір імен не вказано, тоді буде використано простір імен Pod. Це дозволяє дублювати простори імен Kubernetes у StorageOS для більш тісної інтеграції. Встановіть VolumeName на будь-яке імʼя для заміни стандартної поведінки. Встановіть на "default", якщо ви не використовуєте простори імен у StorageOS. Простори імен, які не існують заздалегідь у StorageOS, будуть створені.
vsphereVolume (VsphereVirtualDiskVolumeSource)
vsphereVolume представляє том vSphere, приєднаний та змонтований на вузлах kubelet.
Представляє ресурс тому vSphere.
vsphereVolume.volumePath (string), обовʼязково
volumePath — це шлях, який ідентифікує том vmdk vSphere.
vsphereVolume.fsType (string)
fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.
vsphereVolume.storagePolicyID (string)
storagePolicyID — це ідентифікатор профілю управління політикою зберігання (SPBM), повʼязаний з іменем StoragePolicyName.
vsphereVolume.storagePolicyName (string)
storagePolicyName — це імʼя профілю управління політикою зберігання (SPBM).
Застаріле
gitRepo (GitRepoVolumeSource)
gitRepo представляє репозиторій git на певному рівні ревізії. Застаріло: GitRepo застаріло. Для створення контейнера з репозиторієм git підключіть EmptyDir до InitContainer, який клонує репо за допомогою git, а потім підключіть EmptyDir до контейнера Pod.
*Представляє том, який заповнений вмістом репозиторію git. Томи репозиторію git не підтримують управління власниками. Томи репозиторію git підтримують перепризначення міток SELinux.
Застаріло: GitRepo застаріло. Для створення контейнера з репозиторієм git підключіть EmptyDir до InitContainer, який клонує репо за допомогою git, а потім підключіть EmptyDir до контейнера Pod.*
gitRepo.repository (string), обовʼязково
repository — це URL
gitRepo.directory (string)
directory — це назва цільової теки. Не повинен містити або починатися з '..'. Якщо '.' надано, тека тому буде репозиторієм git. В іншому випадку, якщо вказано, том буде містити репозиторій git у підтеці з вказаною назвою.
gitRepo.revision (string)
revision — це хеш коміту для вказаної ревізії.
DownwardAPIVolumeFile
DownwardAPIVolumeFile представляє інформацію для створення файлу, що містить поле pod.
path (string), обовʼязково
Обовʼязково: path — це відносний шлях до файлу, який буде створено. Не повинен бути абсолютним або містити шлях "..". Має бути закодований у кодуванні utf-8. Перший елемент відносного шляху не повинен починатися з "..".
Обовʼязково: Вибирає поле pod: підтримуються лише анотації, мітки, імʼя та простір імен.
mode (int32)
Опціонально: біти режиму, які використовуються для встановлення дозволів на цей файл, повинні бути вісімковим значенням від 0000 до 0777 або десятковим значенням від 0 до 511. У YAML приймаються як вісімкові, так і десяткові значення, у JSON потрібні десяткові значення для бітів режиму. Якщо не вказано, буде використано стандартне значення для тому. Це може конфліктувати з іншими параметрами, що впливають на режим файлу, наприклад, fsGroup, і результат може бути іншим набором бітів режиму.
Вибирає ресурс контейнера: наразі підтримуються лише обмеження та запити ресурсів (limits.cpu, limits.memory, requests.cpu та requests.memory).
KeyToPath
Зіставляє ключ зі шляхом в томі.
key (string), обовʼязково
key — це ключ, який потрібно проєцювати.
path (string), обовʼязково
path — це відносний шлях файлу, який слід прикріпити до ключа. Не може бути абсолютним шляхом. Не може містити елемента шляху '..'. Не може починатися з рядка '..'.
mode (int32)
mode — опціонально: біти режиму, які використовуються для встановлення дозволів на цей файл. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У YAML приймаються як вісімкові, так і десяткові значення, у JSON для бітів режиму потрібні десяткові значення. Якщо не вказано, буде використано стнадартне значення для тому. Це може конфліктувати з іншими параметрами, що впливають на режим файлу, такими як fsGroup, і результат може бути іншим набором бітів режиму.
5.3.4 - PersistentVolumeClaim
PersistentVolumeClaim — це запит користувача на постійний том і заявка на нього.
apiVersion: v1
import "k8s.io/api/core/v1"
PersistentVolumeClaim
PersistentVolumeClaim представляє запит користувача на отримання та право на постійний том.
selector — це запит мітки для томів, які слід враховувати при звʼязуванні.
resources (ResourceRequirements)
resources представляє мінімальні ресурси, якими повинен володіти том. Якщо включено можливість RecoverVolumeExpansionFailure, користувачам дозволяється вказувати вимоги до ресурсів, які нижчі за попереднє значення, але все ще мають бути вищими, ніж місткість, вказана в полі статусу вимоги. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources
ResourceRequirements описує вимоги до обчислювальних ресурсів.
resources.claims ([]ResourceClaim)
Map: унікальні значення на ключа name будуть збережені під час злиття
Claims отримує перелік назв ресурсів, визначених у spec.resourceClaims, які використовуються цим контейнером.
Це поле альфа і вимагає активації власності DynamicResourceAllocation.
Це поле незмінне. Його можна встановити лише для контейнерів.
ResourceClaim посилається на один запис в PodSpec.ResourceClaims.
resources.claims.name (string), обовʼязково
Назва повинна відповідати назві одного запису у pod.spec.resourceClaims Podʼа, де використовується це поле. Вона робить цей ресурс доступним всередині контейнера.
Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється як Limits, якщо це явно вказано, інакше — як значення, визначене реалізацією. Запити не можуть перевищувати Limits. Додаткова інформація: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
volumeName (string)
volumeName — це посилання на звʼязування з постійним томом, що підтримує цей запит.
Якщо провайдер або зовнішній контролер може підтримувати вказане джерело даних, він створить новий том на основі вмісту вказаного джерела даних. Коли вмикається функціональна властивість AnyVolumeDataSource, вміст dataSource буде скопійовано до dataSourceRef, а вміст dataSourceRef буде скопійовано до dataSource, коли не вказано dataSourceRef.namespace. Якщо вказано простір імен, то dataSourceRef не буде скопійовано до dataSource.
dataSourceRef (TypedObjectReference)
dataSourceRef вказує на обʼєкт, з якого потрібно заповнити том даними, якщо потрібний непорожній том. Це може бути будь-який обʼєкт з непорожньої API-групи (не базовий обʼєкт) або обʼєкт PersistentVolumeClaim. Коли вказано це поле, звʼязування тому вдасться тільки в тому випадку, якщо тип вказаного обʼєкта відповідає якомусь встановленому наповнювачу тому або динамічному провайдеру. Це поле замінить функціональність поля dataSource і як таке, якщо обидва поля непорожні, вони повинні мати однакове значення. Для забезпечення зворотної сумісності, коли простір імен не вказано в dataSourceRef, обидва поля (dataSource та dataSourceRef) будуть автоматично встановлені в одне значення, якщо одне з них порожнє, а інше — непорожнє. Коли простір імен вказаний в dataSourceRef, dataSource не встановлюється в те ж саме значення і повинно бути порожнім. Є три важливі відмінності між dataSource та dataSourceRef:
Поки dataSource дозволяє лише два конкретних типи обʼєктів, dataSourceRef дозволяє будь-які не базові обʼєкти, а також обʼєкти PersistentVolumeClaim.
Поки dataSource ігнорує заборонені значення (вилучаючи їх), dataSourceRef зберігає всі значення і генерує помилку, якщо вказано заборонене значення.
Поки dataSource дозволяє лише локальні обʼєкти, dataSourceRef дозволяє обʼєкти в будь-яких просторах імен.
(Бета) Використання цього поля вимагає ввімкненої властивості AnyVolumeDataSource. (Альфа) Використання поля namespace у dataSourceRef вимагає ввімкненої властивості CrossNamespaceVolumeDataSource.
**
dataSourceRef.kind (string), обовʼязково
Kind — це тип ресурсу, на який вказується
dataSourceRef.name (string), обовʼязково
Name — це назва ресурсу, на який вказується
dataSourceRef.apiGroup (string)
APIGroup — це група для ресурсу, на який вказується. Якщо APIGroup не вказано, вказаний Kind повинен бути в базовій групі API. Для будь-яких інших сторонніх типів APIGroup обовʼязковий.
dataSourceRef.namespace (string)
Namespace — це простір імен ресурсу, на який вказується. Зверніть увагу, що при вказанні простору імен для призначення namespace необхідний обʼєкт gateway.networking.k8s.io/ReferenceGrant в просторі імен-джерелі, щоб дозволити власнику цього простору імен приймати посилання. Див. документацію ReferenceGrant для отримання деталей. (Альфа) Це поле вимагає ввімкненої властивості CrossNamespaceVolumeDataSource.
PersistentVolumeClaimStatus
PersistentVolumeClaimStatus — це поточний статус запиту на постійний том.
allocatedResourceStatuses зберігає статус ресурсу, який змінюється для даного PVC. Імена ключів відповідають стандартному синтаксису міток Kubernetes. Допустимі значення:
Ключі без префіксу:
storage — місткість тому.
Власні ресурси повинні використовувати визначені реалізацією префіксовані імена, наприклад, "example.com/my-custom-resource".
Крім вищезазначених значень — ключі без префіксу або з префіксом kubernetes.io вважаються зарезервованими й, отже, не можуть використовуватися.
ClaimResourceStatus може бути в одному з наступних станів:
ControllerResizeInProgress: Стан встановлюється, коли контролер зміни розміру починає змінювати розмір тому в панелі управління.
ControllerResizeFailed: Стан встановлюється, коли зміна розміру не вдалася у контролері зміни розміру з термінальною помилкою.
NodeResizePending: Стан встановлюється, коли контролер зміни розміру завершив зміну розміру тому, але подальша зміна розміру тому необхідна на вузлі.
NodeResizeInProgress: Стан встановлюється, коли kubelet починає змінювати розмір тому.
NodeResizeFailed: Стан встановлюється, коли зміна розміру не вдалася у kubelet з термінальною помилкою. Тимчасові помилки не встановлюють NodeResizeFailed.
Наприклад, якщо PVC розширюється для більшої місткості, це поле може бути в одному з наступних станів:
Якщо це поле не встановлено, це означає, що операція зміни розміру для даного PVC не виконується.
Контролер, що отримує оновлення PVC з невідомим раніше resourceName або ClaimResourceStatus, повинен ігнорувати оновлення з метою, для якої він був створений. Наприклад, контролер, який відповідає лише за зміну розміру місткості тому, повинен ігнорувати оновлення PVC, які змінюють інші дійсні ресурси, повʼязані з PVC.
Це поле альфа-версії та вимагає ввімкнення властивості RecoverVolumeExpansionFailure.
allocatedResources відстежує ресурси, виділені для PVC, включаючи його місткість. Імена ключів відповідають стандартному синтаксису міток Kubernetes. Допустимі значення:
Ключі без префіксу:
storage - місткість тому.
Власні ресурси повинні використовувати визначені реалізацією префіксовані імена, наприклад, "example.com/my-custom-resource"
Крім вищезазначених значень — ключі без префіксу або з префіксом kubernetes.io вважаються зарезервованими й, отже, не можуть використовуватися.
Місткість, зазначена тут, може бути більшою за фактичну місткість, коли запит на розширення тому виконується. Для квоти на зберігання використовується більше значення з allocatedResources і PVC.spec.resources. Якщо allocatedResources не встановлено, для розрахунку квоти використовується лише PVC.spec.resources. Якщо запит на розширення місткості тому знижено, allocatedResources знижується лише в тому випадку, якщо операції розширення не виконуються і якщо фактична місткість тому дорівнює або нижча за запитану місткість.
Контролер, що отримує оновлення PVC з невідомим раніше resourceName, повинен ігнорувати оновлення з метою, для якої він був створений. Наприклад, контролер, який відповідає лише за зміну розміру місткості тому, повинен ігнорувати оновлення PVC, які змінюють інші дійсні ресурси, повʼязані з PVC.
Це поле альфа-версії та вимагає ввімкнення властивості RecoverVolumeExpansionFailure.
capacity представляє фактичні ресурси базового тому.
conditions ([]PersistentVolumeClaimCondition)
Patch strategy: злиття за ключем type
conditions — це поточний стан запиту на постійний том. Якщо базовий постійний том змінюється в розмірі, стан буде встановлено на 'ResizeStarted'.
PersistentVolumeClaimCondition містить деталі про стан pvc
conditions.status (string), обовʼязково
conditions.type (string), обовʼязково
conditions.lastProbeTime (Time)
lastProbeTime - це час, коли ми обстежили стан.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.lastTransitionTime (Time)
lastTransitionTime — це час, коли стан перейшов з одного статусу до іншого.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
message — це зрозуміле для людини повідомлення, що вказує на деталі останнього переходу.
conditions.reason (string)
reason — це унікальний, короткий, зрозумілий для машини рядок, який вказує причину останнього переходу стану. Якщо він повідомляє "ResizeStarted", це означає, що базовий постійний том змінюється в розмірі.
phase (string)
phase представляє поточну фазу запиту на постійний том.
PersistentVolumeClaimList
PersistentVolumeClaimList — це список елементів PersistentVolumeClaim.
claimRef є частиною двостороннього звʼязування між PersistentVolume та PersistentVolumeClaim. Очікується, що він буде ненульовим при звʼязуванні. claim.VolumeName є офіційним звʼязуванням між PV та PVC. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#binding
nodeAffinity визначає обмеження, які обмежують доступ до цього тому з певних вузлів. Це поле впливає на планування Podʼів, які використовують цей том.
VolumeNodeAffinity визначає обмеження, які обмежують доступ до цього тому з певних вузлів.
nodeAffinity.обовʼязково (NodeSelector)
обовʼязково визначає жорсткі обмеження на вузли, які повинні бути виконані.
Селектор вузлів представляє обʼєднання результатів одного або кількох запитів по мітках у наборі вузлів; тобто, він представляє операцію АБО для селекторів, представлених термінами селектора вузлів.
Обовʼязково. Список термінів селектора вузлів. Терміни обʼєднуються операцією АБО.
Порожній або нульовий термін селектора вузлів не відповідає жодному обʼєкту. Вимоги до них обʼєднуються операцією І (AND). Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.
persistentVolumeReclaimPolicy визначає, що відбувається з постійним томом після його звільнення від заявки. Валідні варіанти: Retain (стандартно для створених вручну PersistentVolumes), Delete (стандартно для динамічно наданих PersistentVolumes) та Recycle (застаріле). Recycle повинен підтримуватися втулком тому, що забезпечує роботу цього PersistentVolume. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#reclaiming
storageClassName (string)
storageClassName — це назва StorageClass, до якого належить цей постійний том. Порожнє значення означає, що цей том не належить жодному StorageClass.
volumeMode (string)
volumeMode визначає, чи призначений том для використання з форматованою файловою системою або залишатиметься в необробленому блочному стані. Значення Filesystem мається на увазі, якщо не включено в специфікацію.
Local
hostPath (HostPathVolumeSource)
hostPath представляє теку на хості. Надається розробником або тестувальником. Це корисно лише для одновузлової розробки та тестування! Зберігання на хості жодним чином не підтримується та НЕ ПРАЦЮВАТИМЕ у багатовузловому кластері. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#hostpath
Представляє шлях на хості, зіставлений зі шляхом у Podʼі. Шляхи томів хосту не підтримують управління власністю або перепризначення міток SELinux.
local — це безпосередньо приєднане сховище зі спорідненістю до вузла
Local представляє безпосередньо приєднане сховище зі спорідненістю до вузла (бета-функція)
local.path (string), обовʼязкове
повний шлях до тому на вузлі. Це може бути або тека, або блоковий пристрій (диск, розділ і т.д.).
local.fsType (string)
fsType — це тип файлової системи для монтування. Застосовується лише тоді, коли Path є блоковим пристроєм. Повинен бути тип файлової системи, підтримуваний операційною системою хосту. Наприклад, "ext4", "xfs", "ntfs". Стандартне значення — автоматичний вибір файлової системи, якщо не вказано.
fsType — це тип файлової системи тому, який ви хочете монтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore
awsElasticBlockStore.partition (int32)
partition — це розділ у томі, який ви хочете монтувати. Якщо відсутній, то стандартно монтується за назвою тому. Приклади: Для тому /dev/sda1, ви вказуєте розділ як "1". Аналогічно, розділ тому /dev/sda є "0" (або ви можете залишити властивість пустою).
azureDisk представляє монтування Azure Data Disk на хості та звʼязане монтування у Podʼі.
Представляє монтування Azure Data Disk на хості та звʼязане монтування у Podʼі.
azureDisk.diskName (string), обовʼязково
diskName — це імʼя диска даних у сховищі blob
azureDisk.diskURI (string), обовʼязково
diskURI — це URI диска даних у сховищі blob
azureDisk.cachingMode (string)
cachingMode — це режим кешування на хості: None, Read Only, Read Write.
azureDisk.fsType (string)
fsType — тип файлової системи для монтування. Має бути типом файлової системи, підтриманим операційною системою хосту. Наприклад, "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.
azureDisk.kind (string)
kind — очікувані значення:
Shared: декілька томів блобів на обліковому записі сховища
Dedicated: один том блобів на обліковому записі сховища
Managed: керований диск даних Azure (лише в керованому наборі доступності). Стандартне значення — shared.
azureDisk.readOnly (boolean)
readOnly — стандартне значення — false (запис/читання). Якщо тут встановлено true, то встановлюється параметр readOnly у VolumeMounts.
azureFile (AzureFilePersistentVolumeSource)
azureFile представляє монтування Azure File Service на хості та звʼязане монтування у Podʼі.
Представляє монтування Azure File Service на хості та звʼязане монтування у Podʼі.
azureFile.secretName (string), обовʼязково
secretName — це імʼя Secret, що містить імʼя та ключ облікового запису Azure Storage
azureFile.shareName (string), обовʼязково
shareName — це назва розділу Azure
azureFile.readOnly (boolean)
readOnly — стандартне значення — false (запис/читання). Якщо тут встановлено true, то встановлюється параметр readOnly в VolumeMounts.
azureFile.secretNamespace (string)
secretNamespace — це простір імен Secret, що містить імʼя та ключ облікового запису Azure. Стандартно використовується той самий простір імен, що й у Podʼа.
cephfs (CephFSPersistentVolumeSource)
cephFS представляє монтування Ceph FS на хості, яке спільно використовується з життєвим циклом Pod.
Представляє монтування файлової системи Ceph, яка існує протягом життя Podʼу. Томи Cephfs не підтримують управління власниками або перепризначення міток SELinux.
Представляє ресурс тому Cinder в OpenStack. Том Cinder повинен існувати перед монтуванням у контейнер. Том також повинен знаходитися в тому ж регіоні, що й kubelet. Томи Cinder підтримують управління власниками та перепризначення міток SELinux.
fsType — тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хосту. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md
cinder.readOnly (boolean)
readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, параметр readOnly встановлюється в VolumeMounts. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md
cinder.secretRef (SecretReference)
secretRef — необовʼязково: посилання на обʼєкт Secret, що містить параметри для підключення до OpenStack.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
cinder.secretRef.name (string)
name —- унікальне імʼя в межах простору імен для посилання на ресурс Secret.
cinder.secretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
csi (CSIPersistentVolumeSource)
csi представляє сховище, яке обробляється зовнішнім драйвером CSI (функція Beta).
Представляє сховище, яке керується зовнішнім драйвером CSI для сховища (функція Beta)
csi.driver (string), обовʼязково
driver — це назва драйвера, який використовується для цього тому. Обовʼязково.
csi.volumeHandle (string), обовʼязково
volumeHandle — це унікальне імʼя тому, яке повертається драйвером CSI для посилання на том у всіх наступних викликах. Обовʼязково.
csi.controllerExpandSecretRef (SecretReference)
controllerExpandSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання виклику CSI ControllerExpandVolume. Це поле є необовʼязковим і може бути порожнім, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
csi.controllerExpandSecretRef.name (string)
name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.
csi.controllerExpandSecretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
csi.controllerPublishSecretRef (SecretReference)
controllerPublishSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання викликів CSI ControllerPublishVolume і ControllerUnpublishVolume. Це поле є необовʼязковим і може бути порожнім, якщо секрет не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
csi.controllerPublishSecretRef.name (string)
name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.
csi.controllerPublishSecretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
csi.fsType (string)
fsType — тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хосту. Наприклад, "ext4", "xfs", "ntfs".
csi.nodeExpandSecretRef (SecretReference)
nodeExpandSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання виклику CSI NodeExpandVolume. Це поле є необовʼязковим і може бути опущеним, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
csi.nodeExpandSecretRef.name (string)
name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.
csi.nodeExpandSecretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
csi.nodePublishSecretRef (SecretReference)
nodePublishSecretRef — посилання на обʼєкт, Secret що містить чутливу інформацію для передачі до драйвера CSI для виконання викликів CSI NodePublishVolume і NodeUnpublishVolume. Це поле є необовʼязковим і може бути порожнім, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
csi.nodePublishSecretRef.name (string)
name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.
csi.nodePublishSecretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
csi.nodeStageSecretRef (SecretReference)
nodeStageSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання викликів CSI NodeStageVolume і NodeUnstageVolume. Це поле є необовʼязковим і може бути порожнім, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
csi.nodeStageSecretRef.name (string)
name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.
csi.nodeStageSecretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
csi.readOnly (boolean)
readOnly — значення для передачі до ControllerPublishVolumeRequest. Стандартне значення — false (запис/читання).
csi.volumeAttributes (map[string]string)
volumeAttributes — атрибути тому для публікації.
fc (FCVolumeSource)
fc представляє ресурс Fibre Channel, який приєднується до хост-машини kubelet і потім експонується для використання в Podʼі.
Представляє том Fibre Channel. Томи Fibre Channel можуть бути приєднані лише як для читання/запису один раз. Томи Fibre Channel підтримують управління власниками та перепризначення міток SELinux.
fc.fsType (string)
fsType — це тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хосту. Наприклад, "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.
fc.lun (int32)
lun — необовʼязково: номер lun.
fc.readOnly (boolean)
readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, встановлюється параметр readOnly у VolumeMounts.
fc.targetWWNs ([]string)
targetWWNs — необовʼязково: FC вказує всесвітні імена (worldwide names, WWN).
fc.wwids ([]string)
wwids — необовʼязково: світові ідентифікатори тома FC (WWID). Можна встановити або wwids, або комбінацію targetWWNs і lun, але не одночасно.
flexVolume (FlexPersistentVolumeSource)
flexVolume представляє загальний ресурс тома, який надається/приєднується за допомогою втулка.
FlexPersistentVolumeSource представляє загальний постійний том, який надається/приєднується за допомогою втулка.
flexVolume.driver (string), обовʼязково
driver — це імʼя драйвера, яке використовується для цього тома.
flexVolume.fsType (string)
fsType — тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хоста. Наприклад, "ext4", "xfs", "ntfs". Тип стандартної файлової системи залежить від сценарію FlexVolume.
flexVolume.options (map[string]string)
options — необовʼязково: це поле містить додаткові параметри команди, якщо такі є.
flexVolume.readOnly (boolean)
readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, встановлюється параметр readOnly у VolumeMounts.
flexVolume.secretRef (SecretReference)
secretRef — необовʼязково: посилання на обʼєкт Secret, що містить чутливу інформацію для передачі в сценарії втулка. Це поле може бути порожнім, якщо обʼєкт Secret не вказано. Якщо Secret містить більше одного секрету, всі вони передаються в сценарії втулка.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
flexVolume.secretRef.name (string)
name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.
flexVolume.secretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
flocker (FlockerVolumeSource)
flocker представляє том Flocker, приєднаний до хост-машини kubelet і експонований для використання в Podʼі. Це залежить від того, чи працює служба керування Flocker.
Представляє том Flocker, приєднаний агентом Flocker. Повинно бути встановлено одне і тільки одне значення datasetName або datasetUUID. Томи Flocker не підтримують управління власниками або перевизначення міток SELinux.
flocker.datasetName (string)
datasetName — імʼя набору даних, збережене як метадані -> імʼя для набору даних Flocker. Вважається застарілим.
flocker.datasetUUID (string)
datasetUUID — UUID набору даних. Це унікальний ідентифікатор набору даних Flocker.
Представляє постійний диск в Google Compute Engine.
Диск GCE повинен існувати перед монтуванням в контейнер. Диск також повинен знаходитися в тому ж проєкті та зоні GCE, що і kubelet. Диск GCE може бути приєднаний тільки як для читання/запису один раз або тільки для читання багато разів. Диски GCE підтримують управління власниками та перепризначення міток SELinux.
gcePersistentDisk.pdName (string), обовʼязково
pdName — унікальне імʼя ресурсу PD в GCE. Використовується для ідентифікації диска в GCE.
gcePersistentDisk.fsType (string)
fsType — тип файлової системи тома, який ви хочете монтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.
gcePersistentDisk.partition (int32)
partition — розділ у томі, який ви хочете монтувати. Якщо пропущено,стандартно монтується за іменем тома. Приклади: Для тома /dev/sda1 ви вказуєте розділ як "1". Аналогічно, розділ тома для /dev/sda - "0" (або ви можете залишити властивість пустою).
gcePersistentDisk.readOnly (boolean)
readOnly — тут встановлює параметр readOnly у VolumeMounts. Стандартне значення — false.
Представляє монтування Glusterfs, яке існує протягом життєвого циклу Podʼа. Томи Glusterfs не підтримують управління власниками або перепризначенн міток SELinux.
endpointsNamespace — простір імен, який містить точку доступу Glusterfs. Якщо це поле порожнє, EndpointNamespace стандартно встановлюється в той же простір імен, що й звʼязаний PVC. Детальніше: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod
iscsi представляє ресурс ISCSI Disk, який приєднується до хост-машини kubelet і потім експонується для використання в Podʼі. Надається адміністратором.
ISCSIPersistentVolumeSource представляє диск ISCSI. ISCSI томи можуть бути монтувані тільки один раз для читання/запису. ISCSI томи підтримують управління власниками та перепризначення міток SELinux.
iscsi.iqn (string), обовʼязково
iqn - кваліфіковане імʼя ISCSI цілі.
iscsi.lun (int32), обовʼязково
lun — номер LUN цілі ISCSI.
iscsi.targetPortal (string), обовʼязково
targetPortal — це цільовий портал ISCSI. Портал може бути IP або ip_addr:port, якщо порт відрізняється від типового (зазвичай TCP порти 860 та 3260).
iscsi.chapAuthDiscovery (boolean)
chapAuthDiscovery — визначає підтримку автентифікації CHAP для виявлення ISCSI.
iscsi.chapAuthSession (boolean)
chapAuthSession - визначає підтримку автентифікації CHAP сесії ISCSI.
iscsi.fsType (string)
fsType — тип файлової системи тому, який ви хочете монтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Детальніше: https://kubernetes.io/docs/concepts/storage/volumes#iscsi
iscsi.initiatorName (string)
initiatorName — це спеціальне імʼя ініціатора ISCSI. Якщо initiatorName вказано одночасно з iscsiInterface, буде створено новий інтерфейс ISCSI <target portal>:<volume name> для зʼєднання.
iscsi.iscsiInterface (string)
iscsiInterface — це імʼя інтерфейсу, яке використовує транспорт ISCSI. Стандартне значення — 'default' (tcp).
iscsi.portals ([]string)
portals — список цільових порталів ISCSI. Портал може бути IP або ip_addr:port, якщо порт відрізняється від типового (зазвичай TCP порти 860 та 3260).
iscsi.readOnly (boolean)
readOnly — встановлює параметр readOnly у VolumeMounts. Стандартне значення — false.
iscsi.secretRef (SecretReference)
secretRef — це обʼєкт Secret для автентифікації цілі ISCSI та ініціатора.
SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.
iscsi.secretRef.name (string)
name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.
iscsi.secretRef.namespace (string)
namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.
photonPersistentDisk представляє постійний диск Photon Controller, приєднаний і змонтований на хост-машині kubelet
Представляє ресурс постійного диска Photon Controller.
photonPersistentDisk.pdID (string), обовʼязково
pdID — це ідентифікатор, який ідентифікує постійний диск Photon Controller.
photonPersistentDisk.fsType (string)
fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.
portworxVolume (PortworxVolumeSource)
portworxVolume представляє ресурс тома Portworx, приєднаний і змонтований на хост-машині kubelet
Представляє ресурс тома Portworx.
portworxVolume.volumeID (string), обовʼязково
volumeID — унікально ідентифікує том Portworx.
portworxVolume.fsType (string)
fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs". Передбачається "ext4", якщо не вказано інше.
portworxVolume.readOnly (boolean)
readOnly — стандартне значення — false (читання/запис). Якщо встановлено в true, тоді монтування тома буде тільки для читання.
quobyte (QuobyteVolumeSource)
quobyte представляє монтування Quobyte на хості, яке триває протягом життєвого циклу Podʼа.
Представляє монтування Quobyte, яке триває протягом життєвого циклу Podʼа. Quobyte томи не підтримують управління власниками або перевизначення міток SELinux.
quobyte.registry (string), обовʼязково
registry — представляє один або кілька сервісів реєстрації Quobyte, вказаних як рядок у форматі host:port (кілька записів розділяються комами), які діють як центральний реєстр для томів.
quobyte.volume (string), обовʼязково
volume — рядок, який посилається на вже створений том Quobyte за імʼям.
quobyte.group (string)
group — група для відображення доступу до тома. Стандартно група не встановлюється.
quobyte.readOnly (boolean)
readOnly — встановлює, чи має монтуватися том Quobyte тільки для читання. Стандартне значення — false.
quobyte.tenant (string)
tenant — власник вказаного тома Quobyte в Backend. Використовується з динамічно створеними томами Quobyte, значення встановлюється втулком.
quobyte.user (string)
user — користувач для відображення доступу до тома. Стандартно використовується користувач serivceaccount.
Представляє монтування Rados Block Device, яке існує протягом життєвого циклу Podʼа. RBD томи підтримують управління власниками та перевизначення міток SELinux.
fsType — тип файлової системи тому, який ви хочете змонтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Детальніше: https://kubernetes.io/docs/concepts/storage/volumes#rbd
scaleIO представляє постійний том ScaleIO, приєднаний і змонтований на вузлах Kubernetes.
ScaleIOPersistentVolumeSource представляє постійний том ScaleIO
scaleIO.gateway (string), обовʼязково
gateway — адреса хосту шлюза API ScaleIO.
scaleIO.secretRef (SecretReference), обовʼязково
secretRef — посилання на Secret для користувача ScaleIO та іншої чутливої інформації. Якщо це не надано, операція входу буде невдалою.
SecretReference представляє посилання на Secret. Воно містить достатньо інформації для отримання Secret в будь-якому просторі імен
scaleIO.secretRef.name (string)
name — унікальне імʼя ресурсу Secret в просторі імен.
scaleIO.secretRef.namespace (string)
namespace — визначає простір імен, в якому імʼя Secret повинно бути унікальним.
scaleIO.system (string), обовʼязково
system — назва системи зберігання, як налаштовано в ScaleIO.
scaleIO.fsType (string)
fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Стандартне значення — "xfs".
scaleIO.protectionDomain (string)
protectionDomain — назва домену захисту ScaleIO для налаштованого зберігання.
scaleIO.readOnly (boolean)
readOnly — стандартне значення — false (читання/запис). Якщо встановлено в true, тоді монтування тому буде тільки для читання.
scaleIO.sslEnabled (boolean)
sslEnabled — прапорець для увімкнення/вимкнення SSL-звʼязку з Gateway, стандартне значення — false.
scaleIO.storageMode (string)
storageMode — вказує, чи повинно бути зберігання для тому ThickProvisioned або ThinProvisioned. Стандартне значення — ThinProvisioned.
scaleIO.storagePool (string)
storagePool — Pool зберігання ScaleIO, повʼязаний з доменом захисту.
scaleIO.volumeName (string)
volumeName — імʼя вже створеного тому в системі ScaleIO, повʼязаного з цим джерелом тому.
fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.
storageos.readOnly (boolean)
readOnly — стандартне значення — false (читання/запис). Якщо встановлено в true, то монтування тому буде тільки для читання.
secretRef - вказує на Secret, який використовується для отримання облікових даних API StorageOS. Якщо не вказано, спробує використати стандартне значення.
storageos.volumeName (string)
volumeName — імʼя тому StorageOS, зорозуміле людині. Імена томів унікальні лише в межах простору імен.
storageos.volumeNamespace (string)
volumeNamespace — визначає область тому в межах StorageOS. Якщо не вказано, використовується простір імен Podʼа. Це дозволяє відображати простори імен Kubernetes в межах StorageOS для більш тісної інтеграції. Встановіть VolumeName на будь-яке імʼя для заміни стандартної поведінки. Встановіть у "default", якщо ви не використовуєте простори імен в межах StorageOS. Простори імен, які не існують заздалегідь в межах StorageOS, будуть створені.
vsphereVolume (VsphereVirtualDiskVolumeSource)
vsphereVolume представляє том vSphere, який приєднаний і змонтований на вузлах kubelet.
Представляє ресурс тому vSphere.
vsphereVolume.volumePath (string), обовʼязково
volumePath — шлях, який ідентифікує том vSphere vmdk.
vsphereVolume.fsType (string)
fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.
vsphereVolume.storagePolicyID (string)
storagePolicyID — ідентифікатор профілю управління політикою зберігання (SPBM), повʼязаний з іменем політики зберігання.
vsphereVolume.storagePolicyName (string)
storagePolicyName — імʼя профілю управління політикою зберігання (SPBM).
PersistentVolumeStatus
PersistentVolumeStatus — це поточний стан постійного тома.
lastPhaseTransitionTime (Time)
lastPhaseTransitionTime — це час, коли фаза переходила з однієї у іншу, і автоматично скидається до поточного часу кожного разу при переході фази тома. Це альфа-поле і вимагає умікнення функції PersistentVolumeLastPhaseTransitionTime.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
message (string)
message — повідомлення, зрозуміле людині, яке вказує деталі щодо причини, чому том знаходиться у цьому стані.
allowVolumeExpansion показує, чи дозволяє клас зберігання розширення тому.
allowedTopologies ([]TopologySelectorTerm)
Atomic: буде замінено під час обʼєднання
allowedTopologies обмежує топологію вузлів, де томи можуть динамічно виділятися. Кожен втулок тому визначає свої власні специфікації топології. Порожній список TopologySelectorTerm означає, що обмежень по топології немає. Це поле враховується лише серверами, які включають функцію VolumeScheduling.
Термін селектора топології представляє результат запитів до міток. Нульовий або порожній термін селектора топології не відповідає жодному обʼєкту. Вимоги до них обʼєднуються за принципом AND. Він надає підмножину функціональності як NodeSelectorTerm. Це альфа-версія функції та в майбутньому вона може змінитися.
Масив рядкових значень. Одне значення повинно відповідати мітці для вибору. Кожен запис у Values поєднується оператором OR.
mountOptions ([]string)
mountOptions контролює параметри монтування для динамічно виділених PersistentVolumes цього класу зберігання. Наприклад, ["ro", "soft"]. Не перевіряється — монтування PVs просто не вдасться, якщо один з них недійсний.
parameters (map[string]string)
parameters містить параметри для провайдера, який повинен створити томи цього класу зберігання.
reclaimPolicy (string)
reclaimPolicy контролює політику відновлення для динамічно виділених PersistentVolumes цього класу зберігання. Стандартне значення — Delete.
volumeBindingMode (string)
volumeBindingMode вказує, як PersistentVolumeClaims повинні виділятися та звʼязуватися. Якщо не встановлено, використовується VolumeBindingImmediate. Це поле враховується лише серверами, які включають функцію VolumeScheduling.
status представляє статус запиту VolumeAttachment. Заповнюється сутністю, що завершує операцію приєднання або відʼєднання, тобто external-attacher.
VolumeAttachmentSpec
VolumeAttachmentSpec — це специфікація запиту на приєднання тому.
attacher (string), обовʼязково
attacher вказує назву драйвера тому, який МАЄ обробити цей запит. Це назва, яку повертає GetPluginName().
nodeName (string), обовʼязково
nodeName представляє вузол, до якого повинен бути приєднаний том.
source (VolumeAttachmentSource), обовʼязково
source представляє том, який повинен бути приєднаний.
VolumeAttachmentSource представляє том, який повинен бути приєднаний. Зараз лише PersistenVolumes можуть бути приєднані за допомогою зовнішнього attacherʼa, у майбутньому ми можемо дозволити також inline томи в Podʼах. Може бути встановлений лише один елемент.
inlineVolumeSpec містить всю необхідну інформацію для приєднання persistent volume, визначеного VolumeSource Podʼа. Це поле заповнюється лише для функції CSIMigration. Воно містить перетворені поля з VolumeSource Podʼа до PersistentVolumeSpec. Це поле є на рівні beta і враховується лише серверами, які включили функцію CSIMigration.
source.persistentVolumeName (string)
persistentVolumeName представляє імʼя persistent volume для приєднання.
VolumeAttachmentStatus
VolumeAttachmentStatus — це статус запиту на приєднання тому.
attached (boolean), обовʼязково
attached вказує, що том успішно приєднаний. Це поле має бути встановлено лише сутністю, яка завершує операцію приєднання, тобто external-attacher.
attachError (VolumeError)
attachError представляє останню помилку, яка виникла під час операції приєднання, якщо така була. Це поле має бути встановлено лише сутністю, яка завершує операцію приєднання, тобто external-attacher.
VolumeError фіксує помилку, яка виникла під час операції з томом.
attachError.message (string)
message представляє помилку, яка виникла під час операції приєднання або відʼєднання. Цей рядок може бути доданий в лог, тож він не повинен містити конфіденційної інформації.
attachError.time (Time)
time представляє час, коли сталася помилка.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
attachmentMetadata (map[string]string)
attachmentMetadata заповнюється будь-якою інформацією, яка повертається під час успішної операції приєднання і яка повинна бути передана в наступні виклики WaitForAttach або Mount. Це поле має бути встановлено лише сутністю, яка завершує операцію приєднання, тобто external-attacher.
detachError (VolumeError)
detachError представляє останню помилку, яка виникла під час операції відʼєднання, якщо така була. Це поле має бути встановлено лише сутністю, яка завершує операцію відʼєднання, тобто external-attacher.
VolumeError фіксує помилку, яка виникла під час операції з томом.
detachError.message (string)
message представляє помилку, яка виникла під час операції приєднання або відʼєднання. Цей рядок може бути доданий в лог, тож він не повинен містити конфіденційної інформації.
detachError.time (Time)
time представляє час, коли сталася помилка.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
VolumeAttachmentList
VolumeAttachmentList — це колекція обʼєктів VolumeAttachment.
CSIDriver збирає інформацію про драйвер тома Container Storage Interface (CSI), розгорнутий в кластері.
apiVersion: storage.k8s.io/v1
import "k8s.io/api/storage/v1"
CSIDriver
CSIDriver збирає інформацію про драйвер тому Container Storage Interface (CSI), розгорнутий в кластері. Контролер приєднання та відʼєднання Kubernetes використовує цей обʼєкт для визначення необхідності приєднання. Kubelet використовує цей обʼєкт, щоб визначити, чи потрібно передавати інформацію про контейнер при монтуванні. Обʼєкти CSIDriver не має простору імен.
Стандартні метадані обʼєкта. metadata.Name вказує назву драйвера CSI, до якого відноситься цей обʼєкт; вона МАЄ бути такою ж, як імʼя, яке повертає виклик CSI GetPluginName() для цього драйвера. Назва драйвера повинна бути не більше 63 символів, починатися і закінчуватися алфавітно-цифровим символом ([a-z0-9A-Z]), з тире (-), крапками (.) та алфавітно-цифровими символами між ними. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
attachобовʼязково вказує, що цей драйвер томів CSI вимагає операцію приєднання (оскільки він реалізує метод CSI ControllerPublishVolume()), і що контролер приєднання та відʼєднання Kubernetes повинен викликати інтерфейс приєднання томів, який перевіряє статус VolumeAttachment і чекає, поки том буде приєднано, перед тим як перейти до монтування. Зовнішній attacher CSI координується з драйвером томів CSI та оновлює статус VolumeAttachment після завершення операції приєднання. Якщо увімкнено функцію CSIDriverRegistry і значення встановлено на false, операція приєднання буде пропущена. В іншому випадку операція приєднання буде викликана.
Це поле незмінне.
fsGroupPolicy (string)
fsGroupPolicy визначає, чи підтримує базовий том зміну власності та дозволів на том перед монтуванням. Додаткову інформацію дивіться у конкретних значеннях FSGroupPolicy.
Це поле незмінне.
Стандартне значення ReadWriteOnceWithFSType, що дозволяє перевірити кожен том, щоб визначити, чи повинен Kubernetes змінювати власність і дозволи на том. Зі стандартною політикою визначена fsGroup буде застосована лише, якщо визначено fstype і режим доступу тому містить ReadWriteOnce.
podInfoOnMount (boolean)
podInfoOnMount вказує, що цей драйвер томів CSI вимагає додаткову інформацію про Pod (наприклад, podName, podUID тощо) під час операцій монтування, якщо встановлено true. Якщо встановлено false, інформація про Pod не буде передаватися під час монтування. Стандартне значення — false.
Драйвер CSI визначає podInfoOnMount як частину розгортання драйвера. Якщо true, Kubelet передаватиме інформацію про Pod як VolumeContext у викликах CSI NodePublishVolume(). Драйвер CSI відповідає за розбір та перевірку інформації, переданої як VolumeContext.
Наступний VolumeContext буде передано, якщо podInfoOnMount встановлено в true. Цей список може розширюватися, але буде використовуватися префікс. "csi.storage.k8s.io/pod.name": pod.Name "csi.storage.k8s.io/pod.namespace": pod.Namespace "csi.storage.k8s.io/pod.uid": string(pod.UID) "csi.storage.k8s.io/ephemeral": "true", якщо том є ефемерним інлайн-томом, визначеним CSIVolumeSource, в іншому випадку "false"
"csi.storage.k8s.io/ephemeral" — це нова функція в Kubernetes 1.16. Вона потрібна лише для драйверів, які підтримують як "Persistent", так і "Ephemeral" VolumeLifecycleMode. Інші драйвери можуть залишити інформацію про Podʼи вимкненою та/або ігнорувати це поле. Оскільки Kubernetes 1.15 не підтримує це поле, драйвери можуть підтримувати лише один режим під час розгортання на такому кластері, і Deployment визначає, який режим це буде, наприклад, через параметр командного рядка драйвера.
Це поле незмінне.
requiresRepublish (boolean)
requiresRepublish вказує, що драйвер CSI хоче, щоб NodePublishVolume періодично викликали, щоб відобразити будь-які можливі зміни у змонтованому томі. Стандартне значення цього поля — false.
Примітка: після успішного початкового виклику NodePublishVolume наступні виклики NodePublishVolume повинні лише оновлювати вміст тому. Нові точки монтування не будуть видимі для запущеного контейнера.
seLinuxMount (boolean)
seLinuxMount визначає, чи підтримує драйвер CSI опцію монтування "-o context".
Коли "true", драйвер CSI повинен забезпечити, щоб усі томи, надані цим драйвером CSI, могли монтуватися окремо з різними параметрами -o context. Це типово для сховищ, які надають томи як файлові системи на блокових пристроях або як незалежні загальні томи. Kubernetes викликатиме NodeStage / NodePublish з параметром монтування "-o context=xyz" при монтуванні тому ReadWriteOncePod, який використовується в Pod, що явно встановив контекст SELinux. У майбутньому це може бути розширено до інших режимів доступу до томів. У будь-якому випадку Kubernetes забезпечить, щоб том монтувався лише з одним контекстом SELinux.
Коли "false", Kubernetes не передаватиме жодних спеціальних параметрів монтування SELinux драйверу. Це типово для томів, які представляють підтеки більшої спільної файлової системи.
Стандартне значення — "false".
storageCapacity (boolean)
storageCapacity вказує, що драйвер томів CSI хоче, щоб планування Podʼів враховувало обсяг сховища, який буде повідомлено під час розгортання драйвера шляхом створення обʼєктів CSIStorageCapacity з інформацією про місткість, якщо встановлено true.
Перевірку можна ввімкнути відразу під час розгортання драйвера. У цьому випадку створення нових томів з відкладеним привʼязуванням зупиниться, доки Deployment драйвера не опублікує деякий відповідний обʼєкт CSIStorageCapacity.
Альтернативно, драйвер можна розгорнути з невстановленим або false полем, і його можна змінити пізніше, коли буде опубліковано інформацію про місткість сховища.
Це поле було незмінним у Kubernetes <= 1.22 і тепер воно є змінним.
tokenRequests ([]TokenRequest)
Atomic: буде замінено під час злиття
tokenRequests вказує, що драйвер CSI потребує токенів службових облікових записів Podʼів, для яких він монтує том, для необхідної автентифікації. Kubelet передасть токени у VolumeContext у викликах CSI NodePublishVolume. Драйвер CSI повинен розбирати та перевіряти наступний VolumeContext:
Примітка: Аудиторія в кожному запиті токена повинна бути різною, і не більше одного токена має бути пустим рядком. Для отримання нового токена після закінчення терміну дії можна використовувати RequiresRepublish для періодичного виклику NodePublishVolume.
TokenRequest містить параметри токена службового облікового запису.
tokenRequests.audience (string), обовʼязково
audience — це призначена аудиторія токена в "TokenRequestSpec". Стандартно це аудиторії kube apiserver.
tokenRequests.expirationSeconds (int64)
expirationSeconds — це тривалість дії токена в "TokenRequestSpec". Має таке ж стандартне значення, як "ExpirationSeconds" у "TokenRequestSpec".
volumeLifecycleModes ([]string)
Set: унікальні значення будуть збережені під час злиття
volumeLifecycleModes визначає, які типи томів підтримує цей драйвер томів CSI. Стандартно, якщо список порожній, це "Persistent", що визначено специфікацією CSI та реалізовано в Kubernetes через звичайний механізм PV/PVC.
Інший режим — "Ephemeral". У цьому режимі томи визначаються інлайн у специфікації Podʼа за допомогою CSIVolumeSource, і їх життєвий цикл повʼязаний з життєвим циклом цього Podʼа. Драйвер повинен бути обізнаний про це, оскільки він отримає лише виклик NodePublishVolume для такого тому.
CSINode містить інформацію про всі драйвери CSI, встановлені на вузлі.
apiVersion: storage.k8s.io/v1
import "k8s.io/api/storage/v1"
CSINode
CSINode містить інформацію про всі драйвери CSI, встановлені на вузлі. Драйверам CSI не потрібно створювати обʼєкт CSINode безпосередньо. Якщо вони використовують sidecar контейнер node-driver-registrar, kubelet автоматично заповнить обʼєкт CSINode для драйвера CSI під час реєстрації втулка kubelet. CSINode має ту ж назву, що і вузол. Якщо обʼєкт відсутній, це означає, що або на вузлі немає доступних драйверів CSI, або версія Kubelet є достатньо низькою, щоб не створювати цей обʼєкт. CSINode має OwnerReference, яке вказує на відповідний обʼєкт вузла.
CSINodeSpec містить інформацію про специфікації всіх драйверів CSI, встановлених на вузлі.
drivers ([]CSINodeDriver), обовʼязково
Patch strategy: злиття за ключем name
drivers — це список інформації про всі драйвери CSI, які існують на вузлі. Якщо всі драйвери в списку видалено, цей список може бути порожнім.
CSINodeDriver містить інформацію про специфікацію одного драйвера CSI, встановленого на вузлі
drivers.name (string), обовʼязково
name представляє імʼя драйвера CSI, до якого відноситься цей обʼєкт. Це МАЄ бути те саме імʼя, яке повертає виклик CSI GetPluginName() для цього драйвера.
drivers.nodeID (string), обовʼязково
nodeID вузла з погляду драйвера. Це поле дозволяє Kubernetes взаємодіяти з системами зберігання, які не використовують ту ж номенклатуру для вузлів. Наприклад, Kubernetes може називати вузол "node1", але система зберігання може називати той самий вузол "nodeA". Коли Kubernetes видає команду системі зберігання для приєднання тому до конкретного вузла, він може використовувати це поле для посилання на імʼя вузла за допомогою ID, який зрозуміє система зберігання, наприклад "nodeA" замість "node1". Це поле обовʼязкове.
drivers.allocatable (VolumeNodeResources)
allocatable представляє ресурс тому вузла, доступний для планування. Це поле є бета-версією.
VolumeNodeResources — це набір обмежень ресурсів для планування томів.
drivers.allocatable.count (int32)
count вказує максимальну кількість унікальних томів, що керуються драйвером CSI, які можна використовувати на вузлі. Том, який одночасно приєднаний і змонтований на вузлі, вважається використаним один раз, а не двічі. Те саме правило застосовується до унікального тому, який розділяється між кількома Podʼами на одному вузлі. Якщо це поле не вказано, то кількість підтримуваних томів на цьому вузлі не обмежена.
drivers.topologyKeys ([]string)
topologyKeys — це список ключів, підтримуваних драйвером. Коли драйвер ініціалізується в кластері, він надає набір ключів топології, які він розуміє (наприклад, "company.com/zone", "company.com/region"). Коли драйвер ініціалізується на вузлі, він надає ті самі ключі топології разом зі значеннями. Kubelet відображатиме ці ключі топології як мітки на своєму власному обʼєкті вузла. Коли Kubernetes виконує планування з урахуванням топології, він може використовувати цей список для визначення, які мітки він повинен отримати з обʼєкта вузла та передати назад драйверу. Для різних вузлів можуть використовуватися різні ключі топології. Це поле може бути порожнім, якщо драйвер не підтримує топологію.
CSIStorageCapacity зберігає результат одного виклику CSI GetCapacity.
apiVersion: storage.k8s.io/v1
import "k8s.io/api/storage/v1"
CSIStorageCapacity
CSIStorageCapacity зберігає результат одного виклику CSI GetCapacity. Для заданого StorageClass це описує доступну місткість у певному сегменті топології. Це можна використовувати під час розгляду місця для створення нових PersistentVolumes.
Наприклад, це може виражати такі речі:
StorageClass "standard" має "1234 GiB" доступних у "topology.kubernetes.io/zone=us-east1"
StorageClass "localssd" має "10 GiB" доступних у "kubernetes.io/hostname=knode-abc123"
Наступні три випадки означають, що місткість недоступна для певної комбінації:
не існує обʼєкта з відповідною топологією та імʼям класу зберігання
такий обʼєкт існує, але місткість не задана
такий обʼєкт існує, але місткість дорівнює нулю
Виробник цих обʼєктів може вирішити, який підхід є більш відповідним.
Вони споживаються планувальником kube-scheduler, коли драйвер CSI вибирає планування з урахуванням місткості за допомогою CSIDriverSpec.StorageCapacity. Планувальник порівнює MaximumVolumeSize із запитаним розміром очікуваних томів, щоб відфільтрувати невідповідні вузли. Якщо MaximumVolumeSize не задано, він повертається до порівняння з менш точною Capacity. Якщо і це не задано, планувальник припускає, що місткість недостатня, і пробує інший вузол.
Стандартні метадані обʼєкта. Імʼя не має особливого значення. Воно повинно бути піддоменом DNS (допускаються точки, 253 символи). Щоб уникнути конфліктів з іншими драйверами CSI у кластері, рекомендується використовувати csisc-<uuid>, згенероване імʼя або імʼя у зворотному порядку домену, яке закінчується унікальним імʼям драйвера CSI.
storageClassName представляє імʼя StorageClass, до якого відноситься звітна місткість. Воно повинно відповідати тим самим вимогам, що й імʼя обʼєкта StorageClass (не порожнє, піддомен DNS). Якщо цей обʼєкт більше не існує, обʼєкт CSIStorageCapacity застарів і повинен бути видалений його творцем. Це поле незмінне.
capacity — це значення, яке повідомляє драйвер CSI у своєму GetCapacityResponse для GetCapacityRequest з топологією і параметрами, що відповідають попереднім полям.
Семантика наразі (CSI spec 1.2) визначена як: доступна місткість у байтах сховища, яка може бути використана для створення томів. Якщо не задано, ця інформація наразі недоступна.
maximumVolumeSize — це значення, яке повідомляє драйвер CSI у своєму GetCapacityResponse для GetCapacityRequest з топологією і параметрами, що відповідають попереднім полям.
Це визначено починаючи з CSI spec 1.4.0 як найбільший розмір, який може бути використаний у полі CreateVolumeRequest.capacity_range.обовʼязково_bytes для створення тому з тими самими параметрами, що й у GetCapacityRequest. Відповідне значення в API Kubernetes — це ResourceRequirements.Requests у запиті на том.
nodeTopology визначає, які вузли мають доступ до сховища, для якого була надана місткість. Якщо не задано, сховище недоступне з жодного вузла у кластері. Якщо порожнє, сховище доступне з усіх вузлів. Це поле незмінне.
CSIStorageCapacityList
CSIStorageCapacityList — це колекція обʼєктів CSIStorageCapacity.
automountServiceAccountToken вказує, чи повинні Podʼи, які працюють від імені цього службового облікового запису, автоматично мати змонтований API токен. Може бути перевизначено на рівні Podʼа.
imagePullSecrets — це список посилань на Sercretʼи в тому ж просторі імен для використання при завантаженні будь-яких образів у Podʼах, які використовують цей службовий обліковий запис. ImagePullSecrets відрізняються від Secrets тим, що Secrets можуть бути змонтовані в Pod, а ImagePullSecrets доступні лише для kubelet. Докладніше: https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod
secrets — це список секретів у тому ж просторі імен, які Podʼи, що використовують цей службовий обліковий запис, можуть використовувати. Podʼи обмежуються цим списком лише у випадку, якщо цей службовий обліковий запис має анотацію "kubernetes.io/enforce-mountable-secrets" зі значенням "true". Це поле не слід використовувати для пошуку автоматично створених секретів токенів службових облікових записів для використання поза межами Podʼів. Натомість токени можна запитувати безпосередньо за допомогою API TokenRequest або секрети токенів службових облікових записів можна створювати вручну. Докладніше: https://kubernetes.io/docs/concepts/configuration/secret
ServiceAccountList
ServiceAccountList — це список обʼєктів ServiceAccount.
Status заповнюється сервером і вказує, чи може токен бути автентифікований.
TokenRequestSpec
TokenRequestSpec містить параметри запиту токена, надані клієнтом.
audiences ([]string), обовʼязково
Audiences — це цільові аудиторії токена. Отримувач токена повинен ідентифікувати себе за допомогою ідентифікатора зі списку аудиторій токена, інакше він повинен відхилити токен. Токен, виданий для кількох аудиторій, може бути використаний для автентифікації з будь-якою з вказаних аудиторій, що передбачає високий ступінь довіри між цільовими аудиторіями.
boundObjectRef (BoundObjectReference)
BoundObjectRef — це посилання на обʼєкт, до якого буде привʼязано токен. Токен буде дійсний лише до тих пір, поки існує привʼязаний обʼєкт. ПРИМІТКА: Точка доступу TokenReview сервера API перевірить BoundObjectRef, але інші аудиторії можуть цього не робити. Тримайте ExpirationSeconds маленьким, якщо ви хочете швидке відкликання.
BoundObjectReference — це посилання на обʼєкт, до якого привʼязано токен.
boundObjectRef.apiVersion (string)
Версія API посилання.
boundObjectRef.kind (string)
Тип посилання. Дійсними типами є 'Pod' та 'Secret'.
boundObjectRef.name (string)
Імʼя посилання.
boundObjectRef.uid (string)
UID посилання.
expirationSeconds (int64)
ExpirationSeconds — це запитувана тривалість дії запиту. Видавець токенів може повернути токен з іншою тривалістю дії, тому клієнт повинен перевірити поле 'expiration' у відповіді.
TokenRequestStatus
TokenRequestStatus — це результат запиту на отримання токена.
expirationTimestamp (Time), обовʼязково
ExpirationTimestamp — це час закінчення дії виданого токена.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
token (string), обовʼязково
Token — це непрозорий токен на предʼявника.
Операції
create створення токена ServiceAccount
HTTP запит
POST /api/v1/namespaces/{namespace}/serviceaccounts/{name}/token
TokenReview намагається автентифікувати токен вже відомому користувачу.
apiVersion: authentication.k8s.io/v1
import "k8s.io/api/authentication/v1"
TokenReview
TokenReview намагається автентифікувати токен вже відомому користувачу. Примітка: запити TokenReview можуть кешуватися dnekrjv автентифікації вебхука в kube-apiserver.
Status заповнюється сервером і вказує, чи можна автентифікувати запит.
TokenReviewSpec
TokenReviewSpec є описом запиту автентифікації токена.
audiences ([]string)
Audiences — це список ідентифікаторів, які сервер ресурсів, представлений токеном, розпізнає як. Автентифікатори токенів, що володіють інформацією про аудиторію, перевірять, що токен був призначений принаймні для однієї з аудиторій у цьому списку. Якщо аудиторії не надані, типово використовується аудиторія Kubernetes apiserver.
token (string)
Token — це непрозорий токен на предʼявника.
TokenReviewStatus
TokenReviewStatus — це результат запиту автентифікації токена.
audiences ([]string)
Audiences — це ідентифікатори аудиторії, обрані автентифікатором, які сумісні як з TokenReview, так і з токеном. Ідентифікатор є будь-яким ідентифікатором у перетині аудиторій TokenReviewSpec та аудиторій токена. Клієнт TokenReview API, який встановлює поле spec.audiences, повинен перевірити, що сумісний ідентифікатор аудиторії повертається в полі status.audiences, щоб переконатися, що сервер TokenReview враховує аудиторію. Якщо TokenReview повертає порожнє поле status.audience, де status.authenticated є "true", токен дійсний для аудиторії Kubernetes API server.
authenticated (boolean)
Authenticated вказує, що токен був повʼязаний з відомим користувачем.
error (string)
Error вказує, що токен не вдалося перевірити
user (UserInfo)
User — це UserInfo, повʼязаний із наданим токеном.
UserInfo містить інформацію про користувача, необхідну для реалізації інтерфейсу user.Info.
Унікальне значення, яке ідентифікує цього користувача з плином часу. Якщо цього користувача видаляють і додають іншого користувача з тим же імʼям, вони матимуть різні UID.
user.username (string)
Імʼя, яке унікально ідентифікує цього користувача серед усіх активних користувачів.
Обʼєкти CertificateSigningRequest надають механізм для отримання сертифікатів x509 шляхом подання запиту на підписання сертифіката та його асинхронного схвалення і видачі.
apiVersion: certificates.k8s.io/v1
import "k8s.io/api/certificates/v1"
CertificateSigningRequest
Обʼєкти CertificateSigningRequest надають механізм для отримання сертифікатів x509 шляхом подання запиту на підписання сертифіката та його асинхронного схвалення і видачі.
Kubelets використовують цей API для отримання:
клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client-kubelet").
серверних сертифікатів для TLS-точок доступу, до яких kube-apiserver може підключатися безпечно (з використанням signerName "kubernetes.io/kubelet-serving").
Цей API може бути використаний для запиту клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client") або для отримання сертифікатів від нестандартних підписувачів, що не належать до Kubernetes.
spec містить запит на сертифікат і є незмінним після створення. Тільки поля request, signerName, expirationSeconds та usages можуть бути встановлені під час створення. Інші поля визначаються Kubernetes і не можуть бути змінені користувачами.
status містить інформацію про те, чи запит схвалено або відхилено, а також сертифікат, виданий підписувачем, або умови збою, які вказують на збій підписувача.
CertificateSigningRequestSpec
CertificateSigningRequestSpec містить запит на сертифікат.
request ([]byte), обовʼязково
Atomic: буде замінено під час злиття
request містить x509 запит на підписання сертифіката, закодований у блоці PEM "CERTIFICATE REQUEST". При серіалізації у форматі JSON або YAML дані додатково кодуються в base64.
signerName (string), обовʼязково
signerName вказує на запитуваного підписувача і є кваліфікованим імʼям.
Запити List/watch для CertificateSigningRequests можуть фільтруватися за цим полем з використанням fieldSelector "spec.signerName=NAME".
Добре відомі підписувачі Kubernetes:
"kubernetes.io/kube-apiserver-client": видає клієнтські сертифікати, які можна використовувати для автентифікації до kube-apiserver. Запити для цього підписувача ніколи не затверджуються автоматично kube-controller-manager, можуть бути видані контролером "csrsigning" у kube-controller-manager.
"kubernetes.io/kube-apiserver-client-kubelet": видає клієнтські сертифікати, які kubelets використовують для автентифікації до kube-apiserver. Запити для цього підписувача можуть бути автоматично затверджені контролером "csrapproving" у kube-controller-manager і можуть бути видані контролером "csrsigning" у kube-controller-manager.
"kubernetes.io/kubelet-serving": видає серверні сертифікати, які kubelets використовують для обслуговування TLS-точок доступу, до яких kube-apiserver може підключатися безпечно. Запити для цього підписувача ніколи не затверджуються автоматично kube-controller-manager і можуть бути видані контролером "csrsigning" у kube-controller-manager.
Можуть також бути вказані нестандартні signerNames. Підписувач визначає:
Розповсюдження довіри: як розповсюджуються довірчі пакети (CA bundles).
Дозволені субʼєкти: та поведінка, коли запитується недозволений субʼєкт.
Обовʼязкові, дозволені або заборонені розширення x509 у запиті (включаючи те, чи дозволені subjectAltNames, які типи, обмеження на дозволені значення) та поведінка при запиті недозволеного розширення.
Обовʼязкові, дозволені або заборонені ключові використання / розширені ключові використання.
Термін дії сертифіката: чи він фіксований підписувачем, налаштовується адміністратором.
Чи дозволені запити на сертифікати CA.
expirationSeconds (int32)
expirationSeconds — це запитувана тривалість дії виданого сертифіката. Підписувач сертифіката може видати сертифікат з іншою тривалістю дії, тому клієнт повинен перевірити різницю між полями notBefore і notAfter у виданому сертифікаті, щоб визначити фактичну тривалість.
Реалізації v1.22+ вбудованих підписувачів Kubernetes дотримуватимуться цього поля, якщо запитувана тривалість не перевищує максимальну тривалість, яку вони дозволяють відповідно до прапорця CLI --cluster-signing-duration для контролера Kubernetes.
Підписувачі сертифікатів можуть не дотримуватися цього поля з різних причин:
Старий підписувач, який не знає про це поле (наприклад, вбудовані реалізації до v1.22)
Підписувач, чия налаштована максимальна тривалість коротша за запитувану тривалість
Підписувач, чия налаштована мінімальна тривалість довша за запитувану тривалість
Мінімальне дійсне значення для expirationSeconds — 600, тобто 10 хвилин.
extra (map[string][]string)
extra містить додаткові атрибути користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.
groups ([]string)
Atomic: буде замінено під час злиття
groups містить членство в групах користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.
uid (string)
uid містить uid користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.
usages ([]string)
Atomic: буде замінено під час злиття
usages вказує набір запитуваних використань ключів у виданому сертифікаті.
Запити на TLS клієнтські сертифікати зазвичай запитують: "digital signature", "key encipherment", "client auth".
Запити на TLS серверні сертифікати зазвичай запитують: "key encipherment", "digital signature", "server auth".
username містить імʼя користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.
CertificateSigningRequestStatus
CertificateSigningRequestStatus містить умови, що використовуються для позначення статусу запиту (схвалено/відхилено/не вдалося), та виданий сертифікат.
certificate ([]byte)
Atomic: буде замінено під час злиття
certificate заповнюється виданим сертифікатом підписувача після наявності умови "Approved". Це поле встановлюється через субресурс /status. Після заповнення це поле є незмінним.
Якщо запит на підписання сертифіката відхилено, додається умова типу "Denied", і це поле залишається порожнім. Якщо підписувач не може видати сертифікат, додається умова типу "Failed", і це поле залишається порожнім.
Вимоги до валідації:
certificate повинно містити один або більше PEM блоків.
Усі PEM блоки повинні мати мітку "CERTIFICATE", не містити заголовків, а закодовані дані повинні бути структурою сертифіката BER-кодованого ASN.1, як описано в розділі 4 RFC5280.
Не-PEM вміст може зʼявлятися до або після блоків PEM "CERTIFICATE" і не перевіряється, щоб дозволити пояснювальний текст, як описано в розділі 5.2 RFC7468.
Якщо в наявності більше одного блоку PEM, і визначення запитуваного spec.signerName не вказує інше, перший блок є виданим сертифікатом, а наступні блоки слід розглядати як проміжні сертифікати та представлятись під час TLS-handshake.
Сертифікат закодований у форматі PEM.
При серіалізації у форматі JSON або YAML дані додатково кодуються в base64, тому вони складаються з:
Map: унікальні значення за ключем типу зберігатимуться під час злиття
conditions, застосовані до запиту. Відомі стани: "Approved", "Denied" та "Failed".
CertificateSigningRequestCondition описує стан обʼєкта CertificateSigningRequest
conditions.status (string), обовʼязково
статус стану, одне з True, False, Unknown. Стани "Approved", "Denied" та "Failed" не можуть бути "False" або "Unknown".
conditions.type (string), обовʼязково
тип стану. Відомі стани: "Approved", "Denied" та "Failed".
Стан "Approved" додається через субресурс /approval, що вказує на те, що запит було схвалено і сертифікат повинен бути виданий підписувачем.
Стан "Denied" додається через субресурс /approval, що вказує на те, що запит було відхилено і сертифікат не повинен бути виданий підписувачем.
Стан "Failed" додається через субресурс /status, що вказує на те, що підписувачу не вдалося видати сертифікат.
Стан "Approved" та "Denied" є взаємозаперечними. Стани "Approved", "Denied" та "Failed" не можуть бути видалені після додавання.
Дозволено лише один стан певного типу.
conditions.lastTransitionTime (Time)
lastTransitionTime - це час останньої зміни стану з одного статусу до іншого. Якщо не встановлено, коли додається новий тип стану або змінюється статус поточного стану, сервер стандартно встановлює цей час на поточний.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.lastUpdateTime (Time)
lastUpdateTime — це час останнього оновлення цього стану.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string)
message містить зрозуміле для людини повідомлення з деталями про стан запиту.
conditions.reason (string)
reason вказує коротку причину стану запиту.
CertificateSigningRequestList
CertificateSigningRequestList — це колекція обʼєктів CertificateSigningRequest.
ClusterTrustBundle — це кластерний контейнер для X.
apiVersion: certificates.k8s.io/v1alpha1
import "k8s.io/api/certificates/v1alpha1"
ClusterTrustBundle
ClusterTrustBundle — це кластерний контейнер для довірчих якорів X.509 (кореневих сертифікатів).
Обʼєкти ClusterTrustBundle вважаються доступними для читання будь-яким автентифікованим користувачем у кластері, оскільки їх можна монтувати в Pod за допомогою проєкції clusterTrustBundle. Усі службові облікові записи типово мають доступ на читання ClusterTrustBundles. Користувачі, які мають доступ лише на рівні простору імен у кластері, можуть читати ClusterTrustBundles, використовуючи serviceaccount, до якого вони мають доступ.
Він може бути опціонально повʼязаний з певним підписувачем, у такому випадку він містить один дійсний набір довірчих якорів для цього підписувача. Підписувачі можуть мати кілька повʼязаних ClusterTrustBundles; кожен з них є незалежним набором довірчих якорів для цього підписувача. Контроль доступу використовується для забезпечення того, що лише користувачі з правами підписувача можуть створювати або змінювати відповідний набір.
spec містить підписувача (якщо є) та довірчі якорі.
ClusterTrustBundleSpec
ClusterTrustBundleSpec містить інформацію про підписувача та довірчі якорі.
trustBundle (string), обовʼязково
trustBundle містить окремі довірчі якорі X.509 для цього набору, у вигляді PEM-пакета PEM-обгорток, DER-форматованих сертифікатів X.509.
Дані повинні складатися лише з PEM-блоків сертифікатів, які розпізнаються як дійсні сертифікати X.509. Кожен сертифікат повинен містити розширення базових обмежень з встановленою позначкою CA. Сервер API відхилить обʼєкти, що містять дублюючі сертифікати або використовують заголовки блоків PEM.
Користувачі ClusterTrustBundle, включаючи Kubelet, вільні переупорядковувати та видаляти дублікати блоків сертифікатів у цьому файлі за власною логікою, а також видаляти заголовки блоків PEM та міжблокові дані.
signerName (string)
signerName вказує повʼязаного підписувача, якщо такий є.
Щоб створити або оновити ClusterTrustBundle з встановленим signerName, вам потрібно мати наступні дозволи на рівні кластера: group=certificates.k8s.io resource=signers resourceName=<імʼя підписувача> verb=attest.
Якщо signerName не порожній, тоді обʼєкт ClusterTrustBundle повинен мати імʼя, що починається з імені підписувача як префікс (перекладаючи косі на двокрапки). Наприклад, для імені підписувача example.com/foo, допустимі імена обʼєктів ClusterTrustBundle включають example.com:foo:abc та example.com:foo:v1.
Якщо signerName порожній, тоді імʼя обʼєкта ClusterTrustBundle не повинно мати такого префікса.
Запити на список/перегляд ClusterTrustBundle можуть фільтрувати за цим полем, використовуючи селектор поля spec.signerName=NAME.
ClusterTrustBundleList
ClusterTrustBundleList — це колекція обʼєктів ClusterTrustBundle.
SelfSubjectReview містить інформацію про користувача, яку має kube-apiserver про користувача, що робить цей запит.
apiVersion: authentication.k8s.io/v1
import "k8s.io/api/authentication/v1"
SelfSubjectReview
SelfSubjectReview містить інформацію про користувача, яку має kube-apiserver про користувача, що робить цей запит. При використанні імперсоніфікації, користувачі отримають інформацію про користувача, якого вони імітують. Якщо використовується імперсоніфікація або автентифікація заголовка запиту, будь-які додаткові ключі будуть ігноруватися і повертатися у нижньому регістрі.
Унікальне значення, що ідентифікує цього користувача з плином часу. Якщо цей користувач буде видалений і інший користувач з таким самим іменем буде доданий, вони матимуть різні UID.
userInfo.username (string)
Імʼя, яке унікально ідентифікує цього користувача серед усіх активних користувачів.
Операції
create створення SelfSubjectReview
HTTP запит
POST /apis/authentication.k8s.io/v1/selfsubjectreviews
LocalSubjectAccessReview перевіряє, чи може користувач або група виконати дію в заданому просторі імен.
apiVersion: authorization.k8s.io/v1
import "k8s.io/api/authorization/v1"
LocalSubjectAccessReview
LocalSubjectAccessReview перевіряє, чи може користувач або група виконати дію в заданому просторі імен. Наявність ресурсу, обмеженого простором імен, значно полегшує надання політики, обмеженої простором імен, що включає перевірку дозволів.
Специфікація містить інформацію про запит, який оцінюється. spec.namespace повинен дорівнювати простору імен, щодо якого зроблено запит. Якщо поле порожнє, встановлюється стандартне значення.
SelfSubjectAccessReview перевіряє, чи може поточний користувач виконати дію.
apiVersion: authorization.k8s.io/v1
import "k8s.io/api/authorization/v1"
SelfSubjectAccessReview
SelfSubjectAccessReview перевіряє, чи може поточний користувач виконати дію. Незаповнення spec.namespace означає "в усіх просторах імен". Self є особливим випадком, оскільки користувачі завжди повинні мати змогу перевірити, чи можуть вони виконати дію.
Статус заповнюється сервером і вказує, чи дозволено запит, чи ні.
SelfSubjectAccessReviewSpec
SelfSubjectAccessReviewSpec є описом запиту на доступ. Має бути встановлене щось одне з ResourceAuthorizationAttributes або NonResourceAuthorizationAttributes.
nonResourceAttributes (NonResourceAttributes)
NonResourceAttributes описує інформацію для запиту на доступ до не-ресурсів.
NonResourceAttributes включає атрибути авторизації, доступні для запитів до інтерфейсу Authorizer, які не стосуються ресурсів.
nonResourceAttributes.path (string)
Path — це URL-шлях запиту.
nonResourceAttributes.verb (string)
Verb — це стандартне HTTP-дієслово.
resourceAttributes (ResourceAttributes)
ResourceAuthorizationAttributes описує інформацію для запиту на доступ до ресурсу.
ResourceAttributes включає атрибути авторизації, доступні для запитів до інтерфейсу Authorizer, що стосуються ресурсів.
resourceAttributes.group (string)
Group — це API-група ресурсу. "*" означає всі.
resourceAttributes.name (string)
Name — це назва ресурсу, який запитується для "отримання" ("get") або видалення для "delete". "" (порожня) означає всі.
resourceAttributes.namespace (string)
Namespace — це простір імен дії, що запитується. Наразі немає різниці між відсутністю простору імен та всіма просторами імен "" (порожньо) стандартно встановлюється з для LocalSubjectAccessReviews "" (порожньо) означає відсутність для кластерних ресурсів "" (порожньо) означає "всі" для ресурсів, обмежених простором імен, з SubjectAccessReview або SelfSubjectAccessReview.
resourceAttributes.resource (string)
Resource — це один з наявних типів ресурсів. "*" означає всі.
resourceAttributes.subresource (string)
Subresource — це один з наявних типів субресурсів. "" означає відсутність.
resourceAttributes.verb (string)
Verb — це дієслово API ресурсу Kubernetes, таке як: get, list, watch, create, update, delete, proxy. "*" означає всі.
resourceAttributes.version (string)
Version — це версія API ресурсу. "*" означає всі.
Операції
create створення SelfSubjectAccessReview
HTTP запит
POST /apis/authorization.k8s.io/v1/selfsubjectaccessreviews
SelfSubjectRulesReview перелічує набір дій, які поточний користувач може виконувати в межах простору імен.
apiVersion: authorization.k8s.io/v1
import "k8s.io/api/authorization/v1"
SelfSubjectRulesReview
SelfSubjectRulesReview перелічує набір дій, які поточний користувач може виконувати в межах простору імен. Отриманий список дій може бути неповним залежно від режиму авторизації сервера та будь-яких помилок, які виникли під час оцінки. SelfSubjectRulesReview слід використовувати інтерфейсами користувача для показу/приховування дій або швидкого надання кінцевому користувачеві можливості оцінити свої дозволи. Він НЕ ПОВИНЕН використовуватися зовнішніми системами для прийняття рішень щодо авторизації, оскільки це викликає проблеми з підміною, тривалістю життя кешу/відкликанням та правильністю. SubjectAccessReview і LocalAccessReview є правильним способом делегування рішень щодо авторизації до API сервера.
Специфікація містить інформацію про запит, який оцінюється.
status (SubjectRulesReviewStatus)
Статус заповнюється сервером і вказує на набір дій, які користувач може виконувати.
SubjectRulesReviewStatus містить результат перевірки правил. Ця перевірка може бути неповною залежно від набору авторизаторів, з якими налаштовано сервер, і будь-яких помилок, що виникли під час оцінки. Оскільки правила авторизації є адитивними, якщо правило зʼявляється у списку, можна безпечно припустити, що субʼєкт має цей дозвіл, навіть якщо цей список неповний.
status.incomplete (boolean), обовʼязково
Incomplete встановлюється у true, коли правила, повернуті цим викликом, є неповними. Це найчастіше зустрічається, коли авторизатор, такий як зовнішній авторизатор, не підтримує оцінку правил.
NonResourceRules — це список дій, які субʼєкт має право виконувати щодо не-ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.
NonResourceRule містить інформацію, яка описує правило для не-ресурсу
NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. * допускаються, але лише як повний, кінцевий крок у шляху. "*" означає всі.
ResourceRules — це список дій, які субʼєкт має право виконувати щодо ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.
ResourceRule — це список дій, які субʼєкт має право виконувати щодо ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.
Verb — це список дієслів API ресурсу Kubernetes, таких як: get, list, watch, create, update, delete, proxy. "*" означає всі.
status.resourceRules.apiGroups ([]string)
APIGroups — це назва API-групи, яка містить ресурси. Якщо зазначено кілька API-груп, будь-яка дія, запитана для одного з перелічених ресурсів у будь-якій API-групі, буде дозволена. "*" означає всі.
status.resourceRules.resourceNames ([]string)
ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все. "*" означає всі.
status.resourceRules.resources ([]string)
Resources — це список ресурсів, до яких застосовується це правило. "*" означає всі в зазначених apiGroups. "*/foo" представляє субресурс 'foo' для всіх ресурсів у зазначених apiGroups.
status.evaluationError (string)
EvaluationError може зʼявитися разом із Rules. Це вказує на те, що під час оцінки правил сталася помилка, наприклад, авторизатор не підтримує оцінку правил, і що ResourceRules та/або NonResourceRules можуть бути неповними.
SelfSubjectRulesReviewSpec
SelfSubjectRulesReviewSpec визначає специфікацію для SelfSubjectRulesReview.
namespace (string)
Простір імен для оцінки правил. Обовʼязково.
Операції
create створення SelfSubjectRulesReview
HTTP запит
POST /apis/authorization.k8s.io/v1/selfsubjectrulesreviews
Статус заповнюється сервером і вказує, чи дозволено запит, чи ні
SubjectAccessReviewSpec
SubjectAccessReviewSpec — це опис запиту на доступ. Має бути встановлено одне з ResourceAuthorizationAttributes або NonResourceAuthorizationAttributes
extra (map[string][]string)
Extra відповідає методу user.Info.GetExtra() з автентифікатора. Оскільки це вхідні дані для авторизатора, це потребує відображення тут.
groups ([]string)
Groups — це групи, для яких ви проводите тестування.
nonResourceAttributes (NonResourceAttributes)
NonResourceAttributes описує інформацію для запиту на доступ до не-ресурсів
NonResourceAttributes включає атрибути авторизації, доступні для запитів на не-ресурси до інтерфейсу Authorizer
nonResourceAttributes.path (string)
Path — це URL шлях запиту
nonResourceAttributes.verb (string)
Verb — це стандартне HTTP дієслово
resourceAttributes (ResourceAttributes)
ResourceAuthorizationAttributes описує інформацію для запиту на доступ до ресурсу
ResourceAttributes включає атрибути авторизації, доступні для запитів на ресурси до інтерфейсу Authorizer
resourceAttributes.group (string)
Group — це API група ресурсу. "*" означає всі.
resourceAttributes.name (string)
Name — це імʼя ресурсу, який запитується для "отримання" ("get") або видаляється для "видалення" ("delete"). "" (порожньо) означає всі.
resourceAttributes.namespace (string)
Namespace — це простір імен дії, яка запитується. Зараз немає різниці між відсутністю простору імен та всіма просторами імен "" (порожньо) змінюється на стандартне значення для LocalSubjectAccessReviews, "" (порожньо) є порожнім для кластерних ресурсів, "" (порожньо) означає "всі" для ресурсів з простором імен у SubjectAccessReview або SelfSubjectAccessReview
resourceAttributes.resource (string)
Resource — це один з наявних типів ресурсів. "*" означає всі.
resourceAttributes.subresource (string)
Subresource - це один з наявних типів субресурсів. "" означає жоден.
resourceAttributes.verb (string)
Verb — це дієслово API ресурсу Kubernetes, таке як: get, list, watch, create, update, delete, proxy. "*" означає всі.
resourceAttributes.version (string)
Version — це версія API ресурсу. "*" означає всі.
uid (string)
UID — інформація про користувача, який робить запит.
user (string)
User — це користувач, для якого проводиться тестування. Якщо ви вказуєте "User", але не "Groups", то це інтерпретується як "Що, якщо User не є членом жодної групи?"
SubjectAccessReviewStatus
SubjectAccessReviewStatus
allowed (boolean), обовʼязково
Allowed є обовʼязковим. True, якщо дія буде дозволена, false в іншому випадку.
denied (boolean)
Denied є необовʼязковим. True, якщо дія буде заборонена, в іншому випадку false. Якщо як allowed є false, так і denied є false, тоді авторизатор не має думки щодо дозволу дії. Denied не може бути true, якщо Allowed є true.
evaluationError (string)
EvaluationError — це вказівка на те, що під час перевірки авторизації сталася якась помилка. Цілком можливо отримати помилку і мати можливість продовжити визначення статусу авторизації, не зважаючи на це. Наприклад, RBAC може не мати ролі, але достатньо ролей все ще присутні та привʼязані для розгляду запиту.
reason (string)
Reason є необовʼязковим. Він вказує, чому запит був дозволений або відхилений.
Операції
create створення SubjectAccessReview
HTTP запит
POST /apis/authorization.k8s.io/v1/subjectaccessreviews
ClusterRole — це логічне групування PolicyRules на рівні кластера, на яке можна посилатися як на єдине ціле за допомогою привʼязки RoleBinding або ClusterRoleBinding.
apiVersion: rbac.authorization.k8s.io/v1
import "k8s.io/api/rbac/v1"
ClusterRole
ClusterRole — це логічне групування PolicyRules на рівні кластера, на яке можна посилатися як на єдине ціле за допомогою привʼязки RoleBinding або ClusterRoleBinding.
AggregationRule — це необовʼязкове поле, яке описує, як створити правила для цього ClusterRole. Якщо AggregationRule встановлено, то правила управляються контролером і прямі зміни до правил будуть перезаписані контролером.
AggregationRule описує, як знайти ClusterRoles для обʼєднання у ClusterRole
ClusterRoleSelectors містить список селекторів, які будуть використані для пошуку ClusterRoles та створення правил. Якщо будь-який з селекторів збігається, тоді дозволи ClusterRole будуть додані.
rules ([]PolicyRule)
Rules містить всі PolicyRules для цього ClusterRole.
PolicyRule містить інформацію, яка описує правило політики, але не містить інформації про те, до кого застосовується правило або до якого простору імен воно відноситься.
rules.apiGroups ([]string)
APIGroups — це назва APIGroup, яка містить ресурси. Якщо вказано декілька API груп, будь-яка дія, запитана для одного з перерахованих ресурсів у будь-якій API групі, буде дозволена. "" представляє основну API групу, а "*" представляє всі API групи.
rules.resources ([]string)
Resources — це список ресурсів, до яких застосовується це правило. '*' представляє всі ресурси.
rules.verbs ([]string), обовʼязкове
Verbs — це список дієслів, які застосовуються до ВСІХ ResourceKinds, що містяться у цьому правилі. '*' представляє всі дієслова.
rules.resourceNames ([]string)
ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.
rules.nonResourceURLs ([]string)
NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. '*' дозволені, але тільки як повний, кінцевий крок у шляху. Оскільки не ресурсні URL-адреси не належать до простору імен, це поле застосовується тільки для ClusterRoles, на які посилається ClusterRoleBinding. Правила можуть застосовуватися або до API ресурсів (таких як "pods" або "secrets"), або до не ресурсних URL-шляхів (таких як "/api"), але не до обох одночасно.
ClusterRoleBinding посилається на ClusterRole, але не містить її.
apiVersion: rbac.authorization.k8s.io/v1
import "k8s.io/api/rbac/v1"
ClusterRoleBinding
ClusterRoleBinding посилається на ClusterRole, але не містить її. ClusterRoleBinding може посилатися на ClusterRole в глобальному просторі імен та додає інформацію про субʼєкти через Subject.
RoleRef може посилатися лише на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.
RoleRef містить інформацію, яка посилається на використану роль
roleRef.apiGroup (string), обовʼязкове
APIGroup — це група для вказаного ресурсу
roleRef.kind (string), обовʼязкове
Kind - тип вказаного ресурсу
roleRef.name (string), обовʼязкове
Name - це імʼя вказаного ресурсу
subjects ([]Subject)
Subjects містить посилання на обʼєкти, до яких застосовується роль.
Subject містить посилання на обʼєкт або ідентифікатори користувачів, до яких застосовується привʼязка ролей. Може містити або пряме посилання на обʼєкт API, або значення для не-обʼєктів, таких як імена користувачів і груп.
subjects.kind (string), обовʼязкове
Kind — тип обʼєкта, на який посилається. Значення, визначені цією API групою, є "User", "Group" та "ServiceAccount". Якщо Авторизатор не впізнає значення kind, він повинен повідомити про помилку.
subjects.name (string), обовʼязкове
Name — імʼя обʼєкта, на який посилається.
subjects.apiGroup (string)
APIGroup — це API група вказаного субʼєкта. Стандартно "" для субʼєктів ServiceAccount. Стандартно "rbac.authorization.k8s.io" для субʼєктів User і Group.
subjects.namespace (string)
Namespace — простір імен вказаного обʼєкта. Якщо тип обʼєкта не простір імен, наприклад, "User" або "Group", і це значення не порожнє, Авторизатор повинен повідомити про помилку.
ClusterRoleBindingList
ClusterRoleBindingList — це колекція ClusterRoleBindings.
PolicyRule містить інформацію, що описує правило політики, але не містить інформації про те, до кого застосовується правило або до якого простору імен воно відноситься.
rules.apiGroups ([]string)
APIGroups — це назва APIGroup, яка містить ресурси. Якщо вказано декілька API груп, будь-яка дія, запитана для одного з перерахованих ресурсів у будь-якій API групі буде дозволена. "" представляє основну API групу, а "*" представляє всі API групи.
rules.resources ([]string)
Resources — це список ресурсів, до яких застосовується це правило. '*' представляє всі ресурси.
rules.verbs ([]string), обовʼязково
Verbs — це список дієслів, які застосовуються до ВСІХ ResourceKinds, що містяться у цьому правилі. '*' представляє всі дієслова.
rules.resourceNames ([]string)
ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.
rules.nonResourceURLs ([]string)
NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. '*' дозволені, але тільки як повний, кінцевий крок у шляху. Оскільки не ресурсні URL-адреси не належать до простору імен, це поле застосовується тільки для ClusterRoles, на які посилається ClusterRoleBinding. Правила можуть застосовуватися або до API ресурсів (таких як "pods" або "secrets"), або до не ресурсних URL-шляхів (таких як "/api"), але не до обох одночасно.
RoleBinding посилається на роль, але не містить її.
apiVersion: rbac.authorization.k8s.io/v1
import "k8s.io/api/rbac/v1"
RoleBinding
RoleBinding посилається на роль, але не містить її. RoleBinding може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. RoleBinding додає інформацію про субʼєкти через Subjects і інформацію про простір імен, в якому існує. RoleBindings у визначеному просторі імен мають вплив лише в цьому просторі імен.
RoleRef може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.
RoleRef містить інформацію, яка посилається на використану роль
roleRef.apiGroup (string), обовʼязкове
APIGroup — це група для вказаного ресурсу
roleRef.kind (string), обовʼязкове
Kind — тип вказаного ресурсу
roleRef.name (string), обовʼязкове
Name — це імʼя вказаного ресурсу
subjects ([]Subject)
Subjects містить посилання на обʼєкти, до яких застосовується роль.
Subject містить посилання на обʼєкт або ідентифікатори користувачів, до яких застосовується привʼязка ролей. Може містити або пряме посилання на обʼєкт API, або значення для не-обʼєктів, таких як імена користувачів і груп.
subjects.kind (string), обовʼязкове
Kind — тип обʼєкта, на який посилається. Значення, визначені цією API групою, є "User", "Group" та "ServiceAccount". Якщо Авторизатор не впізнає значення kind, він повинен повідомити про помилку.
subjects.name (string), обовʼязкове
Name — імʼя обʼєкта, на який посилається.
subjects.apiGroup (string)
APIGroup — це API група вказаного субʼєкта. Стандартно — "" для субʼєктів ServiceAccount. Стандартно — "rbac.authorization.k8s.io" для субʼєктів User і Group.
subjects.namespace (string)
Namespace — простір імен вказаного обʼєкта. Якщо тип обʼєкта не простір імен, наприклад, "User" або "Group", і це значення не порожнє, Авторизатор повинен повідомити про помилку.
MaxLimitRequestRatio, якщо зазначено, названий ресурс повинен мати запит і обмеження, які обидва є ненульовими, де обмеження, поділене на запит, менше або дорівнює перерахованому значенню; це представляє максимальне навантаження для названого ресурсу.
scopeSelector — це також набір фільтрів, таких як scopes, які повинні відповідати кожному обʼєкту, відстежуваному квотою, але виражені за допомогою ScopeSelectorOperator у поєднанні з можливими значеннями. Для відповідності ресурсу повинні відповідати як scopes, так і scopeSelector (якщо зазначено у spec).
Селектор області застосування являє собою AND селекторів, представлених вимогами селектора ресурсу з обмеженою областю застосування.
Список вимог селектора за областю застосування ресурсів.
Вимога до селектора ресурсу з областю застосування — це селектор, який містить значення, імʼя області застосування та оператор, який повʼязує імʼя області застосування зі значеннями.
Імʼя області застосування, до якої застосовується селектор.
scopeSelector.matchExpressions.values ([]string)
Масив рядкових значень. Якщо оператор In або NotIn, масив значень не повинен бути порожнім. Якщо оператор Exists або DoesNotExist, масив значень повинен бути порожнім. Цей масив замінюється під час стратегії обʼєднання патчів.
scopes ([]string)
Набір фільтрів, які повинні відповідати кожному обʼєкту, відстежуваному квотою. Якщо не вказано, квота відповідає всім обʼєктам.
ResourceQuotaStatus
ResourceQuotaStatus визначає застосовані жорсткі обмеження та спостережуване використання.
podSelector вибирає Podʼи, до яких застосовується цей обʼєкт NetworkPolicy. Масив правил ingress застосовується до будь-яких Podʼів, вибраних цим полем. Кілька мережевих політик можуть вибирати той самий набір Podʼів. У цьому випадку правила ingress для кожного з них поєднуються. Це поле НЕ є необовʼязковим і слідує стандартним семантикам вибору міток. Порожній podSelector збігається з усіма Podʼами в цьому простору імен.
policyTypes ([]string)
policyTypes — це список типів правил, до яких відноситься NetworkPolicy. Дійсні опції включають [“Ingress"], [“Egress"] або [“Ingress", “Egress"]. Якщо це поле не вказано, воно буде визначено стандартно на основі наявності правил ingress або egress; політики, які містять розділ egress, вважаються такими, що впливають на egress, а всі політики (незалежно від того, чи містять вони розділ ingress) вважаються такими, що впливають на ingress. Якщо ви хочете написати політику тільки для egress, ви повинні явно вказати policyTypes [“Egress"]. Аналогічно, якщо ви хочете написати політику, яка визначає, що egress не дозволений, ви повинні вказати значення policyTypes, яке включає “Egress" (оскільки така політика не включатиме розділ egress і стандартно буде просто [“Ingress" ]). Це поле є рівнем бета у версії 1.8.
ingress ([]NetworkPolicyIngressRule)
ingress — це список правил ingress, які застосовуються до вибраних Podʼів. Трафік дозволено до Podʼа, якщо немає мережевих політик, які вибирають Pod (і кластерна політика інакше дозволяє трафік), АБО якщо джерелом трафіку є локальний вузол Podʼа, АБО якщо трафік відповідає принаймні одному правилу ingress серед усіх обʼєктів NetworkPolicy, чий podSelector відповідає Podʼу. Якщо це поле порожнє, ця NetworkPolicy не дозволяє жодного трафіку (і стандартно слугує виключно для того, щоб забезпечити ізоляцію вибраних Podʼів).
NetworkPolicyIngressRule описує конкретний набір трафіку, який дозволено до Podʼів, вибраних podSelector у NetworkPolicySpec. Трафік повинен відповідати як ports, так і from.
ingress.from ([]NetworkPolicyPeer)
from — це список джерел, яким дозволено доступ до Podʼів, вибраних для цього правила. Елементи в цьому списку комбінуються за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма джерелами (трафік не обмежений за джерелом). Якщо це поле присутнє і містить принаймні один елемент, це правило дозволяє трафік лише у разі відповідності принаймні одному елементу зі списку from.
NetworkPolicyPeer описує однорангового учасника для дозволу трафіку до/від. Допускаються лише певні комбінації полів.
ingress.from.ipBlock (IPBlock)
ipBlock визначає політику для конкретного IPBlock. Якщо це поле встановлено, то жодне інше поле не може бути встановлене.
IPBlock описує конкретний CIDR (наприклад, “192.168.1.0/24",“2001:db8::/64"), який дозволено для Podʼів, вибраних podSelector у NetworkPolicySpec. Поле except описує CIDR, які не повинні бути включені до цього правила.
ingress.from.ipBlock.cidr (string), обовʼязково
cidr — це рядок, що представляє IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64".
ingress.from.ipBlock.except ([]string)
except — це перелік CIDR, які не повинні бути включені до IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64". Значення except будуть відхилені, якщо вони виходять за межі діапазону cidr.
namespaceSelector вибирає простори імен за допомогою кластерних міток. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі простори імен.
Якщо також встановлено podSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних namespaceSelector. Інакше він вибирає всі Podʼи в просторах імен, вибраних namespaceSelector.
podSelector — це вибір міток, що вибирає Podʼи. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі Podʼи.
Якщо також встановлено namespaceSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних NamespaceSelector. Інакше він вибирає Podʼи, які відповідають podSelector у власному просторі імен політики.
ingress.ports ([]NetworkPolicyPort)
ports — це список портів, які повинні бути доступні у Podʼах, вибраних для цього правила. Кожен елемент у цьому списку комбінується за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма портами (трафік не обмежений за портом). Якщо це поле присутнє і містить принаймні один елемент, тоді це правило дозволяє трафік лише у разі відповідності принаймні одному порту зі списку.
NetworkPolicyPort описує порт, на якому дозволено трафік
ingress.ports.port (IntOrString)
port представляє порт на заданому протоколі. Це може бути числовий або іменований порт на Podʼі. Якщо це поле не вказане, це збігається з усіма іменами та номерами портів. Якщо присутнє, то відповідає лише трафік на вказаному протоколі ТА порті.
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
ingress.ports.endPort (int32)
endPort вказує, що діапазон портів від port до endPort, якщо встановлено, включно, повинен бути дозволений політикою. Це поле не може бути визначене, якщо поле port не визначене або якщо поле port визначене як іменований (string) порт. Поле endPort повинно бути рівним або більшим за port.
ingress.ports.protocol (string)
protocol представляє протокол (TCP, UDP або SCTP), якому повинен відповідати трафік. Якщо не вказано, це поле стандартно встановлюється у TCP.
egress ([]NetworkPolicyEgressRule)
egress — це список правил egress, які застосовуються до вибраних Podʼів. Вихідний трафік дозволений, якщо немає мережевих політик, які вибирають Pod (і кластерна політика інакше дозволяє трафік), АБО якщо трафік відповідає принаймні одному правилу egress серед усіх обʼєктів NetworkPolicy, чий podSelector відповідає Podʼу. Якщо це поле порожнє, ця NetworkPolicy обмежує весь вихідний трафік (і слугує виключно для того, щоб стандартно забезпечити ізоляцію вибраних Podʼів). Це поле є рівнем бета у версії 1.8.
NetworkPolicyEgressRule описує конкретний набір трафіку, який дозволено від Podʼів, вибраних podSelector у NetworkPolicySpec. Трафік повинен відповідати як ports, так і to. Цей тип є рівнем бета у версії 1.8.
egress.to ([]NetworkPolicyPeer)
to — це список пунктів призначення для вихідного трафіку Podʼів, вибраних для цього правила. Елементи в цьому списку комбінуються за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма пунктами призначення (трафік не обмежений за пунктом призначення). Якщо це поле присутнє і містить принаймні один елемент, це правило дозволяє трафік лише у разі відповідності принаймні одному елементу зі списку to.
NetworkPolicyPeer описує однорангового учасника для дозволу трафіку до/від. Допускаються лише певні комбінації полів.
egress.to.ipBlock (IPBlock)
ipBlock визначає політику для конкретного IPBlock. Якщо це поле встановлено, то жодне інше поле не може бути встановлене.
IPBlock описує конкретний CIDR (наприклад, “192.168.1.0/24",“2001:db8::/64"), який дозволено для Podʼів, вибраних podSelector у NetworkPolicySpec. Поле except описує CIDR, які не повинні бути включені до цього правила.
egress.to.ipBlock.cidr (string), обовʼязково
cidr — це рядок, що представляє IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64".
egress.to.ipBlock.except ([]string)
except — це перелік CIDR, які не повинні бути включені до IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64". Значення except будуть відхилені, якщо вони виходять за межі діапазону cidr.
namespaceSelector вибирає простори імен за допомогою кластерних міток. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі простори імен.
Якщо також встановлено podSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних namespaceSelector. Інакше він вибирає всі Podʼи в просторах імен, вибраних namespaceSelector.
podSelector — це вибір міток, що вибирає Podʼи. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі Podʼи.
Якщо також встановлено namespaceSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних NamespaceSelector. Інакше він вибирає Podʼи, які відповідають podSelector у власному просторі імен політики.
egress.ports ([]NetworkPolicyPort)
ports — це список портів призначення для вихідного трафіку. Кожен елемент у цьому списку комбінується за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма портами (трафік не обмежений за портом). Якщо це поле присутнє і містить принаймні один елемент, тоді це правило дозволяє трафік лише у разі відповідності принаймні одному порту зі списку.
NetworkPolicyPort описує порт, на якому дозволено трафік
egress.ports.port (IntOrString)
port представляє порт на заданому протоколі. Це може бути числовий або іменований порт у Podʼі. Якщо це поле не вказане, воно збігається з усіма іменами та номерами портів. Якщо присутнє, то відповідає лише трафік на вказаному протоколі ТА порті.
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
egress.ports.endPort (int32)
endPort вказує, що діапазон портів від port до endPort, якщо встановлено, включно, повинен бути дозволений політикою. Це поле не може бути визначене, якщо поле port не визначене або якщо поле port визначене як іменований (string) порт. Поле endPort повинно бути рівним або більшим за port.
egress.ports.protocol (string)
protocol представляє протокол (TCP, UDP або SCTP), якому повинен відповідати трафік. Якщо не вказано, це поле стандартно встановлюється у TCP.
NetworkPolicyList
NetworkPolicyList — це список обʼєктів NetworkPolicy.
apiVersion: networking.k8s.io/v1
Вказує версію API.
kind: NetworkPolicyList
Вказує тип ресурсу, в цьому випадку NetworkPolicyList.
Останній спостережуваний стан PodDisruptionBudget.
PodDisruptionBudgetSpec
PodDisruptionBudgetSpec — це опис PodDisruptionBudget.
maxUnavailable (IntOrString)
Виселення дозволяється, якщо щонайбільше "maxUnavailable" Podʼів, вибраних за допомогою "selector", є недоступними після виселення, тобто навіть за відсутності виселеного Podʼа. Наприклад, можна запобігти всім добровільним виселенням, вказавши 0. Це взаємозаперечне налаштування з "minAvailable".
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
minAvailable (IntOrString)
Виселення дозволяється, якщо щонайменше "minAvailable" Podʼів, вибраних за допомогою "selector", залишаться доступними після виселення, тобто навіть за відсутності виселеного Podʼа. Наприклад, можна запобігти всім добровільним виселенням, вказавши "100%".
IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.
Запит міток для Podʼів, виселення яких керується бюджетом розладів. Нульовий селектор не вибиратиме жодного Podʼа, тоді як порожній ({}) селектор вибиратиме всі Podʼи в межах простору імен.
unhealthyPodEvictionPolicy (string)
UnhealthyPodEvictionPolicy визначає критерії, коли несправні Podʼи слід вважати кандидатами на виселення. Поточна реалізація вважає справними ті Podʼи, у яких у status.conditions є елемент із type="Ready",status="True".
Дійсні політики: IfHealthyBudget і AlwaysAllow. Якщо політика не вказана, буде використано стандартну поведінку, яка відповідає політиці IfHealthyBudget.
Політика IfHealthyBudget означає, що працюючі Podʼи (status.phase="Running"), але ще не справні, можуть бути виселені лише у випадку, якщо захищений застосунок не в розладі (status.currentHealthy принаймні дорівнює status.desiredHealthy). Справні Podʼи підпадають під дію PDB для виселення.
Політика AlwaysAllow означає, що всі працюючі Podʼи (status.phase="Running"), але ще не справні, вважаються в стані розладу і можуть бути виселені незалежно від того, чи виконуються критерії у PDB. Це означає, що працюючі Podʼи застосунка в розладі можуть не мати шансу стати справними. Справні Podʼи підпадають під дію PDB для виселення.
У майбутньому можуть бути додані додаткові політики. Клієнти, які приймають рішення про виселення, повинні забороняти виселення несправних Podʼів, якщо вони стикаються з незнайомою політикою в цьому полі.
Це поле знаходиться на рівні бета. API виселення використовує це поле, коли функціональні можливості PDBUnhealthyPodEvictionPolicy увімкнені (стандартно увімкнено).
PodDisruptionBudgetStatus
PodDisruptionBudgetStatus представляє інформацію про стан PodDisruptionBudget. Статус може відставати від фактичного стану системи.
currentHealthy (int32), обовʼязково
поточна кількість справних Podʼів
desiredHealthy (int32), обовʼязково
мінімально бажана кількість справних Podʼів
disruptionsAllowed (int32), обовʼязково
Кількість розладів Podʼів, які наразі дозволені.
expectedPods (int32), обовʼязково
загальна кількість Podʼів, врахованих цим бюджетом розладів
conditions ([]Condition)
Patch strategy: обʼєднання за ключем type
Map: унікальні значення за ключем type зберігаються під час обʼєднання
Conditions містить стани для PDB. Контролер розладів встановлює стан DisruptionAllowed. Нижче наведені відомі значення для поля reason (у майбутньому можуть бути додані додаткові причини):
SyncFailed: Контролер зіткнувся з помилкою і не зміг обчислити кількість дозволених розладів. Тому розлади не дозволяються, і статус стану буде False.
InsufficientPods: Кількість Podʼів дорівнює або менша за кількість, необхідну для PodDisruptionBudget. Розлади не дозволяються, і статус стану буде False.
SufficientPods: Є більше Podʼів, ніж потрібно для PodDisruptionBudget. Стан буде True, і кількість дозволених розладів буде вказана у властивості disruptionsAllowed.
Condition містить деталі щодо одного аспекту поточного стану цього ресурсу API.
conditions.lastTransitionTime (Time), обовʼязково
lastTransitionTime — це час останнього переходу стану з одного в інший. Це має бути момент, коли змінився основний стан. Якщо це невідомо, то допустимо використовувати час, коли змінилося поле API.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
conditions.message (string), обовʼязково
message — це повідомлення, зрозуміле людині, вказує деталі про зміну стану. Це може бути порожній рядок.
conditions.reason (string), обовʼязково
reason містить програмний ідентифікатор, що вказує причину останньої зміни стану. Виробники певних типів станів можуть визначати очікувані значення та значення для цього поля та чи вважаються ці значення гарантованими API. Значення має бути рядком у CamelCase. Це поле не може бути порожнім.
conditions.status (string), обовʼязково
статус стану, одне з True, False, Unknown.
conditions.type (string), обовʼязково
тип стану в CamelCase або у форматі foo.example.com/CamelCase.
conditions.observedGeneration (int64)
observedGeneration представляє .metadata.generation, на основі якого було встановлено стан. Наприклад, якщо .metadata.generation наразі дорівнює 12, але .status.conditions[x].observedGeneration дорівнює 9, стан застарів щодо поточного стану екземпляра.
disruptedPods (map[string]Time)
DisruptedPods містить інформацію про Podʼи, виселення яких було оброблено субресурсом виселення API-сервера, але ще не було зафіксовано контролером PodDisruptionBudget. Pod буде в цьому map з моменту, коли API-сервер обробив запит на виселення, до моменту, коли контролер PDB побачить Pod як такий, що позначений для видалення (або після тайм-ауту). Ключем у map є назва Podʼа, а значенням — час, коли API-сервер обробив запит на виселення. Якщо видалення не відбулося і Pod все ще є, він буде автоматично видалений зі списку контролером PodDisruptionBudget через певний час. Якщо все йде добре, цей map повинен бути порожнім більшу частину часу. Велика кількість записів у map може вказувати на проблеми з видаленням Podʼів.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
observedGeneration (int64)
Останнє спостережене покоління під час оновлення цього статусу PDB. DisruptionsAllowed та інша інформація про статус дійсні лише, якщо observedGeneration дорівнює поколінню обʼєкта PDB.
IP-адреса являє собою одну IP-адресу з одного сімейства IP-адрес.
apiVersion: networking.k8s.io/v1alpha1
import "k8s.io/api/networking/v1alpha1"
IPAddress
IPAddress представляє одну IP-адресу одного сімейства IP. Цей обʼєкт призначений для використання API, які оперують IP-адресами. Обʼєкт використовується ядром API Service для виділення IP-адрес. IP-адресу можна представити у різних форматах. Щоб гарантувати унікальність IP-адреси, імʼя обʼєкта є IP-адреса в канонічному форматі: чотири десяткові цифри, розділені крапками без ведучих нулів для IPv4 і представлення, визначене RFC 5952 для IPv6. Дійсні: 192.168.1.5 або 2001:db8::1 або 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 Недійсні: 10.01.2.3 або 2001:db8:0:0:0::1
Коли параметр присутній, вказує, що зміни не повинні бути збережені. Недійсні або невизнані директиви dryRun призведуть до відповіді з помилкою і подальшої відмови в обробці запиту. Допустимі значення: - All: всі етапи випробувального запуску будуть оброблені
gracePeriodSeconds (int64)
Тривалість в секундах до видалення обʼєкта. Значення повинно бути не відʼємним цілим числом. Значення нуль означає видалення без затримки. Якщо це значення є nil, буде використовуватися стандартне значення для вказаних типів. Стандартно буде використовуватися значення для обʼєкта, якщо не вказано. Нуль означає видалення без затримки.
Застаріле: будь ласка, використовуйте PropagationPolicy, це поле буде застаріле в версії 1.7. Чи повинні бути покинуті залежні обʼєкти. Якщо true/false, завершувач "orphan" буде доданий/видалений зі списку завершувачів обʼєкта. Можна встановити або це поле, або PropagationPolicy, але не обидва.
preconditions (Preconditions)
Має бути виконано перед видаленням. Якщо це неможливо, буде повернено статус 409 Conflict.
Умови мають бути виконані перед виконанням операції (оновлення, видалення і т. д.).
preconditions.resourceVersion (string)
Вказує цільову ResourceVersion
preconditions.uid (string)
Вказує цільовий UID.
propagationPolicy (string)
Чи та як буде виконуватися збір сміття. Можна встановити або це поле, або OrphanDependents. Стандартна політика визначається наявним набором завершувачів у metadata.finalizers та стандартною політикою, що специфічна для ресурсу. Прийнятні значення: 'Orphan' — залишити залежності без батьків; 'Background' — дозволити збирачеві сміття видаляти залежності в фоновому режимі; 'Foreground' — каскадна політика, що видаляє всі залежності безпосередньо.
5.9.2 - LabelSelector
Селектор міток — є запитом на наявність міток до набору ресурсів.
import "k8s.io/apimachinery/pkg/apis/meta/v1"
Селектор міток — це запит на наявність міток до набору ресурсів. Результати matchLabels та matchExpressions поєднуються логічним І (AND). Порожній селектор міток має збіг зі всіма обʼєктам. Нульовий селектор міток не збігається з жодним обʼєктом.
matchExpressions ([]LabelSelectorRequirement)
matchExpressions — це список вимог селектора міток. Вимоги зʼєднуються логічною операцією І (AND).
Вимоги селектора міток — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.
matchExpressions.key (string), обовʼязково
key — це ключ мітки, до якого застосовується селектор.
matchExpressions.operator (string), обовʼязково
operator представляє стосунок ключа до набору значень. Допустимі оператори: In, NotIn, Exists та DoesNotExist.
matchExpressions.values ([]string)
values — це масив рядкових значень. Якщо оператор — In або NotIn, масив значень повинен бути не пустим. Якщо оператор — Exists або DoesNotExist, масив значень повинен бути пустим. Цей масив замінюється під час стратегічного злиття патча.
matchLabels (map[string]string)
matchLabels — це зіставлення пар {ключ, значення}. Один {ключ, значення} у зіставленні matchLabels еквівалентний елементу matchExpressions, де поле key — "key", оператор — "In", а масив значень містить лише "value". Вимоги зʼєднуються логічною операцією І (AND).
5.9.3 - ListMeta
ListMeta описує метадані, які синтетичні ресурси повинні мати, включаючи списки та різноманітні обʼєкти статусу.
import "k8s.io/apimachinery/pkg/apis/meta/v1"
ListMeta описує метадані, які синтетичні ресурси повинні мати, включаючи списки та різноманітні обʼєкти статусу. Ресурс може мати лише один з {ObjectMeta, ListMeta}.
continue (string)
continue може бути встановлено, якщо користувач встановив обмеження на кількість елементів, які повертаються, і вказує на те, що сервер має більше даних. Значення непрозоре і може бути використано для видачі іншого запиту до точки доступу, яка обслуговувала цей список, для отримання наступного набору доступних обʼєктів. Продовження стабільного списку може бути неможливим, якщо конфігурація сервера змінилася або пройшло більше декількох хвилин. Поле resourceVersion, повернене при використанні цього значення continue, буде ідентичним значенню у першій відповіді, якщо ви не отримали цей токен з повідомлення про помилку.
remainingItemCount (int64)
remainingItemCount — це кількість наступних елементів у списку, які не включені у цю відповідь списку. Якщо запит на список містив селектори міток або полів, то кількість залишених елементів невідома, і поле буде залишено невстановленим і опущено під час серіалізації. Якщо список завершено (або через те, що він не розділяється на частини, або через те, що це остання частина), то більше залишених елементів немає, і це поле буде залишено невстановленим і опущено під час серіалізації. Сервери, старші за v1.15, не встановлюють це поле. Призначене використання remainingItemCount — оцінювання розміру колекції. Клієнти не повинні покладатися на встановлення або точність remainingItemCount.
Застаріле: selfLink — це застаріле поле тільки для читання, яке більше не заповнюється системою.
5.9.4 - LocalObjectReference.
LocalObjectReference містить достатньо інформації, щоб дозволити вам знайти вказаний обʼєкт всередині того самого простору імен.
import "k8s.io/api/core/v1"
LocalObjectReference містить достатньо інформації, щоб дозволити вам знайти вказаний обʼєкт всередині того самого простору імен."
title: "LocalObjectReference
Вимоги селектора вузлів — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.
import "k8s.io/api/core/v1"
Вимоги селектора вузлів — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.
key (string), обовʼязково
key — це ключ мітки, до якого застосовується селектор.
operator (string), обовʼязково
operator представляє стосунок ключа до набору значень. Допустимі оператори: In, NotIn, Exists, DoesNotExist, Gt та Lt.
values ([]string)
values — це масив рядкових значень. Якщо оператор — In або NotIn, масив значень повинен бути не пустим. Якщо оператор — Exists або DoesNotExist, масив значень повинен бути пустим. Якщо оператор — Gt або Lt, масив значень повинен містити один елемент, який буде інтерпретовано як ціле число. Цей масив замінюється під час стратегічного злиття патча.
5.9.6 - ObjectFieldSelector
ObjectFieldSelector вибирає поле з версією API обʼєкта.
import "k8s.io/api/core/v1"
ObjectFieldSelector вибирає поле з версією API обʼєкта.
fieldPath (string), обовʼязково
Шлях поля для вибору в зазначеній версії API.
apiVersion (string)
Версія схеми, в якій виражений fieldPath, стандартне значення — "v1".
5.9.7 - ObjectMeta
ObjectMeta — це метадані, які повинні бути у всіх збережених ресурсів, включаючи всі обʼєкти, які користувачі повинні створювати.
import "k8s.io/apimachinery/pkg/apis/meta/v1"
ObjectMeta — це метадані, які повинні бути у всіх збережених ресурсів, включаючи всі обʼєкти, які користувачі повинні створювати.
name (string)
Ім’я (назва) має бути унікальним у просторі імен. Потрібне під час створення ресурсів, хоча деякі ресурси можуть дозволяти клієнту запитувати створення відповідного імені автоматично. Назва в першу чергу призначена для створення ідемпотентності та визначення конфігурації. Не може бути змінене. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#names
generateName (string)
GenerateName — це необов’язковий префікс, який використовується сервером для генерації унікального імені, ТІЛЬКИ ЯКЩО поле Name не було надано. Якщо використовується це поле, ім’я, що повертається клієнту, відрізнятиметься від переданого. Це значення також поєднується з унікальним суфіксом. Надане значення має ті самі правила перевірки, що й поле Name, і може бути скорочено на довжину суфікса, необхідного для того, щоб зробити значення унікальним на сервері.
Якщо це поле вказано, а згенерована назва існує, сервер поверне 409.
Простір імен визначає простір, у якому кожне ім’я має бути унікальним. Порожній простір імен еквівалентний простору імен "default", але "default" є канонічним представленням. Не всі об’єкти повинні мати область імен — значення цього поля для цих об’єктів буде порожнім.
Анотації — це неструктурований масив (map) значень ключів, що зберігається з ресурсом, який може бути заданий зовнішніми інструментами для зберігання та отримання довільних метаданих. Вони не є запитуваними та повинні зберігатися при модифікації обʼєктів. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations
System
finalizers ([]string)
Це поле повинно бути порожнім перед тим, як обʼєкт буде видалено з реєстру. Кожен запис є ідентифікатором відповідального компонента, який видалить цей запис зі списку. Якщо deletionTimestamp обʼєкта не є nil, записи у цьому списку можуть бути лише видалені. Завершувачі можуть оброблятися та видалятися у будь-якому порядку. Порядок НЕ є обовʼязковим, оскільки це створює значний ризик зависання завершувачів. Поле finalizers є спільним, будь-який актор з відповідними дозволами може змінити його порядок. Якщо список завершувачів обробляється у порядку, це може призвести до ситуації, коли компонент, відповідальний за перший завершувач у списку, чекає сигналу (значення поля, зовнішньої системи або іншого), що виробляється компонентом, відповідальним за завершувача, який знаходиться далі у списку, що призводить до тупикової ситуації. Без обовʼязкового порядку завершувачі можуть впорядковуватися самостійно та не вразливі до змін порядку у списку.
managedFields ([]ManagedFieldsEntry)
ManagedFields зіставляє ідентифікатор робочого процесу та версію з набором полів, якими керує цей робочий процес. Це здебільшого для внутрішнього ведення обліку, і користувачам зазвичай не потрібно встановлювати або розуміти це поле. Робочий процес може бути імʼям користувача, імʼям контролера або імʼям конкретного шляху застосування, як-от "ci-cd". Набір полів завжди знаходиться у версії, яку використовував робочий процес при зміні обʼєкта.
ManagedFieldsEntry — це ідентифікатор робочого процесу, набір полів (FieldSet) і версія групи ресурсу, до якого застосовується набір полів.
managedFields.apiVersion (string)
APIVersion визначає версію ресурсу, до якого застосовується цей набір полів. Формат такий самий, як у верхньорівневого поля APIVersion: "group/version". Це необхідно для відстеження версії набору полів, оскільки він не може бути автоматично конвертований.
managedFields.fieldsType (string)
FieldsType є дискримінатором для різних форматів і версій полів. На цей час можливе лише одне значення: "FieldsV1".
managedFields.fieldsV1 (FieldsV1)
FieldsV1 зберігає перший формат JSON версії, як описано в типі "FieldsV1".
*FieldsV1 зберігає набір полів у структурі даних, подібній до Trie, у форматі JSON.
Кожен ключ або представляє саму область (позначену як '.'), і завжди буде зіставлятись з порожнім набором, або є рядком, що представляє субполе або елемент. Рядок буде слідувати одному з чотирьох форматів: f:<name>, де <name> — це імʼя поля в структурі або ключа в map; v:<value>, де <value> — це точне значення у форматі JSON для елемента списку; i:<index>, де <index> — це позиція елемента у списку; k:<keys>, де <keys> — це масив (map) полів ключів елемента списку з їх унікальними значеннями. Якщо ключ зіставляється з порожнім значенням Fields, поле, яке представляє цей ключ, є частиною набору.
Точний формат визначено в sigs.k8s.io/structured-merge-diff*
managedFields.manager (string)
Manager є ідентифікатором робочого процесу, що керує цим набором полів.
managedFields.operation (string)
Operation — це тип операції, яка призвела до створення цього запису ManagedFieldsEntry. Єдині допустимі значення для цього поля — 'Apply' та 'Update'.
managedFields.subresource (string)
Subresource — це назва субресурсу, який використовується для оновлення цього обʼєкта, або порожній рядок, якщо обʼєкт було оновлено через основний ресурс. Значення цього поля використовується для розрізнення між менеджерами, навіть якщо вони мають однакові імена. Наприклад, оновлення статусу буде відрізнятися від звичайного оновлення за допомогою того самого імені менеджера. Зверніть увагу, що поле APIVersion не повʼязане з полем Subresource і завжди відповідає версії основного ресурсу.
managedFields.time (Time)
Time — це часовий відбиток, коли був доданий запис ManagedFields. Час також буде оновлено, якщо додано поле, менеджер змінює будь-яке зі значень власних полів або видаляє поле. Відмітка часу не оновлюється, коли поле видаляється з запису через те, що його взяв на себе інший менеджер.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
ownerReferences ([]OwnerReference)
Patch strategy: злиття за ключем uid
Список обʼєктів, від яких залежить цей обʼєкт. Якщо ВСІ обʼєкти у списку були видалені, цей обʼєкт буде прибраний в процесі збирання сміття. Якщо цей обʼєкт керується контролером, то запис у цьому списку вказуватиме на цей контролер, із полем controller встановленим в true. Не може бути більше одного керуючого контролера.
OwnerReference містить достатньо інформації, щоб дозволити вам ідентифікувати власний обʼєкт. Власний обʼєкт повинен бути в тому ж просторі імен, що й залежний, або мати область видимості кластера, тому поля namespace немає.
ownerReferences.apiVersion (string), обовʼязкове
APIVersion визначає версію ресурсу, до якого відноситься цей обʼєкт.
ownerReferences.kind (string), обовʼязкове
Kind визначає тип ресурсу, до якого відноситься цей обʼєкт. Докладніше: hhtps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
ownerReferences.name (string), обовʼязкове
Ім’я визначає ім’я ресурсу, до якого відноситься цей обʼєкт. Докладніше: hhtps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#names
ownerReferences.uid (string), обовʼязкове
UID визначає унікальний ідентифікатор ресурсу, до якого відноситься цей обʼєкт. Докладніше: hhtps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#uids
ownerReferences.blockOwnerDeletion (boolean)
Якщо true, І якщо у власника є pfdthoedfx "foregroundDeletion", то власника не можна видалити зі сховища ключ-значення, доки це посилання не буде видалено. Див. https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion щодо того, як збирач сміття взаємодіє з цим полем та застосовує явне видалення. стандартно — false. Щоб встановити це поле, користувачу потрібно мати дозвіл "delete" від власника, інакше буде повернуто 422 (Unprocessable Entity).
ownerReferences.controller (boolean)
Якщо true, це посилання вказує на керуючий контролер.
Read-only
creationTimestamp (Time)
CreationTimestamp — це відмітка часу, що представляє час сервера під час створення цього обʼєкта. Немає гарантії, що вона встановлена в порядку "відбулося перед" між окремими операціями. Клієнти не можуть встановлювати це значення. Використовується формат RFC3339 та знаходиться в часовому поясі UTC.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
deletionGracePeriodSeconds (int64)
Кількість секунд, які дозволяють цьому обʼєкту завершити роботу належним чином перед тим, як він буде видалений з системи. Встановлюється лише тоді, коли також встановлено deletionTimestamp. Може бути скорочено тільки в меншу сторону. Тільки для читання.
deletionTimestamp (Time)
Час видалення (DeletionTimestamp) — це дата та час у форматі RFC 3339, коли цей ресурс буде видалено. Це поле встановлюється сервером, коли користувач запитує належне видалення, і не може бути прямо встановлене клієнтом. Ресурс очікується бути видаленим (більше не видимий у списку ресурсів та недосяжний за іменем) після часу, вказаного у цьому полі, як тільки список завершувачів (finalizers) буде порожнім. Поки список завершувачів містить елементи, видалення заблоковане. Як тільки встановлюється час видалення, це значення не можна скасувати або встановити далі в майбутнє, хоча його можна скоротити або ресурс може бути видалений раніше цього часу. Наприклад, користувач може запросити видалення Podʼа через 30 секунд. Kubelet відреагує, надіславши сигнал належного завершення роботи контейнерам у Podʼі. Після цих 30 секунд Kubelet надішле сигнал примусового завершення (SIGKILL) контейнеру й після очищення видалить Pod з API. У випадку мережевих розділень цей обʼєкт може існувати після цієї позначки часу, доки адміністратор або автоматизований процес не визначить, що ресурс повністю завершив роботу. Якщо не встановлено, належне видалення обʼєкта не було запитано.
Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.
generation (int64)
Послідовний номер, що представляє конкретну генерацію бажаного стану. Заповнюється системою. Тільки для читання.
resourceVersion (string)
Непрозоре (opaque) значення, яке представляє внутрішню версію цього обʼєкта, яке може бути використано клієнтами для визначення змін в обʼєктах. Це може використовуватися для оптимістичного одночасного виконання, виявлення змін та операції спостереження над ресурсом або набором ресурсів. Клієнти повинні розглядати ці значення як непрозорі та передавати їх незмінними назад на сервер. Вони можуть бути дійсними тільки для певного ресурсу або набору ресурсів.
Застаріле: selfLink — це застаріле поле, призначене лише для читання, яке більше не заповнюється системою.
uid (string)
UID є унікальним у часі та просторі значенням для цього об’єкта. Зазвичай він генерується сервером після успішного створення ресурсу, і його не можна змінювати під час операцій PUT.
ObjectReference містить достатньо інформації для того, щоб дозволити вам переглядати або змінювати зазначений обʼєкт.
import "k8s.io/api/core/v1"
ObjectReference містить достатньо інформації для того, щоб дозволити вам переглядати або змінювати зазначений обʼєкт.
apiVersion (string)
apiVersion — це версія API ресурсу, до якого вказує цей обʼєкт.
fieldPath (string)
Якщо потрібно посилатися на частину обʼєкта замість цілого обʼєкта, цей рядок повинен містити дійсне висловлення доступу до поля JSON/Go, наприклад, desiredState.manifest.containers[2]. Наприклад, якщо посилання на обʼєкт стосується контейнера у межах Podʼа, це прийме значення подібне: "spec.containers{name}" (де "name" вказує на імʼя контейнера, що спричинило подію), або якщо не вказано жодного імені контейнера "spec.containers[2]" (контейнер з індексом 2 у цьому Pod). Ця синтаксична конструкція вибрана лише для того, щоб мати деякий чітко визначений спосіб посилання на частину обʼєкта.
Patch надає конкретну назву та тип тілу запиту PATCH Kubernetes.
import "k8s.io/apimachinery/pkg/apis/meta/v1"
Patch надає конкретну назву та тип тілу запиту PATCH Kubernetes.
5.9.10 - Quantity
Quantity — це представлення числа з фіксованою комою.
import "k8s.io/apimachinery/pkg/api/resource"
Quantity — це представлення числа з фіксованою комою. Воно надає зручний спосіб перетворення в/з JSON та YAML, на додачу до інструментів String() та AsInt64().
Формат серіалізації виглядає наступним чином:
\<quantity> ::= \<signedNumber>\<suffix>
(Зауважте, що \<suffix> може бути порожнімy, з "" у \<decimalSI>.)
\<digit> ::= 0 | 1 | ... | 9
\<digits> ::= \<digit> | \<digit>\<digits>
\<number> ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits>
\<sign> ::= "+" | "-"
\<signedNumber> ::= \<number> | \<sign>\<number>
\<suffix> ::= \<binarySI> | \<decimalExponent> | \<decimalSI>
\<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
(Міжнародна система мір; Див: http://physics.nist.gov/cuu/Units/binary.html)
\<decimalSI> ::= m | "" | k | M | G | T | P | E
(Зауважте, що 1024 = 1Ki але 1000 = 1k; капіталізація не використовується.)
\<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber>
Незалежно від того, яка з трьох форм експоненти використовується, жодна кількість не може представляти число більше, ніж 2^63-1, а також не може мати більше трьох десяткових знаків. Числа, більші або точніші, будуть обмежені або округлені вгору. (Наприклад: 0.1m буде округлено до 1m.) Це може бути розширено в майбутньому, якщо ми потребуватимемо більших або менших кількостей.
Коли Quantity отримується зі строки, поканик запамʼятає тип суфікса, який він мав, і використовуватиме той самий тип знову, коли буде серіалізований.
Перед серіалізацією, Quantity буде приведено у "канонічну форму". Це означає, що експонента/суфікс буде відрегульована вгору або вниз (з відповідним збільшенням або зменшенням мантиси) таким чином, що:
Точність не буде втрачена
Дробові цифри не будуть випущені
Експонента (або суфікс) буде максимально можливою.
Знак буде опущено, якщо число не є негативним.
Приклади:
1.5 буде серіалізовано як "1500m"
1.5Gi буде серіалізовано як "1536Mi"
Зверніть увагу, що кількість НІКОЛИ не буде внутрішньо представлена числом з плаваючою комою. Це і є головна мета цього підходу.
Неканонічні значення все ще будуть проходити оцінку, якщо вони правильно сформовані, але будуть повторно випущені у своїй канонічній формі. (Отже, завжди використовуйте канонічну форму.)
Цей формат призначений для ускладнення використання цих чисел без написання спеціального коду обробки в надії на те, що це змусить реалізаторів також використовувати реалізацію чисел з фіксованою точкою.
5.9.11 - ResourceFieldSelector
ResourceFieldSelector представляє ресурси контейнера (cpu, memory) та формат їх виводу.
import "k8s.io/api/core/v1"
ResourceFieldSelector представляє ресурси контейнера (cpu, memory) та їх формат виводу.
resource (string), обовʼязково
Обовʼязково: ресурс, який потрібно вибрати.
containerName (string)
Назва контейнера: обовʼязково для томів, необовʼязково для змінних середовища.
Рекомендований HTTP-код відповіді для цього статусу, 0, якщо не встановлено.
details (StatusDetails)
Розширені дані, повʼязані з причиною. Кожна причина може визначити свої власні розширені деталі. Це поле є необовʼязковим, і дані, що повертаються, не гарантовано відповідають будь-якій схемі, крім тієї, що визначена типом причини.
StatusDetails — це набір додаткових властивостей, які МОЖУТЬ бути встановлені сервером для надання додаткової інформації про відповідь. Поле Reason обʼєкта Status визначає, які атрибути будуть встановлені. Клієнти повинні ігнорувати поля, які не відповідають визначеному типу кожного атрибута, і повинні припускати, що будь-який атрибут може бути порожнім, недійсним або невизначеним.
details.causes ([]StatusCause)
Масив Causes містить додаткові деталі, повʼязані з невдачею StatusReason. Не всі StatusReasons можуть надавати детальні причини.
StatusCause надає додаткову інформацію про невдачу api.Status, включаючи випадки, коли зустрічаються декілька помилок.
details.causes.field (string)
Поле ресурсу, яке спричинило цю помилку, назване за його серіалізацією в JSON. Може містити крапку і постфіксну нотацію для вкладених атрибутів. Масиви індексуються починаючи з нуля. Поля можуть зʼявлятися більше одного разу в масиві причин через наявність кількох помилок в полях. Необовʼязкове.
Приклади:
"name" — поле "name" поточного ресурсу
"items[0].name" — поле "name" першого елемента масиву у "items"
details.causes.message (string)
Опис причини помилки, зрозумілий для людини. Це поле може бути представлене читачеві як є.
details.causes.reason (string)
Машинозчитуваний опис причини помилки. Якщо це значення порожнє, інформація відсутня.
details.group (string)
Атрибут групи ресурсу, повʼязаний зі статусом StatusReason.
Атрибут name ресурсу, повʼязаний зі статусом StatusReason (коли є одне імʼя, яке можна описати).
details.retryAfterSeconds (int32)
Якщо вказано, час у секундах до повторного виконання операції. Деякі помилки можуть вказувати, що клієнт повинен виконати альтернативну дію — для цих помилок це поле може показати, як довго чекати перед виконанням альтернативної дії.
Машинозчитуваний опис того, чому ця операція має статус "Failure". Якщо це значення порожнє, немає доступної інформації. Причина уточнює HTTP-код стану, але не перевизначає його.
TypedLocalObjectReference містить достатньо інформації, щоб дозволити вам знаходити типізований згаданий обʼєкт всередині того ж простору імен.
import "k8s.io/api/core/v1"
TypedLocalObjectReference містить достатньо інформації, щоб дозволити вам знаходити типізований згаданий обʼєкт всередині того ж простору імен.
kind (string), обовʼязково
Kind — це тип ресурсу, на який посилаються.
name (string), обовʼязково
Name — це назва ресурсу, на який посилаються.
apiGroup (string)
APIGroup — це група для ресурсу, на який посилаються. Якщо APIGroup не вказано, вказаний Kind повинен бути в основній групі API. Для будь-яких інших сторонніх типів APIGroup є обовʼязковим.
5.10 - Інші ресурси
5.11 - Загальні параметри
allowWatchBookmarks
allowWatchBookmarks запитує події спостереження з типом "BOOKMARK". Сервери, які не реалізують закладки, можуть ігнорувати цей прапорець, і закладки надсилаються на розсуд сервера. Клієнти не повинні припускати, що закладки повертаються через певні інтервали, і не можуть припускати, що сервер надішле будь-яку подію BOOKMARK під час сеансу. Якщо це не спостереження, це поле ігнорується.
continue
Опція continue повинна бути встановлена при отриманні додаткових результатів з сервера. Оскільки це значення визначається сервером, клієнти можуть використовувати значення continue лише з попереднього результату запиту з ідентичними параметрами запиту (за винятком значення continue), і сервер може відхилити значення continue, яке він не розпізнає. Якщо вказане значення continue більше не є дійсним через закінчення терміну дії (зазвичай від п’яти до п’ятнадцяти хвилин) або зміну конфігурації на сервері, сервер відповість помилкою 410 ResourceExpired разом з токеном продовження. Якщо клієнту потрібен узгоджений список, він повинен перезапустити свій список без поля continue. В іншому випадку клієнт може надіслати інший запит списку з токеном, отриманим разом із помилкою 410, сервер відповість списком, починаючи з наступного ключа, але з останнім знімком, який не узгоджується з попередніми результатами списку — об’єкти, які створені, змінені або видалені після першого запиту списку будуть включені у відповідь, якщо їх ключі знаходяться після «наступного ключа».
Це поле не підтримується, коли watch має значення true. Клієнти можуть почати спостереження з останнього значення resourceVersion, повернутого сервером, і не пропустити жодних змін.
dryRun
Якщо присутній, вказує, що зміни не повинні бути збережені. Неправильний або нерозпізнана директива dryRun призведе до помилки та припинення обробки запиту. Дійсні значення:
All: будуть оброблені всі етапи dry run
fieldManager
fieldManager — це імʼя, повʼязане з актором або субʼєктом, який вносить ці зміни. Значення має бути менше або дорівнювати 128 символам і містити лише друковані символи, як визначено https://pkg.go.dev/unicode#IsPrint.
fieldSelector
Селектор для обмеження списку об’єктів, що повертаються, за їх полями. Стандартне значення — все.
fieldValidation
fieldValidation інструктує сервер, як обробляти обʼєкти в запиті (POST/PUT/PATCH), які містять невідомі або дубльовані поля. Дійсні значення:
Ignore: буде ігнорувати будь-які невідомі поля, які тихо видаляються з обʼєкта, і буде ігнорувати всі, крім останнього дубльованого поля, з яким стикається декодер. Це поведінка за замовчуванням до v1.23.
Warn: надішле попередження через стандартний заголовок відповіді про попередження для кожного невідомого поля, яке видаляється з обʼєкта, і для кожного дубльованого поля, з яким стикається. Запит все одно буде успішним, якщо не буде інших помилок, і зберігатиметься лише останнє з будь-яких дубльованих полів. Це стандартне значення у v1.23+
Strict: призведе до помилки BadRequest, якщо будь-які невідомі поля будуть видалені з обʼєкта, або якщо є будь-які дубльовані поля. Помилка, повернена сервером, міститиме всі невідомі та дубльовані поля, з якими стикаються.
force
Force "змушує" застосовувати запити Apply. Це означає, що користувач повторно отримуватиме конфліктні поля, що належать іншим користувачам. Прапорець force має бути скинутий для запитів на патч, які не є apply.
gracePeriodSeconds
Тривалість у секундах до того, як об’єкт повинен бути видалений. Значення має бути додатним цілим числом. Значення нуль вказує на негайне видалення. Якщо це значення є nil, буде використано стандартний період очікування для вказаного типу. Стандартне значення — значення для кожного обʼєкта, якщо не вказано інше. Нуль означає негайне видалення.
labelSelector
Селектор для обмеження списку обʼєктів, що повертаються, за їх мітками. Стандартне значення — все.
limit
limit — це максимальна кількість відповідей, які можна повернути для виклику списку. Якщо елементів більше, сервер встановить поле continue у метаданих списку у значення, яке можна використовувати з тим самим початковим запитом для отримання наступного набору результатів. Встановлення обмеження може повернути менше, ніж запитувана кількість елементів (до нуля елементів), якщо всі запитувані обʼєкти відфільтровані, і клієнти повинні використовувати лише наявність поля continue, щоб визначити, чи доступні додаткові результати. Сервери можуть не підтримувати аргумент limit і повернуть усі доступні результати. Якщо limit вказано, а поле continue порожнє, клієнти можуть припустити, що додаткових результатів немає. Це поле не підтримується, якщо watch має значення true.
Сервер гарантує, що обʼєкти, повернені при використанні continue, будуть ідентичні видачі єдиного виклику списку без обмеження — тобто жодні обʼєкти, створені, змінені або видалені після видачі першого запиту, не будуть включені в жодні подальші запити. Це іноді називають узгодженим знімком і гарантує, що клієнт, який використовує limit для отримання менших частин дуже великого результату, може бути впевнений, що він бачить всі можливі обʼєкти. Якщо обʼєкти оновлюються під час отримання сегментованого списку, повертається версія обʼєкта, яка була присутня на момент розрахунку першого результату списку.
namespace
назва обʼєкта та сфера авторизації, наприклад для команд і проєктів
pretty
Якщо 'true', вивід буде відформатовано з відступами.
propagationPolicy
Чи буде виконуватися і як буде виконуватися збір сміття. Можна встановити це поле або OrphanDependents, але не обидва. Стандартна політика визначається наявним набором завершувачів у metadata.finalizers і стандартною політикою для конкретного ресурсу. Прийнятні значення: 'Orphan' — зробити залежні обʼєкти сиротами; 'Background' — дозволити збирачу сміття видаляти залежні обʼєкти у фоновому режимі; 'Foreground' — політика каскаду, яка видаляє всі залежні обʼєкти явно.
sendInitialEvents=true можна встановити разом із watch=true. У цьому випадку потік спостереження розпочнеться зі штучних подій для створення поточного стану об’єктів у колекції. Після того, як усі такі події будуть надіслані, буде надіслано штучну подію "Bookmark". Закладка повідомить про ResourceVersion (RV), що відповідає набору об’єктів, і буде позначена анотацією "k8s.io/initial-events-end": "true". Після цього потік спостереження продовжуватиметься як зазвичай, надсилаючи події спостереження, що відповідають змінам (після RV) об’єктів, що спостерігаються.
Коли встановлено опцію sendInitialEvents, ми вимагаємо також встановити опцію resourceVersionMatch. Семантика запиту спостереження є такою:
resourceVersionMatch = NotOlderThan інтерпретується як "дані щонайменше такі ж нові, як надані resourceVersion" і подія bookmark надсилається, коли стан синхронізується до resourceVersion принаймні такий свіжий, як той, який надається ListOptions. Якщо resourceVersion не встановлено, це інтерпретується як "послідовне читання", і подія bookmark надсилається, коли стан синхронізується щонайменше до моменту початку обробки запиту.
resourceVersionMatch встановлено на будь-яке інше значення або не встановлено — Повертається помилка Invalid.
Стандартне значення — true, якщо resourceVersion="" або resourceVersion="0" (з міркувань зворотної сумісності) і false в інших випадках.
timeoutSeconds
Тайм-аут для викликів list/watch. Це обмежує тривалість виклику, незалежно від будь-якої активності чи неактивності.
watch
Спостереження за змінами описаних ресурсів і повернення їх у вигляді потоку сповіщень про додавання, оновлення та видалення. Вкажіть resourceVersion.
6 - Інструментування
7 - Безпека та проблеми Kubernetes
8 - Довідкова інформація про вузли
У цьому розділі містяться наступні теми про вузли:
Цей розділ документації Kubernetes містить деталі про використання мережі в Kubernetes.
10 - Інструменти встановлення
11 - Інструмент командного рядка (kubectl)
Kubernetes надає інструмент командного рядка для взаємодії із кластером Kubernetes,
панеллю управління, використовуючи API Kubernetes.
Цей інструмент має назву kubectl.
Для отримання налаштувань kubectl шукає файл config в теці $HOME/.kube. Ви можете вказати інший файл kubeconfig у змінній оточення KUBECONFIG або у значенні ключа --kubeconfig.
Тут ми розглянемо синтаксис команд kubectl, опис операторів та розберемо їх на прикладах. Докладніше про кожну команду, включаючи всі підтримувані прапорці та підкоманди, див. довідкову документацію kubectl.
Інструкції з встановлення знаходяться у статті Встановлення kubectl; короткий посібник є у шпаргалці. Якщо ви звикли користуватись інструмент командного рядка docker, kubectl для користувачів Docker пояснює деякі еквівалентні команди для Kubernetes.
Синтаксис
Використовуйте наступний синтаксис для виконання команд kubectl у вашому терміналі:
kubectl [команда][ТИП][ІМʼЯ][прапорці]
де команда, ТИП, ІМʼЯ та прапорці визначаються наступним чином:
команда: Вказує операцію, яку ви хочете виконати з одним чи кількома ресурсами, наприклад create, get, describe, delete.
ТИП: Вказує тип ресурсу. Типи ресурсів нечутливі до регістру, і можна вказувати форми однини, множини чи абревіатури. Наприклад, наступні команди виводять той самий результат:
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
ІМʼЯ: Вказує імʼя ресурсу. Імена чутливі до регістру. Якщо імʼя відсутнє, виводяться деталі для всіх ресурсів, наприклад kubectl get pods.
При виконанні операції над кількома ресурсами можна вказати кожен ресурс за типом та іменем або вказати один чи кілька файлів:
Щоб вказати ресурси за типом та іменем:
Щоб групувати ресурси, якщо вони всі є тим самим типом: ТИП1 імʼя1 імʼя2 імʼя<#>. Приклад: kubectl get pod example-pod1 example-pod2.
Щоб вказати кілька типів ресурсів окремо: ТИП1/імʼя1 ТИП1/імʼя2 ТИП2/імʼя3 ТИП<#>/імʼя<#>. Приклад: kubectl get pod/example-pod1 replicationcontroller/example-rc1.
Щоб вказати ресурси за допомогою одного чи кількох файлів: -f файл1 -f файл2 -f файл<#>.
Використовуйте YAML замість JSON, оскільки YAML зазвичай є зручнішим для користувача, особливо для файлів конфігурації. Приклад: kubectl get -f ./pod.yaml
прапорці: Є необовʼязковими. Наприклад, ви можете використовувати прапорці -s або --server, щоб вказати адресу та порт сервера API Kubernetes.
Увага:
Прапорці, які ви вказуєте в командному рядку, перевизначають стандартні значення та будь-які відповідні змінні середовища.
Якщо вам потрібна допомога, виконайте команду kubectl help у вікні термінала.
Автентифікація та перевизначення простору імен в кластері
Типово kubectl спочатку визначатиме, чи він виконується в середині Podʼа, і отже, в кластері. Програма починає з перевірки наявності змінних середовища KUBERNETES_SERVICE_HOST та KUBERNETES_SERVICE_PORT, а також наявності файлу токена облікового запису служби за шляхом /var/run/secrets/kubernetes.io/serviceaccount/token. Якщо всі три умови виконуються, вважається, що використовується автентифікація в кластері.
Для забезпечення зворотної сумісності, якщо під час автентифікації в кластері встановлено змінну середовища POD_NAMESPACE, вона перевизначить типовий простір імен скориставшись токеном облікового запису служби. Це буде впливати на будь-які маніфести або інструменти, які покладаються на типовий простір імен.
Змінна середовища POD_NAMESPACE
Якщо змінна середовища POD_NAMESPACE встановлена, операції CLI для ресурсів з обмеженим простором імен будуть отримувати типове значення від цієї змінної. Наприклад, якщо змінна встановлена в seattle, kubectl get pods поверне Podʼи з простору імен seattle. Це тому, що Podʼи є ресурсом з обмеженим простором імен, і ми не вказали команді простір імен в командному рядку. Ознайомтесь з виводом kubectl api-resources, щоб визначити, чи ресурс має обмежений простір імен чи ні.
Явне використання --namespace <value> перевизначає цю поведінку.
Як kubectl обробляє токени ServiceAccount
Якщо:
маємо файл токена облікового запису служби Kubernetes, змонтований за шляхом /var/run/secrets/kubernetes.io/serviceaccount/token, і
встановлено змінну середовища KUBERNETES_SERVICE_HOST, і
встановлено змінну середовища KUBERNETES_SERVICE_PORT, і
ви не вказуєте простір імен явно в командному рядку kubectl
тоді kubectl вважатиме, що він працює в вашому кластері. Інструмент kubectl знаходить простір імен цього облікового запису служби (це такий самий простір імен, що й у Podʼа) та діє відповідно до цього простору імен. Це відрізняється від того, що відбувається поза кластером; коли kubectl працює за межами кластера і ви не вказуєте простір імен, команда kubectl діє в просторі імен, встановленому для поточного контексту у вашій конфігурації клієнта. Щоб змінити типовий простір імен для kubectl, ви можете використовувати наступну команду:
Отримати документацію про різні ресурси, такі як Podʼи, вузли, служби і т. д.
expose
kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]
Надати доступ ззовні до контролеру реплікації, Service або Pod, як до нового Service Kubernetes.
get
kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]
Вивести список ресурсів.
kustomize
kubectl kustomize <dir> [flags] [options]
Вивести список ресурсів API, згенерованих з інструкцій у файлі kustomization.yaml. Аргумент повинен бути шляхом до теки, що містить файл, або URL репозиторію git з суфіксом шляху, який вказує на те ж саме відносно кореня репозиторію.
label
kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]
Додати або оновити мітки одного чи кількох ресурсів.
logs
kubectl logs POD [-c CONTAINER] [--follow] [flags]
Вивести логи контейнера у Podʼі.
options
kubectl options
Список глобальних параметрів командного рядка, які застосовуються до всіх команд.
patch
kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]
Оновити одне чи кілька полів ресурсу за допомогою процесу стратегічного обʼєднання патчів.
plugin
kubectl plugin [flags] [options]
Надає інструменти для взаємодії з втулками.
port-forward
kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]
Переспрямувати один або декілька локальних портів у Pod.
Експериментально: чекати на певний стан одного чи кількох ресурсів.
Щоб дізнатися більше про операції, що виконують команди, див. довідку kubectl.
Типи ресурсів
У наступній таблиці наведено список всіх підтримуваних типів ресурсів та їх скорочених аліасів.
(Цей вивід можна отримати за допомогою kubectl api-resources і був актуальним на момент Kubernetes 1.25.0)
ІМʼЯ
СКОРОЧЕННЯ
ВЕРСІЯ API
ВИМІРЮВАНИЙ
ТИП
bindings
v1
true
Binding
componentstatuses
cs
v1
false
ComponentStatus
configmaps
cm
v1
true
ConfigMap
endpoints
ep
v1
true
Endpoints
events
ev
v1
true
Event
limitranges
limits
v1
true
LimitRange
namespaces
ns
v1
false
Namespace
nodes
no
v1
false
Node
persistentvolumeclaims
pvc
v1
true
PersistentVolumeClaim
persistentvolumes
pv
v1
false
PersistentVolume
pods
po
v1
true
Pod
podtemplates
v1
true
PodTemplate
replicationcontrollers
rc
v1
true
ReplicationController
resourcequotas
quota
v1
true
ResourceQuota
secrets
v1
true
Secret
serviceaccounts
sa
v1
true
ServiceAccount
services
svc
v1
true
Service
mutatingwebhookconfigurations
admissionregistration.k8s.io/v1
false
MutatingWebhookConfiguration
validatingwebhookconfigurations
admissionregistration.k8s.io/v1
false
ValidatingWebhookConfiguration
customresourcedefinitions
crd,crds
apiextensions.k8s.io/v1
false
CustomResourceDefinition
apiservices
apiregistration.k8s.io/v1
false
APIService
controllerrevisions
apps/v1
true
ControllerRevision
daemonsets
ds
apps/v1
true
DaemonSet
deployments
deploy
apps/v1
true
Deployment
replicasets
rs
apps/v1
true
ReplicaSet
statefulsets
sts
apps/v1
true
StatefulSet
tokenreviews
authentication.k8s.io/v1
false
TokenReview
localsubjectaccessreviews
authorization.k8s.io/v1
true
LocalSubjectAccessReview
selfsubjectaccessreviews
authorization.k8s.io/v1
false
SelfSubjectAccessReview
selfsubjectrulesreviews
authorization.k8s.io/v1
false
SelfSubjectRulesReview
subjectaccessreviews
authorization.k8s.io/v1
false
SubjectAccessReview
horizontalpodautoscalers
hpa
autoscaling/v2
true
HorizontalPodAutoscaler
cronjobs
cj
batch/v1
true
CronJob
jobs
batch/v1
true
Job
certificatesigningrequests
csr
certificates.k8s.io/v1
false
CertificateSigningRequest
leases
coordination.k8s.io/v1
true
Lease
endpointslices
discovery.k8s.io/v1
true
EndpointSlice
events
ev
events.k8s.io/v1
true
Event
flowschemas
flowcontrol.apiserver.k8s.io/v1beta2
false
FlowSchema
prioritylevelconfigurations
flowcontrol.apiserver.k8s.io/v1beta2
false
PriorityLevelConfiguration
ingressclasses
networking.k8s.io/v1
false
IngressClass
ingresses
ing
networking.k8s.io/v1
true
Ingress
networkpolicies
netpol
networking.k8s.io/v1
true
NetworkPolicy
runtimeclasses
node.k8s.io/v1
false
RuntimeClass
poddisruptionbudgets
pdb
policy/v1
true
PodDisruptionBudget
podsecuritypolicies
psp
policy/v1beta1
false
PodSecurityPolicy
clusterrolebindings
rbac.authorization.k8s.io/v1
false
ClusterRoleBinding
clusterroles
rbac.authorization.k8s.io/v1
false
ClusterRole
rolebindings
rbac.authorization.k8s.io/v1
true
RoleBinding
roles
rbac.authorization.k8s.io/v1
true
Role
priorityclasses
pc
scheduling.k8s.io/v1
false
PriorityClass
csidrivers
storage.k8s.io/v1
false
CSIDriver
csinodes
storage.k8s.io/v1
false
CSINode
csistoragecapacities
storage.k8s.io/v1
true
CSIStorageCapacity
storageclasses
sc
storage.k8s.io/v1
false
StorageClass
volumeattachments
storage.k8s.io/v1
false
VolumeAttachment
Параметри виводу
Використовуйте наступні розділи для отримання інформації про те, як ви можете форматувати або сортувати вивід деяких команд. Докладні відомості щодо команд, які підтримують різні параметри виводу, див. в документації по kubectl.
Форматування виводу
Стандартний формат виводу для всіх команд kubectl – це читабельний текстовий формат. Щоб вивести деталі у вашому терміналі у певному форматі, ви можете додати параметр -o або --output до підтримуваної команди kubectl.
Синтаксис
kubectl [команда][ТИП][ІМʼЯ] -o <формат_виводу>
Залежно від операції kubectl, підтримуються наступні формати виводу:
Формат виводу
Опис
-o custom-columns=<специфікація>
Вивести таблицю, використовуючи розділений комою список власних стовпців.
-o custom-columns-file=<імʼя_файлу>
Вивести таблицю, використовуючи шаблон власних стовпців у файлі <імʼя_файлу>.
Вивести поля, визначені в виразі jsonpath у файлі <імʼя_файлу>.
-o name
Вивести лише імʼя ресурсу і нічого більше.
-o wide
Вивести у текстовому форматі з будь-якою додатковою інформацією. Для Pod включно з імʼям вузла.
-o yaml
Вивести обʼєкт API у форматі YAML.
Приклад
Тут наступна команда виводить інформацію про Pod у форматі YAML:
kubectl get pod web-pod-13je7 -o yaml
Нагадування: Дивіться довідку kubectl для отримання деталей щодо підтримуваних форматів виводу для кожної команди.
Власні стовпці
Щоб визначити власні стовпці та виводити лише ті деталі, які вам потрібні у вигляді таблиці, ви можете використовувати опцію custom-columns. Ви можете вибрати визначення спеціальних стовпців під час складення параметрів команди або використовувати файл шаблону: -o custom-columns=<spec> або -o custom-columns-file=<filename>.
Приклади
З використанням параметрів в командному рядку:
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
З використанням файлу шаблону template.txt:
kubectl get pods <pod-name> -o custom-columns-file=template.txt
де template.txt містить:
NAME RSRC
metadata.name metadata.resourceVersion
Результати виводу будуть виглядати як для використання шаблону, так і для параметрів командного рядка, як:
NAME RSRC
submit-queue 610995
Стовпці на стороні сервера
kubectl підтримує отримання конкретної інформації в стовпці щодо обʼєктів від сервера. Це означає, що для будь-якого заданого ресурсу сервер поверне стовпці та рядки, що стосуються цього ресурсу, для показу його клієнту. Це дозволяє отримати послідовний, зручний для читання вивід для різних клієнтів, які використовуються для одного і того ж кластера, оскільки сервер ізолює деталі виведення.
Ця функція стандартно увімкнена. Щоб вимкнути її, додайте прапорець --server-print=false до команди kubectl get.
Приклади
Щоб вивести інформацію про стан Podʼа, використовуйте команду на зразок наступної:
kubectl get pods <pod-name> --server-print=false
Вивід буде подібний до:
NAME AGE
pod-name 1m
Сортування списку обʼєктів
Щоб вивести обʼєкти в відсортованому списку у вашому вікні термінала, ви можете додати прапорець --sort-by до команди kubectl. Впорядкуйте ваші обʼєкти, вказавши будь-яке числове чи рядкове поле з прапорцем --sort-by. Для вказання поля використовуйте вираз jsonpath.
Щоб вивести список Podʼів, відсортованих за назвами, зробіть наступне:
kubectl get pods --sort-by=.metadata.name
Приклади: Загальні операції
Використовуйте цей набір прикладів, щоб ознайомитися з тим, як використовувати найпоширеніші операції kubectl:
kubectl apply — Застосувати або оновити ресурс із файлу чи stdin.
# Створити службу, використовуючи визначення у файлі example-service.yaml.kubectl apply -f example-service.yaml
# Створити контролер реплікації, використовуючи визначення у файлі example-controller.yaml.kubectl apply -f example-controller.yaml
# Створити обʼєкти, які визначені у файлах з розширеннями .yaml, .yml, або .json у теці <directory>.kubectl apply -f <directory>
kubectl get — Показати відомості про один чи кілька ресурсів.
# Показати всі Podʼі у форматі звичайного тексту.kubectl get pods
# Показати всі Podʼі у форматі звичайного тексту та додаткову інформацію (наприклад, імʼя вузла).kubectl get pods -o wide
# Показати контролер реплікації із вказаним імʼям у форматі звичайного тексту. Порада: Ви можете скоротити та замінити тип ресурсу 'replicationcontroller' на скорочену назву 'rc'.kubectl get replicationcontroller <rc-name>
# Показати всі контролери реплікації та служби разом у форматі звичайного тексту.kubectl get rc,services
# Показати всі daemonsets у форматі звичайного тексту.kubectl get ds
# Показати всі Podʼи, які працюють на вузлі server01kubectl get pods --field-selector=spec.nodeName=server01
kubectl describe — Показати детальний стан одного чи кількох ресурсів, включаючи ті, які ще не ініціалізовані.
# Показати деталі вузла із ім'ям <node-name>.kubectl describe nodes <node-name>
# Показати деталі Podʼу із ім'ям <pod-name>.kubectl describe pods/<pod-name>
# Показати деталі всіх Podʼів, які керуються контролером реплікації із вказаним ім'ям <rc-name>.# Памʼятайте: Будь-які Podʼи, які створює контролер реплікації, отримують префікс із імʼям контролера реплікації.kubectl describe pods <rc-name>
# Показати всі Podʼиkubectl describe pods
Примітка:
Команда kubectl get зазвичай використовується для отримання одного чи кількох ресурсів того ж типу ресурсу. Вона має багатий набір прапорців, що дозволяють налаштовувати формат виводу за допомогою прапорця -o або --output, наприклад. Ви можете вказати прапорець -w або --watch, щоб почати слідкування за оновленнями для певного обʼєкта. Команда kubectl describe більше фокусується на описі багатьох повʼязаних аспектів вказаного ресурсу. Вона може робити кілька викликів до API-сервера для побудови виводу для користувача. Наприклад, команда kubectl describe node отримує не тільки інформацію про вузол, але й підсумок Podʼів, які працюють на ньому, події, створені для вузла, і т. д.
kubectl delete — Видалити ресурси або з використанням файлу, або з stdin, або вказавши селектори міток, імена, селектори ресурсів чи самі ресурси.
# Видалити Pod, використовуючи тип та імʼя, вказане у файлі pod.yaml.kubectl delete -f pod.yaml
# Видалити всі Podʼи та служби із міткою '<label-key>=<label-value>'.kubectl delete pods,services -l <label-key>=<label-value>
# Видалити всі Podʼи, включаючи неініціалізовані.kubectl delete pods --all
kubectl exec — Виконати команду у контейнері Podʼу.
# Отримати вивід виконання команди 'date' у Podʼі <pod-name>. Типово вивід виконується з першого контейнера.kubectl exec <pod-name> -- date
# Отримати вивід виконання команди 'date' у контейнері <container-name> Podʼу <pod-name>.kubectl exec <pod-name> -c <container-name> -- date
# Отримати інтерактивний TTY та виконати /bin/bash у Podʼі <pod-name>. Типово вивід виконується з першого контейнера.kubectl exec -ti <pod-name> -- /bin/bash
kubectl logs — Вивести логи для контейнера у Podʼі.
# Отримати логи із Podʼу <pod-name>.kubectl logs <pod-name>
# Почати виведення логів у режимі стрічки із Podʼу <pod-name>. Це схоже на команду 'tail -f' у Linux.kubectl logs -f <pod-name>
kubectl diff — Переглянути відмінності запропонованих оновлень кластера.
# Відмінності ресурсів, включених у "pod.json".kubectl diff -f pod.json
# Відмінності, отримані з stdin.cat service.yaml | kubectl diff -f -
Приклади: Створення та використання втулків
Використовуйте цей набір прикладів, щоб ознайомитися із написанням та використанням втулків kubectl:
# створіть простий втулок будь-якою мовою та зробить файл виконуваним# так, щоб він починався префіксом "kubectl-"cat ./kubectl-hello
#!/bin/sh
# цей втулок виводить слова "hello world"echo"hello world"
Дайте втулку права на виконання:
chmod a+x ./kubectl-hello
# та перемістіть його в місце, яке є у вашому шляху (PATH)sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# Ви зараз створили та "встановили" втулок kubectl.# Ви можете почати використовувати цей втулок, викликаючи його з kubectl, # ніби це звичайна командаkubectl hello
hello world
# Ви можете "вилучити" втулок, видаливши його з теки у вашому# $PATH, де ви його розмістилиsudo rm /usr/local/bin/kubectl-hello
Щоб переглянути всі втулки, доступні для kubectl, використовуйте команду kubectl plugin list:
kubectl plugin list
Вивід буде схожий на:
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
kubectl plugin list також попереджає вас про втулки, які не мають прав на виконання, або які перекриваються з іншими втулками; наприклад:
sudo chmod -x /usr/local/bin/kubectl-foo # вилучити права виконанняkubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- попередження: /usr/local/bin/kubectl-foo визначено як втулок, але він не є виконавчим
/usr/local/bin/kubectl-bar
error: one plugin warning was found
Ви можете думати про втулки як про можливість будувати більш складні функції на основі наявних команд kubectl:
cat ./kubectl-whoami
Наступні кілька прикладів передбачають, що ви вже зробили так, що kubectl-whoami має наступний вміст:
#!/bin/bash
# цей втулок використовує команду `kubectl config` для виведення# інформації про поточного користувача, на основі вибраного контекстуkubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
Запуск вищезазначеної команди дає вам вивід із зазначенням користувача для поточного контексту у вашому файлі KUBECONFIG:
# зробіть файл виконавчимsudo chmod +x ./kubectl-whoami
# та перемістіть його у ваш шлях (PATH)sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
Для отримання додаткової інформації про втулки, подивіться приклад CLI-втулка.
12 - Відлагодження кластера
13 - Компонентні інструменти
13.1 - Feature Gates
This page contains an overview of the various feature gates an administrator
can specify on different Kubernetes components.
See feature stages for an explanation of the stages for a feature.
Overview
Feature gates are a set of key=value pairs that describe Kubernetes features.
You can turn these features on or off using the --feature-gates command line flag
on each Kubernetes component.
Each Kubernetes component lets you enable or disable a set of feature gates that
are relevant to that component.
Use -h flag to see a full set of feature gates for all components.
To set feature gates for a component, such as kubelet, use the --feature-gates
flag assigned to a list of feature pairs:
--feature-gates=...,GracefulNodeShutdown=true
The following tables are a summary of the feature gates that you can set on
different Kubernetes components.
The "Since" column contains the Kubernetes release when a feature is introduced
or its release stage is changed.
The "Until" column, if not empty, contains the last Kubernetes release in which
you can still use a feature gate.
The feature is well tested. Enabling the feature is considered safe.
Support for the overall feature will not be dropped, though details may change.
The schema and/or semantics of objects may change in incompatible ways in a
subsequent beta or stable release. When this happens, we will provide instructions
for migrating to the next version. This may require deleting, editing, and
re-creating API objects. The editing process may require some thought.
This may require downtime for applications that rely on the feature.
Recommended for only non-business-critical uses because of potential for
incompatible changes in subsequent releases. If you have multiple clusters
that can be upgraded independently, you may be able to relax this restriction.
Примітка:
Please do try Beta features and give feedback on them!
After they exit beta, it may not be practical for us to make more changes.
A General Availability (GA) feature is also referred to as a stable feature. It means:
The feature is always enabled; you cannot disable it.
The corresponding feature gate is no longer needed.
Stable versions of features will appear in released software for many subsequent versions.
List of feature gates
Each feature gate is designed for enabling/disabling a specific feature.
InPlacePodVerticalScaling: Дозволяє вертикальне масштабування Podʼів на місці.
Що далі
The deprecation policy for Kubernetes explains
the project's approach to removing features and components.
Since Kubernetes 1.24, new beta APIs are not enabled by default. When enabling a beta
feature, you will also need to enable any associated API resources.
For example, to enable a particular resource like
storage.k8s.io/v1beta1/csistoragecapacities, set --runtime-config=storage.k8s.io/v1beta1/csistoragecapacities.
See API Versioning for more details on the command line flags.
14 - Конфігураційні API
15 - Зовнішні API
16 - Планування
17 - Інші інструменти
Kubernetes містить кілька інструментів, які допоможуть вам працювати з системою Kubernetes.
crictl
crictl — це інтерфейс командного рядка для перегляду та відлагодження оточення виконання контейнерів, сумісних з CRI.
Dashboard
Dashboard, вебінтерфейс Kubernetes, дозволяє розгортати контейнерні застосунки в кластері Kubernetes, розвʼязувати проблеми з ними та управляти кластером та його ресурсами.
Helm
🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes. Докладніше
Helm — це інструмент для управління пакунками наперед сконфігурованих ресурсів Kubernetes. Ці пакунки відомі як Helm charts.
Використовуйте Helm для:
Пошуку та використання популярного програмного забезпечення, упакованого як Helm charts для Kubernetes
Поширення ваших застосунків у вигляді Helm charts
Створення відтворюваних збірок вашого застосунку Kubernetes
Управління файлами маніфестів Kubernetes
Управління випусками пакунків Helm
Kompose
Kompose — це інструмент для допомоги користувачам Docker Compose в переході до Kubernetes.
Використовуйте Kompose для:
Перетворення файлу Docker Compose в обʼєкти Kubernetes
Переходу від локальної розробки Docker до управління вашим застосунком через Kubernetes
Kui — це графічний інструмент, який обробляє ваші звичайні запити командного рядка kubectl та показує вивід в графічному вигляді.
Kui обробляє звичайні запити командного рядка kubectl та показує вивід в графічному вигляді. Замість ASCII-таблиць, Kui надає графічний рендеринг з таблицями, які можна сортувати.
Kui дозволяє вам:
Натискати на довгі, автоматично генеровані назви ресурсів, замість копіювання та вставляння
Вводити команди kubectl і бачити їх виконання, іноді навіть швидше, ніж в kubectl
Запитувати Job та бачити його виконання у вигляді діаграми водоспаду
Переходити за ресурсами в вашому кластері за допомогою графічного інтерфейсу користувача
Minikube
minikube — це інструмент, який запускає локальний однокомпонентний кластер Kubernetes безпосередньо на вашому компʼютері для розробки та тестування.
