Це багатосторінковий друкований вигляд цього розділу. Натисність щоб друкувати.

Повернутися до звичайного перегляду сторінки.

Довідник

Цей розділ документації Kubernetes містить довідники.

Довідники API

Офіційно підтримувані клієнтські бібліотеки

Для надсилання викликів до API Kubernetes використовуючи одну з мов програмування ви можете використовувати клієнтські бібліотеки. Офіційно підтримуються наступні:

CLI

  • kubectl — Основний інструмент командного рядка для виконання команд та управління кластерами Kubernetes.
    • JSONPath — Посібник з синтаксису використання виразів JSONPath з kubectl.
  • kubeadm — Інструмент командного рядка для легкого налаштування захищеного кластера Kubernetes.

Компоненти

  • kubelet — Основний агент, який працює на кожному вузлі. Kubelet отримує набір PodSpecs і переконується, що описані контейнери працюють і є справними.

  • kube-apiserver — REST API, що перевіряє та налаштовує дані для обʼєктів API, таких як Podʼи, Serviceʼи, контролери реплікацій.

  • kube-controller-manager — Демон, який містить основні процеси управління, які постачаються з Kubernetes.

  • kube-proxy — Може виконувати просте перенаправлення потоку TCP/UDP або перенаправляти потік TCP/UDP методом "round-robin" через набір бекендів.

  • kube-scheduler — Планувальник, який керує доступністю, продуктивністю та місткістю.

  • Список портів та протоколів, які повинні бути відкриті на вузлах панелі управління та робочих вузлах.

Конфігураційні API

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

Конфігураційні API kubeadm

Зовнішні API

Ці API, визначені проєктом Kubernetes, але не реалізовані в межах основного проєкту:

Документи проєктування

Архів документів проєктування функціонала Kubernetes. Ви можете розпочати з

1 - Глосарій

2 - Огляд API

Цей розділ містить довідкову інформацію про API Kubernetes.

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

Довідник API Kubernetes містить список API для версії Kubernetes v1.31.

Для отримання загальної інформації, читайте 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

Збереження

Kubernetes зберігає свій серіалізований стан у термінах ресурсів API, записуючи їх в etcd.

Що далі

2.1 - Концепції API Kubernetes

API Kubernetes — це програмний інтерфейс на основі ресурсів (RESTful), який надається через HTTP. Він підтримує отримання, створення, оновлення та видалення основних ресурсів за допомогою стандартних HTTP-дієслів (POST, PUT, PATCH, DELETE, GET).

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

Kubernetes підтримує ефективні сповіщення про зміни ресурсів за допомогою watches.

В API Kubernetes, watch це дієслово, яке використовується для відстеження змін обʼєкта в Kubernetes у вигляді потоку. Використовується для ефективного виявлення змін.

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.

Приклади:

  • /api/v1/namespaces
  • /api/v1/pods
  • /api/v1/namespaces/my-namespace/pods
  • /apis/apps/v1/deployments
  • /apis/apps/v1/namespaces/my-namespace/deployments
  • /apis/apps/v1/namespaces/my-namespace/deployments/my-deployment

Ви також можете отримати доступ до колекцій ресурсів (наприклад, переліку усіх 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 для отримання додаткової інформації. Немає можливості отримати доступ до субресурсів через декілька ресурсів — зазвичай використовується новий віртуальний тип ресурсу, якщо це стає необхідним.

HTTP медіа-типи

Kubernetes підтримує кодування JSON та Protobuf для передачі даних по HTTP.

Стандартно, Kubernetes повертає серіалізовані об’єкти JSON, використовуючи медіа-тип application/json. Хоча JSON є стандартним типом, клієнти можуть запитувати відповідь у форматі YAML, або більш ефективне двійкове подання у вигляді Protobuf для кращої продуктивності.

Kubernetes API реалізує стандартне узгодження типів вмісту HTTP: передача заголовка Accept у запиті GET вказує серверу спробувати повернути відповідь у бажаному медіа-типі. Якщо ви хочете надіслати об’єкт у форматі Protobuf на сервер для запиту PUT або POST, вам необхідно відповідно встановити заголовок запиту Content-Type.

Якщо ви запитуєте доступні медіа-типи, API-сервер повертає відповідь з відповідним заголовком Content-Type; якщо жоден із запитаних медіа-типів не підтримується, API-сервер поверне повідомлення про помилку 406 Not acceptable. Усі вбудовані типи ресурсів підтримують медіа-тип application/json.

Кодування ресурсів у форматі JSON

API Kubernetes стандартно використовує JSON для кодування тіла HTTP повідомлень.

Наприклад:

  1. Вивести список усіх Podʼів в кластері без вказування бажаного формату

    GET /api/v1/pods

    200 OK
Content-Type: application/json

… Колекція Pod, закодована у форматі JSON (обʼєкт PodList)

  2. Створити Pod, відправивши JSON на сервер та запросивши відповідь у форматі JSON.

    POST /api/v1/namespaces/test/pods
Content-Type: application/json
Accept: application/json
… Обʼєкт Pod, закодований у форматі JSON

    200 OK
Content-Type: application/json

{
  "kind": "Pod",
  "apiVersion": "v1",
  …
}

Кодування ресурсів у YAML

Kubernetes також підтримує медіатип application/yaml для запитів та відповідей. YAML може використовуватись для визначення маніфестів Kubernetes та взаємодії з API.

Наприклад:

  1. Отримати список усіх podʼів у кластері у форматі YAML

    GET /api/v1/pods
Accept: application/yaml

    200 OK
Content-Type: application/yaml

… YAML-кодована колекція Podʼів (обʼєкт PodList)

  2. Створити pod, надіславши дані у форматі YAML на сервер і запросивши відповідь у форматі YAML:

    POST /api/v1/namespaces/test/pods
Content-Type: application/yaml
Accept: application/yaml
… YAML-кодований об'єкт Pod

    200 OK
Content-Type: application/yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  …

Кодування Kubernetes Protobuf

Kubernetes використовує обгортку-конверт для кодування відповідей у форматі Protobuf. Ця обгортка починається з 4 байтів магічного числа, щоб допомогти ідентифікувати вміст на диску або в etcd як Protobuf (на відміну від JSON). Дані з магічним числом (4 байти) слідують за повідомленням, закодованим у форматі Protobuf, яке описує кодування та тип основного об’єкта. Усередині повідомлення Protobuf дані внутрішнього об’єкта записуються за допомогою поля raw Unknown (дивіться IDL для докладної інформації).

Наприклад:

  1. Вивести список усіх Pod в кластері у форматі Protobuf.

    GET /api/v1/pods
Accept: application/vnd.kubernetes.protobuf

    200 OK
Content-Type: application/vnd.kubernetes.protobuf

… Колекція Pod, закодована у форматі JSON (об'єкт PodList)

  2. Створити Pod, відправивши дані, закодовані у форматі Protobuf на сервер, але запросити відповідь у форматі JSON.

    POST /api/v1/namespaces/test/pods
Content-Type: application/vnd.kubernetes.protobuf
Accept: application/json
… двійково закодований обʼєкт Pod
---
200 OK
Content-Type: application/json

{
  "kind": "Pod",
  "apiVersion": "v1",
  ...
}

Ви можете використовувати обидві техніки разом і взаємодіяти з API Kubernetes, яке підтримує кодування Protobuf, для читання та запису даних. Лише деякі типи ресурсів API є сумісними з Protobuf.

Формат обгортки:

Чотирибайтовий префікс магічного числа:
  Байти 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00]

Закодоване повідомлення Protobuf з наступним IDL:
  message Unknown {
    // typeMeta повинне містити значення рядків для "kind" та "apiVersion", як встановлено в обʼєкті
    JSON optional TypeMeta typeMeta = 1;

    // raw містить повний серіалізований обʼєкт у форматі protobuf.
    // Дивіться визначення protobuf у клієнтських бібліотеках для конкретного виду.
    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;
  }

Сумісність із Kubernetes Protobuf

Не всі типи ресурсів API підтримують кодування Kubernetes у форматі Protobuf; зокрема, Protobuf не доступний для ресурсів, які визначені як CustomResourceDefinitions або надаються через шар агрегації.

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

Accept: application/vnd.kubernetes.protobuf, application/json

Ефективне виявлення змін

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 і розпочати знову. Див. Семантика версій ресурсів для отримання детальнішої інформації.

Наприклад:

  1. Отримання списку всіх Podʼів у вказаному просторі імен.

    GET /api/v1/namespaces/test/pods
---
200 OK
Content-Type: application/json

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {"resourceVersion":"10245"},
  "items": [...]
}

  2. Починаючи з версії ресурсу 10245, отримуйте сповіщення про будь-які операції API (такі як create, delete, patch або update), що впливають на Podʼи у просторі імен test. Кожне сповіщення про зміну — це документ JSON. Тіло відповіді HTTP (надається як application/json) складається із серії документів JSON.

    GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245
---
200 OK
Transfer-Encoding: chunked
Content-Type: application/json

{
  "type": "ADDED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
}
{
  "type": "MODIFIED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "11020", ...}, ...}
}
...

Сервер 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. Наприклад:

GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
---
200 OK
Transfer-Encoding: chunked
Content-Type: application/json

{
  "type": "ADDED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
}
...
{
  "type": "BOOKMARK",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }
}

Як клієнт, ви можете запитувати події BOOKMARK, встановлюючи параметр запиту allowWatchBookmarks=true у запиті watch, але не слід припускати, що закладки будуть повертатися з певним інтервалом, і клієнти не можуть очікувати, що сервер API надішле будь-яку подію BOOKMARK, навіть якщо її було запитано.

Потокові списки

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [alpha] (стандартно увімкнено: false)

У великих кластерах отримання колекції деяких типів ресурсів може призвести до значного збільшення використання ресурсів (переважно 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=) може призвести до наступної послідовності подій:

GET /api/v1/namespaces/test/pods?watch=1&sendInitialEvents=true&allowWatchBookmarks=true&resourceVersion=&resourceVersionMatch=NotOlderThan
---
200 OK
Transfer-Encoding: chunked
Content-Type: application/json

{
  "type": "ADDED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "8467", "name": "foo"}, ...}
}
{
  "type": "ADDED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "5726", "name": "bar"}, ...}
}
{
  "type": "BOOKMARK",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10245"} }
}
...
<далі йде звичайний потік спостереження, починаючи з resourceVersion="10245">

Стиснення відповідей

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.16 [beta] (стандартно увімкнено: true)

Опція 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] (стандартно увімкнено: true)

У великих кластерах отримання колекції деяких типів ресурсів може призвести до дуже великих відповідей, що може вплинути на сервер та клієнта. Наприклад, у кластері може бути десятки тисяч 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ʼів за раз, запитуйте ці частини наступним чином:

  1. Отримати всі Podʼи в кластері, отримуючи до 500 Podʼів за раз.

    GET /api/v1/pods?limit=500
---
200 OK
Content-Type: application/json

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion":"10245",
    "continue": "ENCODED_CONTINUE_TOKEN",
    "remainingItemCount": 753,
    ...
  },
  "items": [...] // повертає Podʼи 1-500
}

  2. Продовжити попередній запит, отримуючи наступний набір з 500 Podʼів.

    GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN
---
200 OK
Content-Type: application/json

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion":"10245",
    "continue": "ENCODED_CONTINUE_TOKEN_2",
    "remainingItemCount": 253,
    ...
  },
  "items": [...] // повертає Podʼи 501-1000
}

  3. Продовжити попередній запит, отримуючи останні 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. Наприклад:

GET /api/v1/services

{
  "kind": "ServiceList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "2947301"
  },
  "items": [
    {
      "metadata": {
        "name": "kubernetes",
        "namespace": "default",
...
      "metadata": {
        "name": "kube-dns",
        "namespace": "kube-system",
...

Є десятки типів колекцій (таких як PodList, ServiceList та NodeList), визначених в API Kubernetes. Ви можете отримати більше інформації про кожен тип колекції з довідника Kubernetes API.

Деякі інструменти, такі як kubectl, представляють механізм колекцій Kubernetes трохи інакше, ніж сам API Kubernetes. Оскільки вихідні дані kubectl можуть включати відповідь з декількох операцій list на рівні API, kubectl представляє список елементів, використовуючи kind: List. Наприклад:

kubectl get services -A -o yaml

apiVersion: v1
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
items:
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: "2021-06-03T14:54:12Z"
    labels:
      component: apiserver
      provider: kubernetes
    name: kubernetes
    namespace: default
...
- apiVersion: v1
  kind: Service
  metadata:
    annotations:
      prometheus.io/port: "9153"
      prometheus.io/scrape: "true"
    creationTimestamp: "2021-06-03T14:54:14Z"
    labels:
      k8s-app: kube-dns
      kubernetes.io/cluster-service: "true"
      kubernetes.io/name: CoreDNS
    name: kube-dns
    namespace: kube-system

Отримання ресурсів у вигляді таблиць

Коли ви запускаєте 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 ресурсу.

GET /apis/crd.example.com/v1alpha1/namespaces/default/resources
---
200 OK
Content-Type: application/json
...

{
    "kind": "Table",
    "apiVersion": "meta.k8s.io/v1",
    ...
    "columnDefinitions": [
        {
            "name": "Name",
            "type": "string",
            ...
        },
        {
            "name": "Created At",
            "type": "date",
            ...
        }
    ]
}

Не всі типи ресурсів API підтримують табличну відповідь; наприклад, CustomResourceDefinitions можуть не визначати відповідність полів таблиці, а APIService, що розширює основний API Kubernetes може взагалі не обслуговувати табличні відповіді. Якщо ви створюєте клієнта, що використовує інформацію з таблиці та який повинен працювати з усіма типами ресурсів, включаючи розширення, ви повинні робити запити, які вказують кілька типів контенту у заголовку Accept. Наприклад:

Accept: application/json;as=Table;g=meta.k8s.io;v=v1, application/json

Видалення ресурсів

Коли ви видаляєте ресурс, цей процес проходить у два етапи:

  1. Завершення (finalization)
  2. Видалення (removal)
{
  "kind": "ConfigMap",
  "apiVersion": "v1",
  "metadata": {
    "finalizers": ["url.io/neat-finalization", "other-url.io/my-finalizer"],
    "deletionTimestamp": null,
  }
}

Коли клієнт вперше надсилає запит на видалення ресурсу, .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-запиті.

Ці ситуації такі:

  1. Поле не розпізнається, оскільки воно не входить до схеми OpenAPI ресурсу. (Одним винятком є CRDs, які явно обирають не обрізати невідомі поля через x-kubernetes-preserve-unknown-fields).
  2. Поле дублюється в обʼєкті.

Валідація для нерозпізнаних або дубльованих полів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [stable] (стандартно увімкнено: true)

З версії 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.

Інструменти, які надсилають запити на сервер (такі як kubectl), можуть встановлювати свої власні типові значення, які відрізняються від рівня валідації Warn, що стандартно використовується сервером API.

Інструмент kubectl використовує прапорець --validate для встановлення рівня валідації полів. Він приймає значення ignore, warn та strict, а також приймає значення true (еквівалентно strict) і false (еквівалентно ignore). Станадртне налаштування валідації для kubectl — це --validate=true, що означає сувору валідацію полів на стороні сервера.

Коли kubectl не може підключитися до сервера API з валідацією полів (сервери API до Kubernetes 1.27), він повернеться до використання валідації на стороні клієнта. Валідація на стороні клієнта буде повністю видалена у майбутній версії kubectl.

Dry-run

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable] (стандартно увімкнено: true)

При використанні 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.

Приклад 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: фіксує час створення/видалення
  • UID: унікально ідентифікує обʼєкт і генерується випадково (недетерміновано)
  • resourceVersion: відстежує збережену версію обʼєкта
  • Будь-яке поле, встановлене мутаційним контролером допуску
  • Для ресурсу 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:

rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["patch"]

Дивіться Огляд авторизації.

Оновлення наявних ресурсів

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 дозволяє панелі управління відстежувати керовані поля для новостворених обʼєктів. SСерверне застосування забезпечує чітку схему для управління конфліктами полів, пропонує серверні операції apply і update, та замінює функціональність на стороні клієнта kubectl apply.

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

Дивіться Серверне застосування для отримання додаткової інформації.

Вибір механізму оновлення

HTTP PUT для заміни наявного ресурсу

Операція оновлення (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=Exactlimit не встановленоНедійснийНедійснийExact
resourceVersionMatch=Exactlimit=<n>, continue не встановленоНедійснийНедійснийExact
resourceVersionMatch=NotOlderThanlimit не встановленоНедійснийAnyNotOlderThan
resourceVersionMatch=NotOlderThanlimit=<n>, continue не встановленоНедійснийAnyNotOlderThan

Сенс семантики операцій get та list такий:

Any
Повернути дані на будь-якій версії ресурсу. Вибирається найновіша доступна версія ресурсу, але не потрібна сильна консистентність; дані на будь-якій версії ресурсу можуть бути обслуговані. Є можливість отримати дані на значно старішій версії ресурсу, яку клієнт раніше спостерігав, особливо в конфігураціях високої доступності через розділи або застарілі кеші. Клієнти, які не можуть терпіти це, не повинні використовувати цю семантику.
Найновіший
Повернути дані на найновішій версії ресурсу. Повернені дані повинні бути консистентними (детально: обслуговуються з etcd за допомогою кворумного читання). Для etcd версій v3.4.31+ та v3.5.13+ Kubernetes 1.31 обслуговує "найсвіжіші" читання з watch cache: внутрішнього, вбудованого в памʼять сховища всередині API сервера, що кешує та відображає стан даних, збережених у etcd. Kubernetes запитує сповіщення про прогрес, щоб підтримувати консистентність кешу з шаром збереження даних (persistence layer) у etcd. Версії Kubernetes з v1.28 до v1.30 також підтримували цю функцію, але як Alpha, вона не рекомендувалася для використання в операційному середовищі і не була стандартно увімкненою до випуску v1.31.
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.

При використанні 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 починається з синтетичних подій "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-сервер може чекати невизначений час (до тайм-ауту запиту), поки версія ресурсу не стане доступною.

  1. Ідемпотентність означає, що ви можете повторно виконати операцію без змін у стані системи. https://uk.wikipedia.org/wiki/Ідемпотентність ↩︎

2.2 - Server-Side Apply

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable] (стандартно увімкнено: true)

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: v1
kind: ConfigMap
metadata:
  name: test-cm
  namespace: default
  labels:
    test-label: test
  managedFields:
  - manager: kubectl
    operation: Apply # зверніть увагу на великі літери: "Apply" (або "Update")
    apiVersion: v1
    time: "2010-10-10T0:00:00Z"
    fieldsType: FieldsV1
    fieldsV1:
      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 потрапить у неконсистентний стан (що не повинно відбуватися при нормальній роботі).

Формат managedFields описаний у довіднику API Kubernetes.

Конфлікти

Конфлікт — це спеціальна помилка статусу, яка виникає, коли операція 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.

Серіалізація є такою ж, як для обʼєктів Kubernetes, за винятком того, що клієнти не зобовʼязані надсилати повний обʼєкт.

Ось приклад тіла повідомлення Server-Side Apply (повністю специфікований намір):

{
  "apiVersion": "v1",
  "kind": "ConfigMap"
}

(це зробить оновлення без змін, за умови, що це було надіслано як тіло patch запиту до дійсного ресурсу v1/configmaps, з відповідним заголовком запиту Content-Type).

Операції з області управління полями

Операції API Kubernetes, де враховується управління полями, включають:

  1. Server-Side Apply (HTTP PATCH, з типом контенту application/apply-patch+yaml)
  2. Заміна наявного обʼєкта (update для Kubernetes; PUT на рівні HTTP)

Обидві операції оновлюють .metadata.managedFields, але поводяться трохи по-різному.

Якщо не вказано примусове перезаписування, операція apply, що зустрічає конфлікти на рівні полів, завжди зазнає невдачі; у противагу, якщо зміну здійснено за допомогою update, що впливає на кероване поле, конфлікт ніколи не призводить до невдачі операції.

Усі запити Server-Side Apply patch повинні ідентифікувати себе, надаючи параметр запиту fieldManager, тоді як цей параметр запиту є необовʼязковим для операцій update. Нарешті, при використанні операції Apply ви не можете визначати managedFields у тілі запиту, який ви надсилаєте.

Приклад обʼєкта з декількома менеджерами може виглядати так:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
  namespace: default
  labels:
    test-label: test
  managedFields:
  - manager: kubectl
    operation: Apply
    apiVersion: v1
    fields:
      f:metadata:
        f:labels:
          f:test-label: {}
  - manager: kube-controller-manager
    operation: Update
    apiVersion: v1
    time: '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Можливі значенняОпис
//+listTypex-kubernetes-list-typeatomic/set/mapЗастосовується до списків. set застосовується до списків, які включають лише скалярні елементи. Ці елементи повинні бути унікальними. map застосовується до списків вкладених типів. Значення ключів (див. listMapKey) повинні бути унікальними в списку. atomic може застосовуватися до будь-якого списку. Якщо налаштовано як atomic, весь список замінюється під час злиття. У будь-який момент часу список належить одному менеджеру. Якщо set або map, різні менеджери можуть окремо керувати елементами.
//+listMapKeyx-kubernetes-list-map-keysСписок імен полів, наприклад, ["port", "protocol"]Застосовується лише при +listType=map. Список імен полів, значення яких унікально ідентифікують елементи у списку. Хоча ключів може бути багато, listMapKey є одниною, тому що ключі потрібно вказувати індивідуально в типі Go. Поля ключів повинні бути скалярами.
//+mapTypex-kubernetes-map-typeatomic/granularЗастосовується до map. atomic означає, що map можна замінити повністю тільки одним менеджером. granular означає, що map підтримує окремих менеджерів, які оновлюють окремі поля.
//+structTypex-kubernetes-map-typeatomic/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.

Візьмемо, наприклад, власний ресурс користувача ресурс:

---
apiVersion: example.com/v1
kind: Foo
metadata:
  name: foo-sample
  managedFields:
  - manager: "manager-one"
    operation: Apply
    apiVersion: example.com/v1
    fields:
      f:spec:
        f:data: {}
spec:
  data:
    key1: val1
    key2: val2

До того, як spec.data зміниться з atomic на granular, manager-one володіє полем spec.data і всіма полями в ньому (key1 та key2). Коли CRD змінюється, щоб зробити spec.data granular, 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, встановленим на бажане значення:

application/ssa/nginx-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

І користувач створив Deployment, використовуючи Server-Side Apply, наступним чином:

kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment.yaml --server-side

Пізніше автоматичне масштабування увімкнено для Deployment; наприклад:

kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=1 --max=10

Тепер користувач хоче видалити 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/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3

Користувач застосовує цей маніфест, використовуючи приватне імʼя менеджера полів. У цьому прикладі користувач вибрав handover-to-hpa:

kubectl apply -f nginx-deployment-replicas-only.yaml \
  --server-side --field-manager=handover-to-hpa \
  --validate=false

Якщо застосування призводить до конфлікту з контролером HPA, тоді нічого не робіть. Конфлікт вказує на те, що контролер вже вимагає поле на цьому етапі.

На цьому етапі користувач може видалити поле replicas з маніфесту:

application/ssa/nginx-deployment-no-replicas.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

Зауважте, що кожного разу, коли контролер 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 без виникнення конфліктів.

Ця поведінка стосується server-side apply з менеджером полів kubectl. Як виняток, ви можете відмовитися від цієї поведінки, вказавши іншого, не стандартного менеджера полів, як показано в наступному прикладі. Стандартним менеджером полів для kubectl server-side apply є kubectl.

kubectl apply --server-side --field-manager=my-manager [--dry-run=server]

Повернення з 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.

kubectl apply --server-side --field-manager=my-manager [--dry-run=server]

Реалізація API

Дієслово 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 порожнім записом. Два приклади:

PATCH /api/v1/namespaces/default/configmaps/example-cm
Accept: application/json
Content-Type: application/merge-patch+json

{
  "metadata": {
    "managedFields": [
      {}
    ]
  }
}

PATCH /api/v1/namespaces/default/configmaps/example-cm
Accept: application/json
Content-Type: application/json-patch+json
If-Match: 1234567890123456789

[{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]

Це перепише managedFields списком, що містить один порожній запис, що в результаті повністю видалить managedFields з обʼєкта. Зверніть увагу, що встановлення managedFields як порожнього списку не скине це поле. Це зроблено спеціально, щоб managedFields ніколи не видалялися клієнтами, які не знають про це поле.

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

Що далі

Ви можете прочитати про managedFields у довіднику API Kubernetes для верхнього рівня поля metadata.

2.3 - Бібліотеки клієнтів

Ця сторінка містить огляд бібліотек клієнтів для використання Kubernetes API різними мовами програмування.

Для написання застосунків, що використовують Kubernetes REST API, вам не потрібно самостійно реалізовувати виклики API та типи запитів/відповідей. Ви можете використовувати бібліотеку клієнтів для мови програмування, яку ви використовуєте.

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

Офіційно підтримувані бібліотеки клієнтів Kubernetes

Наступні бібліотеки клієнтів офіційно підтримуються Kubernetes SIG API Machinery.

МоваБібліотека клієнтівПриклад програм
Cgithub.com/kubernetes-client/cпереглянути
dotnetgithub.com/kubernetes-client/csharpпереглянути
Gogithub.com/kubernetes/client-go/переглянути
Haskellgithub.com/kubernetes-client/haskellпереглянути
Javagithub.com/kubernetes-client/javaпереглянути
JavaScriptgithub.com/kubernetes-client/javascriptпереглянути
Perlgithub.com/kubernetes-client/perl/переглянути
Pythongithub.com/kubernetes-client/python/переглянути
Rubygithub.com/kubernetes-client/ruby/переглянути

Бібліотеки клієнтів, що підтримуються спільнотою

Наступні бібліотеки клієнтів Kubernetes надаються і підтримуються їх авторами, а не командою Kubernetes.

МоваБібліотека клієнтів
Clojuregithub.com/yanatan16/clj-kubernetes-api
DotNetgithub.com/tonnyeremin/kubernetes_gen
DotNet (RestSharp)github.com/masroorhasan/Kubernetes.DotNet
Elixirgithub.com/obmarg/kazan
Elixirgithub.com/coryodaniel/k8s
Java (OSGi)bitbucket.org/amdatulabs/amdatu-kubernetes
Java (Fabric8, OSGi)github.com/fabric8io/kubernetes-client
Javagithub.com/manusa/yakc
Lispgithub.com/brendandburns/cl-k8s
Lispgithub.com/xh4/cube
Node.js (TypeScript)github.com/Goyoo/node-k8s-client
Node.jsgithub.com/ajpauwels/easy-k8s
Node.jsgithub.com/godaddy/kubernetes-client
Node.jsgithub.com/tenxcloud/node-kubernetes-client
Perlmetacpan.org/pod/Net::Kubernetes
PHPgithub.com/allansun/kubernetes-php-client
PHPgithub.com/maclof/kubernetes-client
PHPgithub.com/travisghansen/kubernetes-client-php
PHPgithub.com/renoki-co/php-k8s
Pythongithub.com/fiaas/k8s
Pythongithub.com/gtsystem/lightkube
Pythongithub.com/kr8s-org/kr8s
Pythongithub.com/mnubo/kubernetes-py
Pythongithub.com/tomplus/kubernetes_asyncio
Pythongithub.com/Frankkkkk/pykorm
Rubygithub.com/abonas/kubeclient
Rubygithub.com/k8s-ruby/k8s-ruby
Rubygithub.com/kontena/k8s-client
Rustgithub.com/kube-rs/kube
Rustgithub.com/ynqa/kubernetes-rust
Scalagithub.com/hagay3/skuber
Scalagithub.com/hnaderi/scala-k8s
Scalagithub.com/joan38/kubernetes-client
Swiftgithub.com/swiftkube/client

2.4 - Загальна мова виразів у Kubernetes

Загальна мова виразів (Common Expression Language, CEL) використовується в API 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:

Приклади виразів CEL та їх призначення
ПравилоПризначення
self.minReplicas <= self.replicas && self.replicas <= self.maxReplicasПеревірити, що три поля, що визначають репліки, розташовані в правильному порядку
'Available' in self.stateCountsПеревірити, що в map існує запис з ключем 'Available'
(self.list1.size() == 0) != (self.list2.size() == 0)Перевірити, що один із двох списків не порожній, але не обидва одночасно
self.envars.filter(e, e.name = 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$'))Перевірити поле 'value' у запису listMap, де поле ключа 'name' дорівнює 'MY_ENV'
has(self.expired) && self.created + self.ttl < self.expiredПеревірити, що дата 'expired' є пізніше дати 'created' плюс тривалість 'ttl'
self.health.startsWith('ok')Перевірити, що строкове поле 'health' має префікс 'ok'
self.widgets.exists(w, w.key == 'x' && w.foo < 10)Перевірити, що властивість 'foo' елемента listMap з ключем 'x' менше 10
type(self) == string ? self == '99%' : self == 42Перевірити поле типу int-або-string для обох випадків: int та string
self.metadata.name == 'singleton'Перевірити, що імʼя обʼєкта відповідає конкретному значенню (робить його унікальним)
self.set1.all(e, !(e in self.set2))Перевірити, що два списки (listSets) не перетинаються
self.names.size() == self.details.size() && self.names.all(n, n in self.details)Перевірити, що map 'details' має ключі, які відповідають елементам у списку 'names'
self.details.all(key, key.matches('^[a-zA-Z]*$'))Перевірити ключі map 'details'
self.details.all(key, self.details[key].matches('^[a-zA-Z]*$'))Перевірити значення map 'details'

Опції CEL, особливості мови та бібліотеки

CEL налаштовується з наступними опціями, бібліотеками та особливостями мови, введеними у зазначених версіях Kubernetes:

Опція, бібліотека або особливість мови CELВключеноДоступність
Стандартні макросиhas, all, exists, exists_one, map, filterУсі версії Kubernetes
Стандартні функціїДивіться офіційний список стандартних визначеньУсі версії Kubernetes
Однорідні агрегаційні літералиУсі версії Kubernetes
Часовий пояс UTC за замовчуваннямУсі версії Kubernetes
Рання перевірка деклараційУсі версії Kubernetes
бібліотека розширених рядків, Версія 1charAt, indexOf, lastIndexOf, lowerAscii, upperAscii, replace, split, join, substring, trimУсі версії Kubernetes
Бібліотека списків KubernetesДивіться бібліотеку списків KubernetesУсі версії Kubernetes
Бібліотека регулярних виразів KubernetesДивіться бібліотеку регулярних виразів KubernetesУсі версії Kubernetes
Бібліотека URL KubernetesДивіться бібліотеку URL KubernetesУсі версії Kubernetes
Бібліотека авторизації KubernetesДивіться бібліотеку авторизації KubernetesУсі версії Kubernetes
Бібліотека кількостей KubernetesДивіться бібліотеку кількостей KubernetesВерсії Kubernetes 1.29+
Опційні типи CELДивіться опційні типи CELВерсії Kubernetes 1.29+
Порівняння чисел різних типів CELДивіться порівняння чисел різних типів CELВерсії Kubernetes 1.29+

Функції 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
lowPriorities.map(x, x.priority).max() < highPriorities.map(x, x.priority).min()Перевірити, що два набори пріоритетів не перекриваються
names.indexOf('should-be-first') == 1Вимагати, щоб перше імʼя у списку було певним значенням

Для отримання додаткової інформації дивіться бібліотеку списків Kubernetes godoc.

Бібліотека регулярних виразів Kubernetes

Крім функції matches, наданої стандартною бібліотекою CEL, бібліотека регулярних виразів надає функції find та findAll, що дозволяють виконувати ширший спектр операцій з регулярними виразами.

Приклади:

Приклади виразів CEL, що використовують функції бібліотеки регулярних виразів
Вираз CELПризначення
"abc 123".find('[0-9]+')Знайти перше число у рядку
"1, 2, 3, 4".findAll('[0-9]+').map(x, int(x)).sum() < 100Перевірити, що сума чисел у рядку менше 100

Для отримання додаткової інформації дивіться бібліотеку регулярних виразів Kubernetes godoc.

Бібліотека URL Kubernetes

Для спрощення та безпечної обробки 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()Повертає '/path%20with%20spaces/'

Для отримання додаткової інформації дивіться бібліотеку URL Kubernetes godoc.

Бібліотека авторизатора Kubernetes

Для виразів CEL в API, де доступна змінна типу Authorizer, авторизатор може використовуватися для виконання перевірок авторизації для принципала (автентифікованого користувача) запиту.

Перевірки ресурсів API виконуються наступним чином:

  1. Вкажіть групу та ресурс для перевірки: Authorizer.group(string).resource(string) ResourceCheck.

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

    • ResourceCheck.subresource(string) ResourceCheck
    • ResourceCheck.namespace(string) ResourceCheck
    • ResourceCheck.name(string) ResourceCheck

  3. Викличте ResourceCheck.check(verb string) Decision, щоб виконати перевірку авторизації.

  4. Викличте allowed() bool або reason() string, щоб переглянути результат перевірки авторизації.

Не-ресурсна авторизація виконується так:

  1. Вкажіть лише шлях: Authorizer.path(string) PathCheck.
  2. Викличте PathCheck.check(httpVerb string) Decision, щоб виконати перевірку авторизації.
  3. Викличте allowed() bool або reason() string, щоб переглянути результат перевірки авторизації.

Для виконання перевірки авторизації для службового облікового запису:

  • Authorizer.serviceAccount(namespace string, name string) Authorizer
Приклади виразів CEL, що використовують функції бібліотеки авторизатора
Вираз CELПризначення
authorizer.group('').resource('pods').namespace('default').check('create').allowed()Повертає true, якщо принципалу (користувачу або службовому обліковому запису) дозволено створювати Podʼи у просторі імен 'default'.
authorizer.path('/healthz').check('get').allowed()Перевіряє, чи авторизований принципал (користувач або службовий обліковий запис) виконує HTTP GET-запити до шляху API /healthz.
authorizer.serviceAccount('default', 'myserviceaccount').resource('deployments').check('delete').allowed()Перевіряє, чи службовий обліковий запис має дозвіл на видалення deployments.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

З увімкненою альфа-функцією AuthorizeWithSelectors, до перевірок авторизації можна додавати селектори полів і міток.

Приклади CEL виразів із використанням функцій авторизації для селекторів
CEL виразПризначення
authorizer.group('').resource('pods').fieldSelector('spec.nodeName=mynode').check('list').allowed()Повертає true, якщо користувач або службовий обліковий запис має дозвіл на отримання списку Podʼів із селектором полів spec.nodeName=mynode.
authorizer.group('').resource('pods').labelSelector('example.com/mylabel=myvalue').check('list').allowed()Повертає true, якщо користувач або службовий обліковий запис має дозвіл на отримання списку Podʼів із селектором міток example.com/mylabel=myvalue.

Для отримання додаткової інформації дивіться бібліотеку Kubernetes Authz та бібліотеку Kubernetes AuthzSelectors godoc.

Бібліотека кількості Kubernetes

У Kubernetes 1.28 додана підтримка обробки рядків кількості (наприклад, 1,5G, 512k, 20Mi).

  • isQuantity(string) перевіряє, чи є рядок дійсною кількістю відповідно до Кількості ресурсів Kubernetes.
  • 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()Перевірка, чи конвертація в ціле число викликає помилку.
quantity("50k").asInteger()Точна конвертація в ціле число.
quantity("9999999999999999999999999999999999999G").asApproximateFloat()Втратна конвертація в плаваючий рядок.
quantity("50k").add(quantity("20k"))Додати дві кількості.
quantity("50k").sub(20000)Відняти ціле число від кількості.
quantity("50k").add(20).sub(quantity("100k")).sub(-50000)Ланцюгове додавання та віднімання цілих чисел та кількостей.
quantity("200M").compareTo(quantity("0.2G"))Порівняти дві кількості.
quantity("150Mi").isGreaterThan(quantity("100Mi"))Перевірити, чи кількість більша за отримувача.
quantity("50M").isLessThan(quantity("100M"))Перевірити, чи кількість менша за отримувача.

Перевірка типів

CEL — це поступово типізована мова.

Деякі поля API Kubernetes містять повністю перевірені типи CEL-виразів. Наприклад, Правила валідації власних ресурсів повністю перевірені за типом.

Деякі поля API Kubernetes містять частково перевірені типи CEL-виразів. Частково перевірений вираз — це вираз, в якому деякі змінні статично типізовані, а інші — динамічно типізовані. Наприклад, в CEL-виразах ValidatingAdmissionPolicies, змінна request має тип, але змінна object динамічно типізована. У звʼязку з цим вираз, що містить request.namex, не пройде перевірку типів, оскільки поле namex не визначене. Однак object.namex пройде перевірку типів навіть тоді, коли поле namex не визначене для типів ресурсів, на які посилається object, оскільки object динамічно типізований.

Макрос has() в CEL можна використовувати у виразах CEL для перевірки доступності поля динамічно типізованої змінної перед спробою доступу до значення поля. Наприклад:

has(object.namex) ? object.namex == 'special' : request.name == 'special'

Інтеграція системи типів

Таблиця, що показує взаємозвʼязок між типами OpenAPIv3 та CEL
Тип OpenAPIv3Тип CEL
'object' з Propertiesobject / "тип повідомлення" (type(<object>) обчислюється як selfType<uniqueNumber>.path.to.object.from.self
'object' з AdditionalPropertiesmap
'object' з x-kubernetes-embedded-typeobject / "тип повідомлення", 'apiVersion', 'kind', 'metadata.name' і 'metadata.generateName' включені в схему
'object' з x-kubernetes-preserve-unknown-fieldsobject / "тип повідомлення", невідомі поля НЕ доступні у виразі CEL
x-kubernetes-int-or-stringобʼєднання int або string, self.intOrString < 100 || self.intOrString == '50%' обчислюється як true для 50 і "50%"
'array'list
'array' з x-kubernetes-list-type=maplist з базованими на map рівноправністю та унікальними ключами
'array' з x-kubernetes-list-type=setlist з базованими на set рівноправністю та унікальними елементами
'boolean'boolean
'number' (усі формати)double
'integer' (усі формати)int (64)
немає еквівалентаuint (64)
'null'null_type
'string'string
'string' з format=byte (base64 encoded)bytes
'string' з format=datetimestamp (google.protobuf.Timestamp)
'string' з format=datetimetimestamp (google.protobuf.Timestamp)
'string' з format=durationduration (google.protobuf.Duration)

Також дивіться: Типи CEL, Типи OpenAPI, Структурні схеми Kubernetes.

Порівняння рівності для масивів з 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
екрануюча послідовністьеквівалент імені властивості
__underscores____
__dot__.
__dash__-
__slash__/
__{keyword}__ЗАРЕЗЕРВОВАНЕ ключове слово CEL

Коли ви екрануєте будь-яке з ЗАРЕЗЕРВОВАНИХ ключових слів CEL, збіг повинен точно відповідати імені властивості та використовувати екранування з підкресленням (наприклад, int у слові sprint не буде екрановано, і це не буде необхідно).

Приклади екранування:

Приклади екранованих ідентифікаторів CEL
імʼя властивостіправило з екранованим імʼям властивості
namespaceself.__namespace__ > 0
x-propself.x__dash__prop > 0
redact__dself.redact__underscores__d > 0
stringself.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 основні треки, кожен з яких має різні політики застарівання:

ПрикладТрек
v1GA (загальнодоступна, стабільна)
v1beta1Beta (попередній випуск, перед GA)
v1alpha1Alpha (експериментальна)

Конкретний випуск Kubernetes може підтримувати будь-яку кількість груп API та будь-яку кількість версій кожного з них.

Наступні правила регулюють застарівання елементів API. Це включає:

  • Ресурси REST (також відомі як обʼєкти API)
  • Поля ресурсів REST
  • Анотації на ресурсах REST, включаючи "бета" анотації, але не включаючи "альфа" анотації
  • Перелічувані або постійні значення
  • Структури конфігурації компонентів

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

Правило №1: Елементи API можуть бути видалені лише шляхом інкрементування версії групи API.

Після того, як елемент 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 закінчиться.

Правило №4б: "Бажана" версія API та "версія зберігання" для даної групи можуть не просуватися до того, як буде зроблено випуск, що підтримує як нову версію, так і попередню версію.

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

Все це найкраще ілюструється прикладами. Уявіть собі випуск Kubernetes, версія X, який вводить нову групу API. Новий випуск Kubernetes виходить приблизно кожні 4 місяці (3 на рік). Наступна таблиця описує, які версії API підтримуються в ряді наступних випусків.

ВипускВерсії APIБажана/Версія зберіганняПримітки
Xv1alpha1v1alpha1
X+1v1alpha2v1alpha2
  • v1alpha1 видалено. Необхідні дії див. у примітках до випуску.
X+2v1beta1v1beta1
  • v1alpha2 видалено. Необхідні дії див. у примітках до випуску.
X+3v1beta2, v1beta1 (застаріла)v1beta1
  • v1beta1 застаріла. Необхідні дії див. у примітках до випуску.
X+4v1beta2, v1beta1 (застаріла)v1beta2
X+5v1, v1beta1 (застаріла), v1beta2 (застаріла)v1beta2
  • v1beta2 застаріла. Необхідні дії див. у примітках до випуску.
X+6v1, v1beta2 (застаріла)v1
  • v1beta1 видалено. Необхідні дії див. у примітках до випуску.
X+7v1, v1beta2 (застаріла)v1
X+8v2alpha1, v1v1
  • v1beta2 видалено. Необхідні дії див. у примітках до випуску.
X+9v2alpha2, v1v1
  • v2alpha1 видалено. Необхідні дії див. у примітках до випуску.
X+10v2beta1, v1v1
  • v2alpha2 видалено. Необхідні дії див. у примітках до випуску.
X+11v2beta2, v2beta1 (застаріла), v1v1
  • v2beta1 застаріла. Необхідні дії див. у примітках до випуску.
X+12v2, v2beta2 (застаріла), v2beta1 (застаріла), v1 (застаріла)v1
  • v2beta2 застаріла. Необхідні дії див. у примітках до випуску.
  • v1 застаріла на користь v2, але не буде видалена
X+13v2, v2beta1 (застаріла), v2beta2 (застаріла), v1 (застаріла)v2
X+14v2, v2beta2 (застаріла), v1 (застаріла)v2
  • v2beta1 видалено. Необхідні дії див. у примітках до випуску.
X+15v2, 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:

  1. Повертає заголовок Warning (як визначено у RFC7234, Розділ 5.5) у відповіді API.

  2. Додає "k8s.io/deprecated":"true" анотацію до події аудиту, зареєстрованої для запиту.

  3. Встановлює метрику apiserver_requested_deprecated_apis gauge у значення 1 у процесі kube-apiserver. Метрика має мітки group, version, resource, subresource, які можна поєднати з метрикою apiserver_request_total, і мітку removed_release, яка вказує випуск Kubernetes, в якому API більше не буде обслуговуватися. Наступний запит Prometheus повертає інформацію про запити, зроблені до застарілих API, які будуть видалені у версії v1.22:

    apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total

Поля REST ресурсів

Як і 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.

v1.25

Випуск 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.

PodDisruptionBudget

Версія 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 буде видалено.

Перейдіть до Pod Security Admission або виклику стороннього вебхуку допуску. Для настанов з міграції, див. Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity Admission Controller. Для отримання додаткової інформації про застарілість, див. ВPodSecurityPolicy Deprecation: Past, Present, and Future.

RuntimeClass

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 сервера:

--runtime-config=<group>/<version>=false

Наприклад:

--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1,...

Пошук використання застарілих API

Використовуйте попередження клієнтів, метрики та інформацію аудиту, доступні в версії 1.19+ для визначення використання застарілих API.

Перехід на незастарілі API

  • Оновіть власні інтеграції та контролери, щоб викликати незастарілі API.

  • Змініть YAML файли, щоб вони посилалися на незастарілі API.

    Ви можете використовувати команду kubectl convert для автоматичного перетворення наявного обʼєкта:

    kubectl convert -f <file> --output-version <group>/<version>.

    Наприклад, щоб перетворити старий Deployment на apps/v1, ви можете виконати:

    kubectl convert -f ./my-deployment.yaml --output-version apps/v1

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

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 також підтримує виключення конкретних перевірок. Параметри запиту також можна комбінувати, як у цьому прикладі:

curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'

Вивід показує, що перевірка etcd виключено:

[+]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.31 [alpha]

Кожна індивідуальна перевірка стану надає HTTP точку доступу і може бути перевірена індивідуально. Схема для індивідуальних перевірок стану — /livez/<healthcheck-name> або /readyz/<healthcheck-name>, де livez і readyz можуть бути використані для індикації, чи ви хочете перевірити liveness або readiness API сервера відповідно. Шлях <healthcheck-name> можна знайти, використовуючи прапорець verbose вище та шлях між [+] та ok. Ці індивідуальні перевірки стану не повинні використовуватися машинами, але можуть бути корисні для оператора-людини для налагодження системи:

curl -k https://localhost:6443/livez/etcd

3 - Управління доступом до API Kubernetes

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

Довідники:

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

Ця сторінка надає огляд автентифікації.

Користувачі в Kubernetes

У всіх кластерах 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 для генерації запиту на підпис сертифіката:

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

Це створить CSR для імені користувача "jbeda", який належить до двох груп, "app1" і "app2".

Дивіться Керування сертифікатами для отримання інформації про те, як створити клієнтський сертифікат.

Статичний файл токенів

API сервер читає токени на предʼявника (bearer tokens) з файлу при використанні опції --token-auth-file=SOMEFILE у командному рядку. Наразі токени діють безстроково, і список токенів не можна змінити без перезавантаження API сервера.

Файл токенів є csv-файлом з мінімум 3 стовпцями: токен, імʼя користувача, uid користувача, а також необовʼязкові імена груп.

Використання токена на предʼявника у запиті

При використанні автентифікації за допомогою токенів з HTTP клієнта, API сервер очікує заголовок Authorization зі значенням Bearer <token>. Маркер має бути послідовністю символів, яку можна помістити в значення HTTP заголовка, використовуючи лише можливості кодування та цитування HTTP. Наприклад, якщо токен — 31ada4fd-adec-460c-809a-9e56ceb75269, тоді він буде виглядати у заголовку HTTP, як показано нижче.

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

Bootstrap токени

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Для спрощення початкового налаштування нових кластерів, 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.

apiVersion: apps/v1 # ця apiVersion актуальна станом з Kubernetes 1.9
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 3
  template:
    metadata:
    # ...
    spec:
      serviceAccountName: bob-the-bot
      containers:
      - name: nginx
        image: 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).

Токени 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

  1. Увійдіть до свого провайдера ідентичності.

  2. Ваш провайдер ідентичності надасть вам access_token, id_token та refresh_token.

  3. Використовуючи kubectl, використовуйте свій id_token із прапорцем --token або додайте його безпосередньо до вашого kubeconfig.

  4. kubectl надсилає ваш id_token у заголовку Authorization до сервера API.

  5. Сервер API перевіряє, чи є підпис JWT дійсним.

  6. Перевіряє, чи не минув термін дії id_token.

    Виконує перевірку вимог та/або користувача, якщо з AuthenticationConfiguration налаштовані вирази CEL.

  7. Переконується, що користувач авторизований.

  8. Після авторизації сервер API повертає відповідь kubectl.

  9. kubectl надає зворотній звʼязок користувачу.

Оскільки всі дані, необхідні для верифікації вашої особи, містяться в id_token, Kubernetes не потрібно "дзвонити додому" до провайдера ідентичності. У моделі, де кожен запит є stateless, це забезпечує дуже масштабоване рішення для автентифікації. Це має кілька викликів:

  1. Kubernetes не має "вебінтерфейсу" для ініціювання процесу автентифікації. Немає оглядача або інтерфейсу для збору облікових даних, тому вам потрібно спочатку автентифікуватися у свого провайдера ідентичності.
  2. id_token не можна відкликати, він схожий на сертифікат, тому він повинен бути короткостроковим (лише кілька хвилин), що може бути дуже незручним, оскільки потрібно отримувати новий токен кожні кілька хвилин.
  3. Для автентифікації в панелі управління Kubernetes, ви повинні використовувати команду kubectl proxy або зворотний проксі, який вставляє id_token.

Налаштування сервера API

Використання прапорців

Щоб увімкнути втулок, налаштуйте наступні прапорці на сервері API:

ПараметрОписПрикладОбовʼязковий
--oidc-issuer-urlURL провайдера, який дозволяє серверу API знаходити публічні ключі підпису. Приймаються лише URL-адреси, що використовують схему https://. Це зазвичай URL виявлення провайдера, змінений на порожній шляхЯкщо URL виявлення OIDC провайдера https://accounts.provider.example/.well-known/openid-configuration, значення повинно бути https://accounts.provider.exampleТак
--oidc-client-idІдентифікатор клієнта, для якого мають бути видані всі токени.kubernetesТак
--oidc-username-claimJWT вимога для використання як імені користувача. Стандартно 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-claimJWT вимога для використання як групи користувача. Якщо вимога присутня, вона повинна бути масивом рядків.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] (стандартно увімкнено: true)

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.31, формат файлу структурованої конфігурації автентифікації є на рівні бета-версії, і механізм використання цієї конфігурації також є на рівні бета-версії. За умови, що ви не вимкнули спеціально функційну можливість StructuredAuthenticationConfiguration для вашого кластера, ви можете увімкнути структуровану автентифікацію, вказавши аргумент командного рядка --authentication-config для kube-apiserver. Приклад файлу конфігурації структурованої автентифікації наведено нижче.

---
#
# УВАГА: це приклад конфігурації.
#        Не використовуйте це для вашого кластера!
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: 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: hd
    requiredValue: 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.expression jwt.claimMappings.extra[i].valueExpression представляє вираз, який буде оцінений CEL. Вирази CEL мають доступ до вмісту корисного навантаження токена, організованого у змінну CEL claims. claims — зіствлення імен тверджень (як рядків) до значень тверджень (будь-якого типу).

    Щоб дізнатися більше, дивіться Документацію по CEL.

    Ось приклади AuthenticationConfiguration з різними корисними навантаженнями токена.

    apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://example.com
    audiences:
    - my-app
  claimMappings:
    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:')" # вибарз буде оцінений як true, тоож валідація пройде успішно.
    message: 'username cannot used reserved system: prefix'

    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJpYXQiOjE3MDExMDcyMzMsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5jb20iLCJqdGkiOiI3YzMzNzk0MjgwN2U3M2NhYTJjMzBjODY4YWMwY2U5MTBiY2UwMmRkY2JmZWJlOGMyM2I4YjVmMjdhZDYyODczIiwibmJmIjoxNzAxMTA3MjMzLCJyb2xlcyI6InVzZXIsYWRtaW4iLCJzdWIiOiJhdXRoIiwidGVuYW50IjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjRhIiwidXNlcm5hbWUiOiJmb28ifQ.TBWF2RkQHm4QQz85AYPcwLxSk-VLvQW-mNDHx7SEOSv9LVwcPYPuPajJpuQn9C_gKq1R94QKSQ5F6UgHMILz8OfmPKmX_00wpwwNVGeevJ79ieX2V-__W56iNR5gJ-i9nn6FYk5pwfVREB0l4HSlpTOmu80gbPWAXY5hLW0ZtcE1JTEEmefORHV2ge8e3jp1xGafNy6LdJWabYuKiw8d7Qga__HxtKB-t0kRMNzLRS7rka_SfQg0dSYektuxhLbiDkqhmRffGlQKXGVzUsuvFw7IGM5ZWnZgEMDzCI357obHeM3tRqpn5WRjtB8oM7JgnCymaJi-P3iCd88iu1xnzA

    де корисне навантаження токена:

      {
    "aud": "kubernetes",
    "exp": 1703232949,
    "iat": 1701107233,
    "iss": "https://example.com",
    "jti": "7c337942807e73caa2c30c868ac0ce910bce02ddcbfebe8c23b8b5f27ad62873",
    "nbf": 1701107233,
    "roles": "user,admin",
    "sub": "auth",
    "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
    "username": "foo"
  }

    Токен із зазначеною вище AuthenticationConfiguration створить наступний об’єкт UserInfo і успішно автентифікує користувача.

    {
    "username": "foo:external-user",
    "uid": "auth",
    "groups": [
        "user",
        "admin"
    ],
    "extra": {
        "example.com/tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a"
    }
}


    apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://example.com
    audiences:
    - my-app
  claimValidationRules:
  - expression: 'claims.hd == "example.com"' # маркер нижче не має цього твердження, тому перевірка не вдасться.
    message: the hd claim must be set to example.com
  claimMappings:
    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'

    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJpYXQiOjE3MDExMDcyMzMsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5jb20iLCJqdGkiOiI3YzMzNzk0MjgwN2U3M2NhYTJjMzBjODY4YWMwY2U5MTBiY2UwMmRkY2JmZWJlOGMyM2I4YjVmMjdhZDYyODczIiwibmJmIjoxNzAxMTA3MjMzLCJyb2xlcyI6InVzZXIsYWRtaW4iLCJzdWIiOiJhdXRoIiwidGVuYW50IjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjRhIiwidXNlcm5hbWUiOiJmb28ifQ.TBWF2RkQHm4QQz85AYPcwLxSk-VLvQW-mNDHx7SEOSv9LVwcPYPuPajJpuQn9C_gKq1R94QKSQ5F6UgHMILz8OfmPKmX_00wpwwNVGeevJ79ieX2V-__W56iNR5gJ-i9nn6FYk5pwfVREB0l4HSlpTOmu80gbPWAXY5hLW0ZtcE1JTEEmefORHV2ge8e3jp1xGafNy6LdJWabYuKiw8d7Qga__HxtKB-t0kRMNzLRS7rka_SfQg0dSYektuxhLbiDkqhmRffGlQKXGVzUsuvFw7IGM5ZWnZgEMDzCI357obHeM3tRqpn5WRjtB8oM7JgnCymaJi-P3iCd88iu1xnzA

    де корисне навантаження токена:

      {
    "aud": "kubernetes",
    "exp": 1703232949,
    "iat": 1701107233,
    "iss": "https://example.com",
    "jti": "7c337942807e73caa2c30c868ac0ce910bce02ddcbfebe8c23b8b5f27ad62873",
    "nbf": 1701107233,
    "roles": "user,admin",
    "sub": "auth",
    "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
    "username": "foo"
  }

    Токен із зазначеною вище AuthenticationConfiguration не зможе автентифікуватись, оскільки твердження hd не має значення example.com. Сервер API поверне помилку 401 Unauthorized.

    apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://example.com
    audiences:
    - my-app
  claimValidationRules:
  - expression: 'claims.hd == "example.com"'
    message: the hd claim must be set to example.com
  claimMappings:
    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'

    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJoZCI6ImV4YW1wbGUuY29tIiwiaWF0IjoxNzAxMTEzMTAxLCJpc3MiOiJodHRwczovL2V4YW1wbGUuY29tIiwianRpIjoiYjViMDY1MjM3MmNkMjBlMzQ1YjZmZGZmY2RjMjE4MWY0YWZkNmYyNTlhYWI0YjdlMzU4ODEyMzdkMjkyMjBiYyIsIm5iZiI6MTcwMTExMzEwMSwicm9sZXMiOiJ1c2VyLGFkbWluIiwic3ViIjoiYXV0aCIsInRlbmFudCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0YSIsInVzZXJuYW1lIjoiZm9vIn0.FgPJBYLobo9jnbHreooBlvpgEcSPWnKfX6dc0IvdlRB-F0dCcgy91oCJeK_aBk-8zH5AKUXoFTlInfLCkPivMOJqMECA1YTrMUwt_IVqwb116AqihfByUYIIqzMjvUbthtbpIeHQm2fF0HbrUqa_Q0uaYwgy8mD807h7sBcUMjNd215ff_nFIHss-9zegH8GI1d9fiBf-g6zjkR1j987EP748khpQh9IxPjMJbSgG_uH5x80YFuqgEWwq-aYJPQxXX6FatP96a2EAn7wfPpGlPRt0HcBOvq5pCnudgCgfVgiOJiLr_7robQu4T1bis0W75VPEvwWtgFcLnvcQx0JWg

    де корисне навантаження токена:

      {
    "aud": "kubernetes",
    "exp": 1703232949,
    "hd": "example.com",
    "iat": 1701113101,
    "iss": "https://example.com",
    "jti": "b5b0652372cd20e345b6fdffcdc2181f4afd6f259aab4b7e35881237d29220bc",
    "nbf": 1701113101,
    "roles": "user,admin",
    "sub": "auth",
    "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
    "username": "foo"
  }

    Токен із наведеною вище AuthenticationConfiguration створить такий обʼєкт UserInfo:

    {
    "username": "system:foo",
    "uid": "auth",
    "groups": [
        "user",
        "admin"
    ],
    "extra": {
        "example.com/tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a"
    }
}

    який не пройде перевірку користувача, оскільки ім’я користувача починається з system:. Сервер API поверне помилку 401 Unauthorized.

Обмеження
  1. Розподілені твердження не працюють через вирази CEL.
  2. Конфігурація селектора вихідного трафіку не підтримується для викликів до issuer.url та issuer.discoveryURL.

Kubernetes не надає провайдера ідентифікації OpenID Connect. Ви можете використовувати наявного публічного провайдера ідентифікації OpenID Connect (наприклад, Google або інші). Або ж ви можете запустити власного провайдера ідентифікації, такого як dex, Keycloak, CloudFoundry UAA, або Tremolo Security's OpenUnison.

Для того, щоб провайдер ідентифікації працював з Kubernetes, він повинен:

  1. Підтримувати OpenID Connect discovery

    Публічний ключ для перевірки підпису отримується з публічної точки доступу видавця за допомогою OIDC discovery. Якщо ви використовуєте файл конфігурації автентифікації, провайдер ідентифікації не обовʼязково має публічно відкривати точку доступу discovery. Ви можете розмістити точку доступу discovery в іншому місці, ніж видавець (наприклад, локально в кластері) і вказати issuer.discoveryURL у файлі конфігурації.

  2. Працювати через TLS з не застарілими шифрами

  3. Мати сертифікат, підписаний ЦС (навіть якщо ЦС не комерційний або самопідписаний)

Примітка щодо вимоги №3 вище, що потреби в сертифікаті, підписаного ЦС. Якщо ви розгортаєте власного провайдера ідентифікації (на відміну від одного з хмарних провайдерів, таких як Google або Microsoft), ви ПОВИІННІ мати сертифікат вебсервера провайдера ідентифікації, підписаний сертифікатом з прапорцем CA, встановленим на TRUE, навіть якщо він самопідписаний. Це повʼязано з тим, що реалізація клієнта TLS в GoLang дуже сувора до стандартів перевірки сертифікатів. Якщо у вас немає під рукою ЦС, ви можете використовувати скрипт gencert від команди Dex для створення простого ЦС і пари підписаного сертифіката та ключа. Або ви можете використовувати цей подібний скрипт, який генерує сертифікати SHA256 з довшим терміном дії та більшим розміром ключа.

Інструкції з налаштування для конкретних систем:

Використання kubectl

Варіант 1 — Автентифікатор OIDC

Перший варіант — використання автентифікатора 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 )

Як приклад, запустіть наведену нижче команду після автентифікації у постачальника ідентифікаційної інформації:

kubectl config set-credentials mmosley  \
        --auth-provider=oidc  \
        --auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP  \
        --auth-provider-arg=client-id=kubernetes  \
        --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5  \
        --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
        --auth-provider-arg=idp-certificate-authority=/root/ca.pem \
        --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw

Що створить наведену нижче конфігурацію:

users:
- name: mmosley
  user:
    auth-provider:
      config:
        client-id: kubernetes
        client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
        id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
        idp-certificate-authority: /root/ca.pem
        idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
        refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
      name: oidc

Після закінчення терміну дії вашого id_token kubectl спробує оновити ваш 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 Kubernetes
apiVersion: v1
# Тип обʼєкта API
kind: Config
# clusters посилається на віддалений сервіс.
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # ЦС для перевірки віддаленого сервісу.
      server: https://authn.example.com/authenticate # URL віддаленого сервісу для запиту. 'https' рекомендовано для промислового застосування.

# users посилається на конфігурацію вебхука API-сервера.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # сертифікат для використання втулком вебхука
      client-key: /path/to/key.pem          # ключ, що відповідає сертифікату

# файли kubeconfig потребують контексту. Надати один для API-сервера.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authn-service
    user: name-of-api-server
  name: webhook

Коли клієнт намагається автентифікуватись на API-сервері за допомогою токена на предʼявника, як розглядалось вище, вебхук автентифікації надсилає POST-запит з JSON-серіалізованим обʼєктом TokenReview, що містить токен для віддаленого сервісу.

Зверніть увагу, що обʼєкти API вебхука підпадають під ті ж правила сумісності версій, що й інші обʼєкти API Kubernetes. Виконавці повинні перевірити поле apiVersion запиту, щоб забезпечити правильну десеріалізацію, і повинні відповідати обʼєктом TokenReview тієї ж версії, що й запит.

{
  "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, і стає додатковим ключем, а значення заголовка — додатковим значенням.

Наприклад, з цією конфігурацією:

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-

цей запит:

GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile

призведе до такої інформації про користувача:

name: fido
groups:
- dogs
- dachshunds
extra:
  acme.com/project:
  - some-project
  scopes:
  - openid
  - profile

Для запобігання підробці заголовків, проксі-сервер автентифікації повинен представити дійсний клієнтський сертифікат на 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, тому застарілі правила політики, які надають доступ користувачеві * або групі *, не включають анонімних користувачів.

Налаштування анонімної автентифікації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha] (стандартно увімкнено: false)

AuthenticationConfiguration можна використовувати для налаштування анонімного автентифікатора. Щоб увімкнути налаштування анонімної автентифікації через конфігураційний файл, потрібно увімкнути функціональну можливість AnonymousAuthConfigurableEndpoints. Коли ця функціональна можливість увімкнена, ви не можете встановити прапорець --anonymous-auth.

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

Ось приклад конфігураційного файлу автентифікації:

---
#
# УВАГА: це приклад конфігурації.
#        Не використовуйте його для вашого власного кластера!
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

У наведеній конфігурації лише точки доступу /livez, /readyz і /healthz доступні для анонімних запитів. Будь-які інші точки доступу будуть недоступні, навіть якщо це дозволено конфігурацією RBAC.

Імперсонізація користувачів

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

Запити з імперсонізацією спочатку автентифікуються як запити від імені запитувача, потім переключаються на імперсоновану інформацію про користувача.

  • Користувач робить 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 не накладає жодних вимог щодо формату цього рядка.

Приклад заголовків імперсонізації при імперсонуванні користувача з групами:

Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins

Приклад заголовків імперсонізації при імперсонуванні користувача з UID та додатковими полями:

Impersonate-User: jane.doe@example.com
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-acme.com%2Fproject: some-project
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development
Impersonate-Uid: 06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b

Для використання 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)

Встановіть прапорці --as і --as-group:

kubectl drain mynode --as=superman --as-group=system:masters

node/mynode cordoned
node/mynode drained

Для імперсонізації користувача, групи, ідентифікатора користувача (UID) або додаткових полів, користувач, який виконує імперсонізацію, повинен мати можливість виконувати дію "impersonate" з типом атрибута, який імперсонується ("user", "group", "uid" і т.д.). Для кластерів, що використовують втулок авторизації RBAC, наступна роль ClusterRole охоплює правила, необхідні для налаштування заголовків імперсонізації користувачів і груп:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: impersonator
rules:
- apiGroups: [""]
  resources: ["users", "groups", "serviceaccounts"]
  verbs: ["impersonate"]

Для імперсонізації, додаткові поля та імперсоновані UID належать до групи apiGroup "authentication.k8s.io". Додаткові поля оцінюються як субресурси ресурсу "userextras". Щоб дозволити користувачеві використовувати заголовки імперсонізації для додаткового поля "scopes" та для UID, користувачеві слід надати таку роль:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scopes-and-uid-impersonator
rules:
# Може встановлювати заголовок "Impersonate-Extra-scopes" та заголовок "Impersonate-Uid".
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes", "uids"]
  verbs: ["impersonate"]

Значення заголовків імперсонізації також можна обмежити, обмеживши набір resourceNames, які ресурс може приймати.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-impersonator
rules:
# Може імперсонувати користувача "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"]

Втулки облікових даних client-go

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable]

k8s.io/client-go та інструменти, які використовують його, такі як kubectl та kubelet, можуть виконувати зовнішню команду для отримання облікових даних користувача.

Ця функція призначена для клієнтських інтеграцій з протоколами автентифікації, які не підтримуються на рівні k8s.io/client-go (LDAP, Kerberos, OAuth2, SAML та ін.). Вутулок реалізує логіку, специфічну для протоколу, а потім повертає непрозорі облікові дані для використання. Майже всі випадки використання втулків автентифікації потребують наявності компоненту на стороні сервера з підтримкою автентифікації токенів webhook, щоб інтерпретувати формат облікових даних, який генерується клієнтським втулком.

Приклад використання

У гіпотетичному сценарії використання організація запускає зовнішню службу, яка обмінює облікові дані LDAP на підписані токени, специфічні для користувача. Служба також може відповідати на запити автентифікатора токенів webhook, щоб перевірити токени. Користувачам буде потрібно встановити втулок автентифікації на своїй робочій станції.

Для автентифікації в API:

  • Користувач видає команду kubectl.
  • Вутулок облікових даних запитує користувача облікові дані LDAP, обмінює облікові дані зовнішньою службою на токен.
  • Вутулок облікових даних повертає токен client-go, який використовує його як токен власника на сервері API.
  • Сервер API використовує автентифікатор токенів webhook, щоб надіслати TokenReview зовнішній службі.
  • Зовнішня служба перевіряє підпис на токені та повертає імʼя користувача та групи.

Налаштування

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

apiVersion: v1
kind: Config
users:
- name: my-user
  user:
    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: Never
clusters:
- name: my-cluster
  cluster:
    server: "https://172.17.4.100:6443"
    certificate-authority: "/etc/kubernetes/ca.pem"
    extensions:
    - name: client.authentication.k8s.io/exec # зарезервоване імʼя розширення для кожної конфігурації виконання кластера
      extension:
        arbitrary: config
        this: може бути надано через змінну середовища KUBERNETES_EXEC_INFO при встановленні provideClusterInfo
        you: ["можете", "покласти", "будь-що", "тут"]
contexts:
- name: my-cluster
  context:
    cluster: my-cluster
    user: my-user
current-context: my-cluster


apiVersion: v1
kind: Config
users:
- name: my-user
  user:
    exec:
      # Команда для виконання. Обовʼязково.
      command: "example-client-go-exec-plugin"

      # Версія API, яку слід використовувати при декодуванні ресурсу ExecCredentials. Обовʼязково.
      #
      # Версія API, повернута втулком, ПОВИННА відповідати версії, вказаній тут.
      #
      # Щоб інтегруватися з інструментами, які підтримують кілька версій (наприклад, client.authentication.k8s.io/v1),
      # встановіть змінну середовища, перед ```yaml
      apiVersion: "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: Never
clusters:
- name: my-cluster
  cluster:
    server: "https://172.17.4.100:6443"
    certificate-authority: "/etc/kubernetes/ca.pem"
    extensions:
    - name: client.authentication.k8s.io/exec # зарезервоване імʼя розширення для кожної конфігурації виконання кластера
      extension:
        arbitrary: config
        this: може бути надано через змінну середовища KUBERNETES_EXEC_INFO при встановленні provideClusterInfo
        you: ["можете", "покласти", "будь-що", "тут"]
contexts:
- name: my-cluster
  context:
    cluster: my-cluster
    user: my-user
current-context: my-cluster

Відносні шляхи до команд інтерпретуються відносно теки файлу конфігурації. Якщо KUBECONFIG встановлено на /home/jane/kubeconfig, а команда виконання — ./bin/example-client-go-exec-plugin, то виконується бінарний файл /home/jane/bin/example-client-go-exec-plugin.

- name: my-user
  user:
    exec:
      # Шлях відносно теки kubeconfig
      command: "./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

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token"
  }
}


{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token"
  }
}

Альтративно, можна повернути PEM-кодований сертифікат клієнта та ключ для використання TLS-автентифікації клієнта. Якщо втулок повертає різний сертифікат та ключ при наступному виклику, k8s.io/client-go закриє існуючі зʼєднання з сервером, щоб змусити новий TLS-обмін.

Якщо вказано, що clientKeyData та clientCertificateData повинні бути присутніми.

clientCertificateData може містити додаткові проміжні сертифікати для відправки на сервер.

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
  }
}


{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
  }
}

Додатково відповідь може включати термін дії облікового запису, форматований як RFC 3339 мітка часу.

Наявність або відсутність терміну дії має такий вплив:

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

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token",
    "expirationTimestamp": "2018-03-05T17:30:20-08:00"
  }
}


{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token",
    "expirationTimestamp": "2018-03-05T17:30:20-08:00"
  }
}

Щоб дозволити втулку виконання отримувати інформацію, що специфічна для кластера, встановіть 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

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview"
}

Приклад відповіді:

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview",
  "status": {
    "userInfo": {
      "name": "jane.doe",
      "uid": "b6c7cfd4-f166-11ec-8ea0-0242ac120002",
      "groups": [
        "viewers",
        "editors",
        "system:authenticated"
      ],
      "extra": {
        "provider_id": ["token.company.example"]
      }
    }
  }
}

Для зручності доступний також запит 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-представлення результату:

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview",
  "status": {
    "userInfo": {
      "username": "jane.doe",
      "uid": "b79dbf30-0c6a-11ed-861d-0242ac120002",
      "groups": [
        "students",
        "teachers",
        "system:authenticated"
      ],
      "extra": {
        "skills": [
          "reading",
          "learning"
        ],
        "subjects": [
          "math",
          "sports"
        ]
      }
    }
  }
}


apiVersion: authentication.k8s.io/v1
kind: SelfSubjectReview
status:
  userInfo:
    username: jane.doe
    uid: b79dbf30-0c6a-11ed-861d-0242ac120002
    groups:
    - students
    - teachers
    - system:authenticated
    extra:
      skills:
      - reading
      - learning
      subjects:
      - math
      - sports

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

Стандартно всі автентифіковані користувачі можуть створювати обʼєкти SelfSubjectReview, коли функція APISelfSubjectReview включена. Це дозволено за допомогою кластерної ролі system:basic-user.

Що далі

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: v1
kind: Secret
metadata:
  # Назва МАЄ бути у формі "bootstrap-token-<token id>"
  name: bootstrap-token-07401b
  namespace: kube-system

# Тип МАЄ бути 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
  # Опис, зрозумілий людині. Необовʼязково.
  description: "Стандартний bootstrap-токен, згенерований 'kubeadm init'."

  # ID та секрет токена. Обовʼязково.
  token-id: 07401b
  token-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.

ConfigMap може виглядати так:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-info
  namespace: kube-public
data:
  jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: <дуже довгі дані сертифіката>
        server: https://10.138.0.2:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []

Елемент kubeconfig у ConfigMap є конфігураційним файлом, який містить лише інформацію про кластер. Ключовим моментом, що передається, є certificate-authority-data. Це може бути розширено в майбутньому.

Підпис є підписом JWS, що використовує "відокремлений" режим. Щоб перевірити підпис, користувач має закодувати вміст kubeconfig відповідно до правил JWS (закодовано base64, відкидаючи будь-які кінцеві =). Цей закодований вміст потім використовується для формування повного JWS шляхом вставки його між 2 крапками. Ви можете перевірити JWS, використовуючи схему HS256 (HMAC-SHA256) з повним токеном (наприклад, 07401b.f395accd246ae52d) як спільний секрет. Користувачі повинні перевірити, що використовується HS256.

Додаткову інформацію можна знайти в розділі докладні відомості про реалізацію kubeadm.

3.3 - Авторизація

Деталі механізмів авторизації Kubernetes і підтримувані режими авторизації.

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

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

Вердикти авторизації

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

Усі частини запиту до API повинні бути дозволені деяким механізмом авторизації, щоб він міг продовжити виконання. Іншими словами: стандартно доступ заборонений.

Коли налаштовано кілька модулів авторизації, кожен перевіряється по черзі. Якщо будь-який авторизатор схвалює або відхиляє запит, це рішення негайно повертається і жоден інший авторизатор не перевіряється. Якщо всі модулі не мають думки щодо запиту, то запит відхиляється. Загальний вердикт "відхилено" означає, що 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 методдієслово запиту
POSTcreate
GET, HEADget (для індивідуальних ресурсів), list (для колекцій, включаючи повний вміст обʼєктів), watch (для спостереження за індивідуальним ресурсом або колекцією ресурсів)
PUTupdate
PATCHpatch
DELETEdelete (для індивідуальних ресурсів), deletecollection (для колекцій)

Іноді Kubernetes перевіряє авторизацію для додаткових дозволів, використовуючи спеціалізовані дієслова. Наприклад:

  • Особливі випадки автентифікації
    • Дієслово impersonate для users, groups, і serviceaccounts в основній групі API, та userextras у групі API authentication.k8s.io.
  • Авторизація CertificateSigningRequests
    • Дієслово approve для CertificateSigningRequests, та update для переглядів наявних схвалень
  • RBAC
    • Дієслова bind та escalate для ресурсів roles та clusterroles у групі API rbac.authorization.k8s.io.

Контекст авторизації

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

Режими авторизації

API-сервер Kubernetes може авторизувати запит, використовуючи один з декількох режимів авторизації:

AlwaysAllow
Цей режим дозволяє всі запити, що несе ризики для безпеки. Використовуйте цей режим авторизації тільки якщо вам не потрібна авторизація для ваших запитів до API (наприклад, для тестування).
AlwaysDeny
Цей режим блокує всі запити. Використовуйте цей режим авторизації тільки для тестування.
ABAC (контроль доступу на основі атрибутів)
Режим ABAC в Kubernetes визначає парадигму управління доступом, згідно з якою права доступу надаються користувачам за допомогою політик, які обʼєднують атрибути разом. Політики можуть використовувати будь-який тип атрибутів (атрибути користувача, атрибути ресурсу, обʼєкта, середовища тощо).
RBAC (контроль доступу на основі ролей)
Kubernetes RBAC — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів в організації. У цьому контексті доступ — це можливість окремого користувача виконувати певне завдання, наприклад, переглядати, створювати або змінювати файл. В цьому режимі Kubernetes використовує групу API rbac.authorization.k8s.io для прийняття рішень щодо авторизації, що дозволяє вам динамічно налаштовувати політики дозволів через API Kubernetes.
Node
Спеціальний режим авторизації, який надає дозволи для kubeletʼів на основі запланованих до запуску Podʼів. Щоб дізнатися більше про режим авторизації вузла, див. Авторизація вузла.
Webhook
Kubernetes режим webhook для авторизації робить синхронний HTTP-виклик, блокуючи запит до тих пір, поки віддалений HTTP-сервіс не відповість на нього. Ви можете написати власне програмне забезпечення для обробки виклику або використовувати рішення з екосистеми.

Конфігурація режиму авторизації

Ви можете налаштувати ланцюжок авторизації API сервера Kubernetes, використовуючи або параметри командного рядка, або, як бета-функцію, використовуючи конфігураційний файл.

Ви повинні вибрати один з двох підходів до конфігурації: задати обидва шляхи --authorization-config і налаштувати вебхук авторизації за допомогою аргументів командного рядка --authorization-mode та --authorization-webhook-* не допускається. Якщо ви спробуєте це зробити, API сервер повідомить про помилку під час запуску та одразу завершить роботу.

Конфігурація режиму авторизації через командний рядок

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.8 [stable]

Ви можете використовувати наступні режими:

  • --authorization-mode=ABAC (режим контролю доступу на основі атрибутів)
  • --authorization-mode=RBAC (режим контролю доступу на основі ролей)
  • --authorization-mode=Node (авторизатор вузлів)
  • --authorization-mode=Webhook (режим авторизації вебхуком)
  • --authorization-mode=AlwaysAllow (завжди дозволяє запити; несе ризики безпеки)
  • --authorization-mode=AlwaysDeny (завжди відхиляє запити)

Ви можете вибрати більше одного режиму авторизації; наприклад: --authorization-mode=Node,Webhook

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

Ви не можете поєднувати аргумент командного рядка --authorization-mode з аргументом командного рядка --authorization-config, який використовується для налаштування авторизації за допомогою локального файлу.

Для отримання додаткової інформації про аргументи командного рядка для API сервера, читайте довідник по kube-apiserver.

Налаштування API сервера за допомогою конфігураційного файлу авторизації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta] (стандартно увімкнено: true)

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

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

Ви вказуєте шлях до конфігурації авторизації за допомогою аргументу командного рядка --authorization-config.

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

Приклад конфігурації

---
#
# НЕ ВИКОРИСТОВУЙТЕ КОНФІГУРАЦІЮ ТАК, ЯК ВОНА Є. ЦЕ ПРИКЛАД.
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthorizationConfiguration
authorizers:
  * type: Webhook
    # Назва, що використовується для опису авторизатора
    # Це явно використовується в механізмі моніторингу для метрик
    # Примітка:
    #   - Перевірка цього поля схожа на перевірку міток K8s на сьогодні.
    # Обовʼязково, немає стандартного значення
    name: webhook
    webhook:
      # Тривалість кешування відповідей 'authorized' від вебхука
      # авторизатора.
      # Те саме, що і встановлення прапорця `--authorization-webhook-cache-authorized-ttl`.
      # Стандартно: 5m0s
      authorizedTTL: 30s
      # Тривалість кешування відповідей 'unauthorized' від вебхука
      # авторизатора.
      # Те саме, що і встановлення прапорця `--authorization-webhook-cache-unauthorized-ttl`.
      # Стандартно: 30 с
      unauthorizedTTL: 30s
      # Тайм-аут для запиту вебхука
      # Максимально допустимий: 30 с
      # Обовʼязково, немає стандартного значення
      timeout: 3s
      # Версія API для SubjectAccessReview в authorization.k8s.io, яка
      # надсилається до вебхука та очікується від нього.
      # Те саме, що і встановлення прапорця `--authorization-webhook-version`.
      # Обовʼязково, немає стандартного значення
      # Допустимі значення: v1beta1, v1
      subjectAccessReviewVersion: v1
      # MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview
      # за якою оцінюються вирази CEL
      # Допустимі значення: v1
      # Обовʼязково, немає стандартного значення
      matchConditionSubjectAccessReviewVersion: v1
      # Керує рішенням авторизації, коли запит вебхука не вдалося
      # виконати або отримано некоректну відповідь або помилки під час оцінки
      # виразів matchConditions.
      # Допустимі значення:
      #   - NoOpinion: продовжувати до наступних авторизаторів, щоб перевірити, чи дозволяє один з них запит
      #   - Deny: відхиляти запит без консультації з наступними авторизаторами
      # Обовʼязково, немає стандартного значення
      failurePolicy: Deny
      connectionInfo:
        # Керує тим, як вебхук повинен спілкуватися з сервером.
        # Допустимі значення:
        # - KubeConfigFile: використовуйте файл, вказаний у kubeConfigFile для пошуку сервера.
        # - InClusterConfig: використовуйте конфігурацію внутрішнього кластера для виклику API SubjectAccessReview,
        #   що розміщується kube-apiserver. Цей режим не дозволяється для kube-apiserver.
        type: KubeConfigFile
        # Шлях до файлу KubeConfigFile для інформації про підключення
        # Обовʼязково, якщо connectionInfo.Type є KubeConfigFile
        kubeConfigFile: /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: Node
    name: node
  * type: RBAC
    name: rbac
  * type: Webhook
    name: in-cluster-authorizer
    webhook:
      authorizedTTL: 5 хв
      unauthorizedTTL: 30 с
      timeout: 3 с
      subjectAccessReviewVersion: v1
      failurePolicy: NoOpinion
      connectionInfo:
        type: InClusterConfig

Під час налаштування ланцюжка авторизації за допомогою файлу конфігурації переконайтеся, що всі вузли панелі управління мають однаковий вміст файлу. Зверніть увагу на конфігурацію API сервера при оновленні / зниженні версії вашого кластера. Наприклад, якщо ви оновлюєтеся з Kubernetes 1.30 до Kubernetes 1.31, вам потрібно переконатися, що файл конфігурації має формат, який розуміє Kubernetes 1.31, перш ніж ви оновите кластер. Якщо ви знижуєте версію до 1.30, вам потрібно відповідно налаштувати конфігурацію.

Конфігурація авторизації та перезавантаження

Kubernetes перезавантажує файл конфігурації авторизації, коли API сервер виявляє зміну у файлі, а також за 60-секундним графіком, якщо події змін не спостерігаються.

Підвищення привілеїв через створення або редагування робочих навантажень

Користувачі, які можуть створювати/редагувати 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

Вивід подібний до цього:

yes

kubectl auth can-i create deployments --namespace prod

Вивід подібний до цього:

no

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

kubectl auth can-i list secrets --namespace dev --as dave

Вивід подібний до цього:

no

Так само, щоб перевірити, чи може ServiceAccount з іменем dev-sa в просторі імен dev отримати списки Podʼів в просторі імен target:

kubectl auth can-i list pods \
    --namespace target \
    --as system:serviceaccount:dev:dev-sa

Вивід подібний до цього:

no

SelfSubjectAccessReview є частиною групи API authorization.k8s.io, яка викладає авторизацію сервера API для зовнішніх служб. Інші ресурси у цій групі включають:

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

Ці API можна опитати, створивши звичайні ресурси Kubernetes, де поле відповіді status поверненого обʼєкта є результатом запиту. Наприклад:

kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    verb: create
    namespace: dev
EOF

Створений SelfSubjectAccessReview схожий на:

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    namespace: dev
    verb: create
status:
  allowed: true
  denied: false

Що далі

3.4 - Використання RBAC авторизації

Контроль доступу на основі ролей (RBAC) — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів у вашій організації.

RBAC авторизація використовує групу API rbac.authorization.k8s.io група API для прийняття рішень щодо авторизації, дозволяючи вам динамічно налаштовувати політики через Kubernetes API.

Щоб увімкнути RBAC, запустіть API сервер з прапорцем --authorization-mode, встановленим на список, розділений комами, що включає RBAC; наприклад:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Обʼєкти API

RBAC API визначає чотири типи обʼєктів Kubernetes: Role, ClusterRole, RoleBinding та ClusterRoleBinding. Ви можете описувати або змінювати обʼєкти RBAC за допомогою таких інструментів, як kubectl, так само як і будь-який інший обʼєкт Kubernetes.

Role та ClusterRole

RBAC Role або ClusterRole містять правила, які представляють набір дозволів. Дозволи є виключно адитивними (немає правил "заборони").

Role завжди встановлює дозволи в межах певного простору імен; коли ви створюєте Role, ви повинні вказати простір імен, до якого вона належить.

ClusterRole, на відміну, є ресурсом, який не належить до простору імен. Ресурси мають різні назви (Role і ClusterRole), оскільки обʼєкт Kubernetes завжди повинен бути або привʼязаним до простору імен, або не привʼязаним до простору імен; він не може бути одночасно і тим, і іншим.

ClusterRole мають кілька використань. Ви можете використовувати ClusterRole для:

  1. визначення дозволів на ресурси, що належать до простору імен, і надання доступу в межах окремих просторів імен
  2. визначення дозволів на ресурси, що належать до простору імен, і надання доступу до всіх просторів імен
  3. визначення дозволів на ресурси, що належать до кластера

Якщо ви хочете визначити роль в межах простору імен, використовуйте Role; якщо ви хочете визначити роль для всього кластера, використовуйте ClusterRole.

Приклад Role

Ось приклад Role в просторі імен "default", яку можна використовувати для надання доступу на читання до Podʼів:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" означає основну групу API
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Приклад ClusterRole

ClusterRole може бути використана для надання тих самих дозволів, що й Role. Оскільки ClusterRole стосуються всього кластера, ви також можете використовувати їх для надання доступу до:

  • ресурсів, що належать до кластера (наприклад, вузли)

  • точок доступу, що не є ресурсами (наприклад, /healthz)

  • ресурсів, що належать до простору імен (наприклад, контейнерів), в усіх просторах імен

    Наприклад: ви можете використовувати ClusterRole для дозволу конкретному користувачу виконувати kubectl get pods --all-namespaces.

Ось приклад ClusterRole, яку можна використовувати для надання доступу на читання Secretʼів в будь-якому просторі імен або в усіх просторах імен (залежно від того, як вона звʼязана):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" пропущено, оскільки ClusterRole не привʼязані до простору імен
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів Secret
  # це "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Назва обʼєкта Role або ClusterRole повинна бути дійсною назвою сегмента шляху.

RoleBinding та ClusterRoleBinding

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: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# Ви можете вказати більше одного "субʼєкта"
- kind: User
  name: jane # "name" чутливе до регістру
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" вказує на звʼязування з Role / ClusterRole
  kind: Role # має бути Role або ClusterRole
  name: 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: RoleBinding
metadata:
  name: read-secrets
  #
  # Простір імен RoleBinding визначає, де надаються дозволи.
  # Це надає дозволи лише в просторі імен "development".
  namespace: development
subjects:
- kind: User
  name: dave # Name чутливе до регістру
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Приклад ClusterRoleBinding

Щоб надати дозволи на рівні всього кластера, ви можете використовувати ClusterRoleBinding. Наступний ClusterRoleBinding дозволяє будь-якому користувачу з групи "manager" читати Secretʼи в будь-якому просторі імен.

apiVersion: rbac.authorization.k8s.io/v1
# Це звʼязування кластерної ролі дозволяє будь-якому користувачу з групи "manager" читати Secretʼи в будь-якому просторі імен.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name чутливе до регістру
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Після створення звʼязування ви не можете змінити Role або ClusterRole, на які вони посилаються. Якщо ви спробуєте змінити roleRef звʼязування, ви отримаєте помилку валідації. Якщо ви дійсно хочете змінити roleRef для звʼязування, вам потрібно видалити обʼєкт звʼязування і створити новий.

Існує дві причини для цього обмеження:

  1. Роблячи roleRef незмінним, можна надати комусь дозвіл update на наявний обʼєкт звʼязування, щоб він міг керувати списком субʼєктів, без можливості змінити роль, яка надається цим субʼєктам.
  2. Звʼязування з іншою роллю є принципово іншим звʼязуванням. Вимога видалення/створення нового звʼязування для зміни 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, напишіть:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

Ви також можете посилатися на ресурси за назвою для певних запитів через список resourceNames. Коли зазначено, запити можуть бути обмежені окремими екземплярами ресурсу. Ось приклад, що обмежує субʼєкт лише до get або update ConfigMap з назвою my-configmap:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів ConfigMap є "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

Замість того, щоб посилатися на окремі resources, apiGroups і verbs, ви можете використовувати символ підстановки *, щоб посилатися на всі такі обʼєкти. Для nonResourceURLs ви можете використовувати символ підстановки * як суфікс для глобального збігу. Для resourceNames порожній набір означає, що все дозволено. Ось приклад, що дозволяє виконувати будь-яку поточну і майбутню дію для всіх поточних та майбутніх ресурсів в API групі example.com. Це схоже на вбудовану роль cluster-admin.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: example.com-superuser # НЕ ВИКОРИСТОВУЙТЕ ЦЮ РОЛЬ, ЦЕ ЛИШЕ ПРИКЛАД
rules:
- apiGroups: ["example.com"]
  resources: ["*"]
  verbs: ["*"]

Агреговані ClusterRole

Ви можете агрегувати декілька ClusterRole в одну комбіновану ClusterRole. Контролер, який працює як частина панелі управління кластера, слідкує за обʼєктами ClusterRole з встановленим aggregationRule. aggregationRule визначає мітку селектора, яку використовує контролер для вибору інших обʼєктів ClusterRole, що мають бути обʼєднані у поле rules цього обʼєкта.

Ось приклад агрегованої ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  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/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    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/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Додайте ці дозволи до стандартних ролей "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: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Додайте ці дозволи до стандартної ролі "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"; або числові ідентифікатори користувачів, представлені у вигляді рядків. Вам, як адміністратору кластера, належить налаштувати модулі автентифікації, щоб автентифікація генерувала імена користувачів у бажаному форматі.

У Kubernetes модулі Автентифікатора надають інформацію про групи. Групи, як і користувачі, представлені у вигляді рядків, і цей рядок не має жодних вимог до формату, крім того, що префікс system: зарезервований.

ServiceAccounts мають імена з префіксом system:serviceaccount:, і належать до груп, що мають імена з префіксом system:serviceaccounts:.

Приклади RoleBinding

Наступні приклади є фрагментами RoleBinding, що показують лише секцію subjects.

Для користувача з імʼям alice@example.com:

subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

Для групи з імʼям frontend-admins:

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

Для стандартного службового облікового запису у просторі імен "kube-system":

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

Для всіх службових облікових записів у просторі імен "qa":

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

Для всіх службових облікових записів у будь-якому просторі імен:

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

Для всіх автентифікованих користувачів:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

Для всіх неавтентифікованих користувачів:

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Для всіх користувачів:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Стандартні ролі та привʼязки ролей

API-сервери створюють набір стандартних обʼєктів ClusterRole і ClusterRoleBinding. Багато з них мають префікс system:, що вказує на те, що ресурс безпосередньо керується панеллю управління кластера. Усі стандартні ролі та привʼязки ролей мають мітку kubernetes.io/bootstrapping=rbac-defaults.

Автоматичне узгодження

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

Щоб відмовитися від цього узгодження, встановіть анотацію rbac.authorization.kubernetes.io/autoupdate на стандартній кластерній ролі або стандартній RoleBinding у значення false. Зверніть увагу, що відсутність стандартних дозволів та субʼєктів може призвести до несправних кластерів.

Автоматичне узгодження стандартно увімкнено, якщо авторизатор RBAC активний.

Ролі виявлення API

Стандартні кластерні привʼязки ролей дозволяють неавторизованим і авторизованим користувачам читати інформацію про API, яка вважається безпечною для публічного доступу (включаючи CustomResourceDefinitions). Щоб вимкнути анонімний неавторизований доступ, додайте прапорець --anonymous-auth=false до конфігурації API-сервера.

Щоб переглянути конфігурацію цих ролей через kubectl, запустіть:

kubectl get clusterroles system:discovery -o yaml
Ролі виявлення 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 з однією або кількома з наступних міток:

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

Стандартна ClusterRoleСтандартна ClusterRoleBindingОпис
cluster-adminГрупа system:mastersДозволяє доступ суперкористувача для виконання будь-якої дії на будь-якому ресурсі. При використанні в 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-schedulersystem:kube-scheduler користувачДозволяє доступ до ресурсів, необхідних компоненту планувальника.
system:volume-schedulersystem:kube-scheduler користувачДозволяє доступ до ресурсів обʼєму, необхідних компоненту kube-scheduler.
system:kube-controller-managersystem:kube-controller-manager користувачДозволяє доступ до ресурсів, необхідних компоненту менеджера контролерів. Дозволи, необхідні окремим контролерам, детально описані в ролях контролерів.
system:nodeНемаєДозволяє доступ до ресурсів, необхідних для kubelet, включаючи доступ на читання до всіх секретів та доступ на запис до всіх обʼєктів стану Podʼів.

Ви повинні використовувати Node authorizer та втулок допуску NodeRestriction замість ролі system:node та дозволяти надання доступу до API для kubelet на основі Podʼів, які заплановано для запуску на них.

Роль system:node існує лише для сумісності з кластерами Kubernetes, оновленими з версій до v1.8.

system:node-proxiersystem:kube-proxy користувачДозволяє доступ до ресурсів, необхідних компоненту kube-proxy.

Ролі інших компонентів

Стандартна ClusterRoleСтандартна ClusterRoleBindingОпис
system:auth-delegatorНемаєДозволяє делеговані перевірки автентифікації та авторизації. Це зазвичай використовується серверами надбудов API для уніфікованої автентифікації та авторизації.
system:heapsterНемаєРоль для компонента Heapster (застарілий).
system:kube-aggregatorНемаєРоль для компонента kube-aggregator.
system:kube-dnskube-dns службовий обліковий запис у просторі імен kube-systemРоль для компонента kube-dns.
system:kubelet-api-adminНемаєДозволяє повний доступ до API kubelet.
system:node-bootstrapperНемаєДозволяє доступ до ресурсів, необхідних для виконання початкового завантаження kubelet TLS.
system:node-problem-detectorНемаєРоль для компонента node-problem-detector.
system:persistent-volume-provisionerНемаєДозволяє доступ до ресурсів, необхідних для більшості динамічних провізорів томів.
system:monitoringsystem:monitoring групаДозволяє доступ на читання до точок доступу моніторингу панелі управління (тобто kube-apiserver точки доступу придатності та готовності (/healthz, /livez, /readyz), індивідуальні точки доступу перевірки стану (/healthz/*, /livez/*, /readyz/*) та /metrics). Зверніть увагу, що індивідуальні точки доступу перевірки стану та точка доступу метрик можуть розкривати конфіденційну інформацію.

Ролі для вбудованих контролерів

Менеджер контролерів Kubernetes запускає контролери, які вбудовані в панель управління Kubernetes. Коли його викликають з --use-service-account-credentials, kube-controller-manager запускає кожен контролер використовуючи окремий службовий обліковий запис. Для кожного вбудованого контролера існують відповідні ролі з префіксом system:controller:. Якщо менеджер контролерів не запускається з --use-service-account-credentials, він виконує всі контрольні цикли використовуючи власні облікові дані, які повинні мати всі відповідні ролі. Ці ролі включають:

  • system:controller:attachdetach-controller
  • system:controller:certificate-controller
  • system:controller:clusterrole-aggregation-controller
  • system:controller:cronjob-controller
  • system:controller:daemon-set-controller
  • system:controller:deployment-controller
  • system:controller:disruption-controller
  • system:controller:endpoint-controller
  • system:controller:expand-controller
  • system:controller:generic-garbage-collector
  • system:controller:horizontal-pod-autoscaler
  • system:controller:job-controller
  • system:controller:namespace-controller
  • system:controller:node-controller
  • system:controller:persistent-volume-binder
  • system:controller:pod-garbage-collector
  • system:controller:pv-protection-controller
  • system:controller:pvc-protection-controller
  • system:controller:replicaset-controller
  • system:controller:replication-controller
  • system:controller:resourcequota-controller
  • system:controller:root-ca-cert-publisher
  • system:controller:route-controller
  • system:controller:service-account-controller
  • system:controller:service-controller
  • system:controller:statefulset-controller
  • system:controller:ttl-controller

Запобігання ескалації привілеїв і початкове налаштування

API RBAC запобігає ескалації привілеїв користувачами шляхом редагування ролей або привʼязок ролей. Оскільки це реалізується на рівні API, це застосовується навіть коли авторизатор RBAC не використовується.

Обмеження на створення або оновлення ролей

Ви можете створити/оновити роль, тільки якщо виконується хоча б одна з наступних умов:

  1. Ви вже маєте всі дозволи, що містяться в ролі, в тій же області, що й обʼєкт, який модифікується (кластерний рівень для ClusterRole, у тому ж просторі імен або кластерний рівень для Role).
  2. Вам надано явний дозвіл виконувати дієслово escalate для ресурсу roles або clusterroles в групі API rbac.authorization.k8s.io.

Наприклад, якщо user-1 не має можливості отриамння переліку Secrets на кластерному рівні, він не може створити ClusterRole, що містить цей дозвіл. Щоб дозволити користувачу створювати/оновлювати ролі:

  1. Надайте йому роль, що дозволяє створювати/оновлювати обʼєкти Role або ClusterRole, те що треба.
  2. Надати йому дозвіл включати конкретні дозволи в ролі, які він створює/оновлює:
    • неявно, надаючи йому ці дозволи (якщо він спробує створити або модифікувати Role або ClusterRole з дозволами, які йому самому не надані, запит до API буде заборонений)
    • або явно дозволити вказувати будь-які дозволи в Role або ClusterRole, надаючи йому дозвіл виконувати дієслово escalate для ресурсів roles або clusterroles в групі API rbac.authorization.k8s.io.

Обмеження на створення або оновлення привʼязок ролей

Ви можете створити/оновити привʼязку ролі, тільки якщо вже маєте всі дозволи, що містяться в згаданій ролі (в тій же області, що й привʼязка ролі) або якщо вам надано дозвіл виконувати дієслово bind для згаданої ролі. Наприклад, якщо user-1 не має можливості отримувати перелік Secrets на кластерному рівні, він не може створити ClusterRoleBinding для ролі, яка надає цей дозвіл. Щоб дозволити користувачу створювати/оновлювати привʼязки ролей:

  1. Надати йому роль, що дозволяє створювати/оновлювати обʼєкти RoleBinding або ClusterRoleBinding, як необхідно.
  2. Надати йому дозволи, необхідні для привʼязки певної ролі:
    • неявно, надаючи йому дозволи, що м стяться в ролі.
    • явно, надаючи йому дозвіл виконувати дієслово bind для певної Role (або ClusterRole).

Наприклад, цей ClusterRole і RoleBinding дозволять user-1 надавати іншим користувачам ролі admin, edit і view у просторі імен user-1-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  # пропустіть resourceNames, щоб дозволити привʼязку будь-якої ClusterRole
  resourceNames: ["admin","edit","view"] 
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: 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:

    kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

  • Створити ClusterRole з назвою "pod-reader" зі специфікованими resourceNames:

    kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

  • Створити ClusterRole з назвою "foo" зі специфікованими apiGroups:

    kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps

  • Створити ClusterRole з назвою "foo" з дозволами на субресурси:

    kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

  • Створити ClusterRole з назвою "foo" зі специфікованими nonResourceURL:

    kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*

  • Створити ClusterRole з назвою "monitoring" зі специфікованим aggregationRule:

    kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

kubectl create rolebinding

Надає Role або ClusterRole в межах певного простору імен. Приклади:

  • В межах простору імен "acme" надати дозволи з ClusterRole "admin" користувачу з імʼям "bob":

    kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

  • В межах простору імен "acme" надати дозволи з ClusterRole "view" службовому обліковому запису в просторі імен "acme" з імʼям "myapp":

    kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

  • В межах простору імен "acme" надати дозволи з ClusterRole "view" службовому обліковому запису в просторі імен "myappnamespace" з імʼям "myapp":

    kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme

kubectl create clusterrolebinding

Надає ClusterRole в межах усього кластеру (всі простори імен). Приклади:

  • В межах усього кластеру надати дозволи з ClusterRole "cluster-admin" користувачу з імʼям "root":

    kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

  • В межах усього кластеру надати дозволи з ClusterRole "system:node-proxier" користувачу з імʼям "system:kube-proxy":

    kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy

  • В межах усього кластеру надати дозволи з ClusterRole "view" службовому обліковому запису з імʼям "myapp" у просторі імен "acme":

    kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

kubectl auth reconcile

Створює або оновлює обʼєкти API rbac.authorization.k8s.io/v1 з файлу маніфесту.

Відсутні обʼєкти створюються, і простір імен для обʼєктів у просторі імен створюється за потреби.

Наявні ролі оновлюються, щоб включати дозволи з вхідних обʼєктів, і видаляти зайві дозволи, якщо вказано --remove-extra-permissions.

Наявні привʼязки оновлюються, щоб включати субʼєкти з вхідних обʼєктів, і видаляти зайві субʼєкти, якщо вказано --remove-extra-subjects.

Приклади:

  • Тестове застосування файлу маніфесту обʼєктів RBAC, відображаючи зміни, які будуть зроблені:

    kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client

  • Застосування файлу маніфесту обʼєктів RBAC, збереження будь-яких зайвих дозволів (в ролях) і зайвих субʼєктів (в привʼязках):

    kubectl auth reconcile -f my-rbac-rules.yaml

  • Застосування файлу маніфесту обʼєктів RBAC, видалення будь-яких зайвих дозволів (в ролях) і зайвих субʼєктів (в привʼязках):

    kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions

Права доступу ServiceAccount

Типові політики RBAC надають обмежені права компонентам панелі управління, вузлам і контролерам, але не надають жодних дозволів службовим обліковим записам за межами простору імен kube-system (поза межами дозволів, наданих ролями виявлення API).

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

Підходи від найбезпечніших до найменш безпечних:

  1. Надання ролі для службового облікового запису для конкретного застосунку (найкращий варіант)

    Це вимагає від застосунку зазначення serviceAccountName в його специфікації Pod, і створення службового облікового запису (через API, маніфест програми, kubectl create serviceaccount, тощо).

    Наприклад, надати права лише на читання в межах "my-namespace" службовому обліковому запису "my-sa":

    kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace

  2. Надання ролі службовому обліковому запису "default" в просторі імен

    Якщо програма не зазначає serviceAccountName, вона використовує службовий обліковий запис "default".

    Наприклад, надати права лише на читання в межах "my-namespace" службовому обліковому запису "default":

    kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:default \
  --namespace=my-namespace

    Багато надбудов працюють від імені службового облікового запису "default" у просторі імен kube-system. Щоб дозволити цим надбудовам працювати з правами суперкористувача, надайте права cluster-admin службовому обліковому запису "default" у просторі імен kube-system.

    kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

  3. Надання ролі всім службовим обліковим записам у просторі імен

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

    Наприклад, надати права лише на читання в межах "my-namespace" усім службовим обліковим записам у цьому просторі імен:

    kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

  4. Надання обмеженої ролі всім службовим обліковим записам у кластері (не рекомендується)

    Якщо ви не хочете керувати дозволами по кожному простору імен, ви можете надати кластерну роль усім службовим обліковим записам у кластері.

    Наприклад, надати права лише на читання в усіх просторах імен усім службовим обліковим записам у кластері:

    kubectl create clusterrolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts

  5. Надання прав суперкористувача всім службовим обліковим записам у кластері (категорично не рекомендується)

    Якщо вам не важливо розподіляти дозволи взагалі, ви можете надати права суперкористувача всім службовим обліковим записам.

    kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

Права запису для EndpointSlices і Endpoints

Кластери Kubernetes, створені до версії Kubernetes v1.22, включають права запису для EndpointSlices (і Endpoints) у ролях "edit" і "admin". У рамках помʼякшення наслідків CVE-2021-25740, цей доступ не є частиною агрегованих ролей у кластерах, створених із використанням Kubernetes v1.22 або пізніших версій.

Кластери, які були оновлені до Kubernetes v1.22, не підпадають під цю зміну. Оголошення CVE включає вказівки щодо обмеження цього доступу в поточних кластерах.

Якщо ви хочете, щоб нові кластери зберігали цей рівень доступу в агрегованих ролях, ви можете створити наступну ClusterRole:

access/endpoints-aggregated.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  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:

--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json

Щоб детально пояснити цей перший параметр командного рядка: якщо раніші авторизатори, такі як 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.

Після переходу на використання RBAC, ви повинні налаштувати контроль доступу для вашого кластера, щоб забезпечити відповідність вашим інформаційним вимогам безпеки.

3.5 - Використання авторизації вузлів

Авторизація вузлів — це режим авторизації спеціального призначення, який спеціально авторизує запити API, зроблені kubelet-ами.

Огляд

Авторизатор вузлів дозволяє kubelet-ам виконувати операції з API. Це включає:

Операції читання:

  • services
  • endpoints
  • nodes
  • pods
  • secrets, configmaps, persistent volume claims та persistent volumes, що стосуються Podʼів, привʼязаних до вузла kubelet-а
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha] (стандартно увімкнено: false)

Коли функціональну можливість AuthorizeNodeWithSelectors увімкнено (разом із передумовою AuthorizeWithSelectors), kubelets можуть читати лише власні обʼєкти Node і можуть читати лише Podʼи, привʼязані до їхнього вузла.

Операції запису:

  • вузли та статус вузлів (увімкніть втулок допуску NodeRestriction, щоб обмежити kubelet у зміні свого власного вузла)
  • поди та статус подів (увімкніть втулок допуску NodeRestriction, щоб обмежити kubelet у зміні подів, привʼязаних до себе)
  • події

Операції, повʼязані з авторизацією:

  • доступ на читання/запис API CertificateSigningRequests для TLS початкового запуску
  • можливість створювати 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 API
apiVersion: v1
# тип API обʼєкта
kind: Config
# кластери відносяться до віддаленого сервісу
clusters:
  - name: name-of-remote-authz-service
    cluster:
      # CA для перевірки віддаленого сервісу
      certificate-authority: /path/to/ca.pem
      # URL віддаленого сервісу для запитів. Має використовувати 'https'. Не може включати параметри.
      server: https://authz.example.com/authorize

# користувачі відносяться до конфігурації webhook API сервера
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # сертифікат для використання webhook втулком
      client-key: /path/to/key.pem          # ключ, що відповідає сертифікату

# файли kubeconfig вимагають контекст. Вкажіть один для API сервера.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authz-service
    user: name-of-api-server
  name: webhook

Запити корисного навантаження

При ухваленні рішення про авторизацію, API сервер надсилає JSON- серіалізований обʼєкт authorization.k8s.io/v1beta1 SubjectAccessReview, що описує дію. Цей обʼєкт містить поля, що описують користувача, який намагається зробити запит, та деталі про ресурс, до якого здійснюється доступ, або атрибути запиту.

Зверніть увагу, що обʼєкти API webhook підлягають тим самим правилам сумісності версій, що й інші обʼєкти API Kubernetes. Імплементатори повинні бути обізнані з менш суворими обіцянками сумісності для бета-обʼєктів і перевіряти поле "apiVersion" запиту для забезпечення правильної десеріалізації. Додатково, API сервер повинен увімкнути групу розширень API authorization.k8s.io/v1beta1 (--runtime-config=authorization.k8s.io/v1beta1=true).

Приклад тіла запиту:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "kittensandponies",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    },
    "user": "jane",
    "group": [
      "group1",
      "group2"
    ]
  }
}

Віддалений сервіс має заповнити поле status запиту і відповісти, дозволяючи або забороняючи доступ. Поле spec у відповіді ігнорується і може бути пропущене. Дозвільна відповідь виглядатиме так:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": true
  }
}

Для заборони доступу є два методи.

Перший метод є кращим у більшості випадків і вказує, що 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"
  }
}

Доступ до нересурсних шляхів здійснюється як:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "nonResourceAttributes": {
      "path": "/debug",
      "verb": "get"
    },
    "user": "jane",
    "group": [
      "group1",
      "group2"
    ]
  }
}
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha] (стандартно увімкнено: false)

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

Документація API SubjectAccessReview надає вказівки щодо того, як ці поля мають інтерпретуватися і оброблятися вебхуками авторизації, зокрема використанням розібраних вимог замість сирих рядків селекторів та як безпечно обробляти невідомі оператори.

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "verb": "list",
      "group": "",
      "resource": "pods",
      "fieldSelector": {
        "requirements": [
          {"key":"spec.nodeName", "operator":"In", "values":["mynode"]}
        ]
      },
      "labelSelector": {
        "requirements": [
          {"key":"example.com/mykey", "operator":"In", "values":["myvalue"]}
        ]
      }
    },
    "user": "jane",
    "group": [
      "group1",
      "group2"
    ]
  }
}

Нересурсні шляхи включають: /api, /apis, /metrics, /logs, /debug, /healthz, /livez, /openapi/v2, /readyz та /version. Клієнти потребують доступу до /api, /api/*, /apis, /apis/*, та /version для визначення, які ресурси та версії присутні на сервері. Доступ до інших нересурсних шляхів може бути заборонений без обмеження доступу до REST API.

За подальшою інформацією звертайтеся до документації SubjectAccessReview API та імплементації 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).

Властивість, встановлена на "*", буде збігатися з будь-яким значенням відповідного атрибута.

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

Щоб дозволити будь-якому автентифікованому користувачеві зробити щось, створіть політику з властивістю 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, ви можете збільшити рівень деталізації:

kubectl --v=8 version

Приклади

  1. Alice може робити все з усіма ресурсами:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}

  2. Kubelet може читати будь-які Podʼи:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}

  3. Kubelet може читати та записувати події:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}

  4. Bob може лише читати Podʼи в просторі імен "projectCaribou":

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}

  5. Будь-хто може робити запити тільки для читання на всі нересурсні шляхи:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
 {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}

Приклад повного файлу

Коротка нотатка про службові облікові записи

Кожен службовий обліковий запис має відповідне імʼя користувача ABAC, і імʼя цього службового облікового запису генерується згідно з конвенцією щодо найменування:

system:serviceaccount:<namespace>:<serviceaccountname>

Створюючи новий простір імен, створюється новий службовий обліковий запис у наступному форматі:

system:serviceaccount:<namespace>:default

Наприклад, якщо ви хочете надати стандартному службовому обліковому запису (у просторі імен kube-system) повні привілеї в API за допомогою ABAC, ви додаєте цей рядок до файлу політики:

{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}

apiserver повинен бути перезапущений, щоб використати нові рядки.

3.8 - Контролери допуску

Ця сторінка надає огляд контролерів допуску.

Що це таке?

Контролер допуску — це фрагмент коду, який перехоплює запити до сервера API Kubernetes перед збереженням обʼєкта, але після того, як запит був автентифікований та авторизований.

Контролери допуску можуть бути валідаційними, модифікуючими або обома. Модифікуючі контролери можуть змінювати обʼєкти, повʼязані з запитами, які вони допускають; валідаційні контролери не можуть цього робити.

Контролери допуску обмежують запити на створення, видалення, зміну обʼєктів. Контролери допуску також можуть блокувати нестандартні дієслова, такі як запити на підключення до Podʼа через проксі сервера API. Контролери допуску не блокують (і не можуть) запити на читання (get, watch або list) обʼєктів.

Контролери допуску в Kubernetes 1.31 складаються зі списку нижче, вбудовані у двійковий файл kube-apiserver і можуть бути налаштовані тільки адміністратором кластера. У цьому списку є два спеціальні контролери: MutatingAdmissionWebhook і ValidatingAdmissionWebhook. Вони виконують модифікуючі та валідаційні (відповідно) вебхуки контролю допуску, які налаштовуються в API.

Етапи контролю допуску

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

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

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

Чому вони потрібні?

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

Як увімкнути контролер допуску?

Прапорець сервера API Kubernetes enable-admission-plugins приймає через кому список втулків контролю допуску, які слід викликати перед зміною обʼєктів у кластері. Наприклад, наступна команда увімкне втулки контролю допуску NamespaceLifecycle та LimitRanger:

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

Як вимкнути контролер допуску?

Прапорець сервера API Kubernetes disable-admission-plugins приймає через кому список втулків контролю допуску, які слід вимкнути, навіть якщо вони є у списку втулків, що є стандартно увімкненими.

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

Які втулки є стандартно увімкненими?

Щоб побачити, які втулки допуску увімкнені:

kube-apiserver -h | grep enable-admission-plugins

У Kubernetes 1.31 стандартно увімкнені такі втулки:

CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook

Що робить кожен контролер допуску?

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:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: EventRateLimit
    path: eventconfig.yaml
...

Є чотири типи обмежень, які можна вказати у конфігурації:

  • Server: Всі запити подій (створення або зміни), що отримує API-сервер, використовують один спільний кошик.
  • Namespace: Кожен простір імен має виділений кошик.
  • User: Кожен користувач отримує кошик.
  • SourceAndObject: Кошик призначається кожній комбінації джерела та обʼєкта події.

Нижче наведено приклад eventconfig.yaml для такої конфігурації:

apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
  - type: Namespace
    qps: 50
    burst: 100
    cacheSize: 2000
  - type: User
    qps: 10
    burst: 50

Дивіться API конфігурації EventRateLimit (v1alpha1) для отримання додаткових деталей.

Цей контролер допуску стандартно вимкнено.

ExtendedResourceToleration

Тип: Модифікуючий.

Цей втулок полегшує створення виділених вузлів з розширеними ресурсами. Якщо оператори хочуть створити виділені вузли з розширеними ресурсами (наприклад, 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:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    path: imagepolicyconfig.yaml
...

Альтернативно, ви можете вбудувати конфігурацію безпосередньо у файл:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: <path-to-kubeconfig-file>
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: true

Конфігураційний файл ImagePolicyWebhook повинен посилатися на файл у форматі kubeconfig, який налаштовує зʼєднання з бекендом. Бекенд повинен здійснювати комунікацію через TLS.

Поле cluster у файлі kubeconfig має посилатися на віддалений сервіс, а поле user повинно містити дані авторизації.

# clusters посилається на віддалений сервіс.
clusters:
  - name: name-of-remote-imagepolicy-service
    cluster:
      certificate-authority: /path/to/ca.pem    # CA для верифікації віддаленого сервісу.
      server: https://images.example.com/policy # URL віддаленого сервісу для запитів. Повинен використовувати 'https'.

# users посилається на конфігурацію вебхука API-сервера.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # сертифікат для використання контролером допуску вебхука
      client-key: /path/to/key.pem          # ключ, що відповідає сертифікату

Для додаткової конфігурації HTTP дивіться документацію kubeconfig.

Вміст запитів

Під час прийняття рішення про допуск, API-сервер надсилає POST-запит з серіалізованим у форматі JSON обʼєктом imagepolicy.k8s.io/v1alpha1 ImageReview, що описує дію. Цей обʼєкт містить поля, що описують контейнери, які підлягають допуску, а також будь-які анотації Podʼа, що відповідають *.image-policy.k8s.io/*.

Приклад тіла запиту:

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "spec": {
    "containers": [
      {
        "image": "myrepo/myimage:v1"
      },
      {
        "image": "myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
      }
    ],
    "annotations": {
      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
    },
    "namespace": "mynamespace"
  }
}

Віддалений сервіс повинен заповнити поле status запиту і відповісти з дозволом або відмовою доступу. Поле spec тіла відповіді ігнорується, і його можна не включати. Відповідь, яка дозволяє доступ, виглядатиме так:

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": true
  }
}

Щоб відмовити у доступі, сервіс відповість так:

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": false,
    "reason": "image currently blacklisted"
  }
}

Для додаткової документації дивіться API imagepolicy.v1alpha1.

Розширення за допомогою анотацій

Усі анотації на 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.

Дивіться довідник LimitRange API та приклад LimitRange для отримання додаткової інформації.

MutatingAdmissionWebhook

Тип: Модифікуючий.

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

Цей контролер допуску (як випливає з назви) працює лише на етапі модифікації.

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

Якщо ви вимкнете 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/hostname
    • kubernetes.io/arch
    • kubernetes.io/os
    • beta.kubernetes.io/instance-type
    • node.kubernetes.io/instance-type
    • failure-domain.beta.kubernetes.io/region (застаріло)
    • failure-domain.beta.kubernetes.io/zone (застаріло)
    • topology.kubernetes.io/region
    • topology.kubernetes.io/zone
    • мітки з префіксом kubelet.kubernetes.io/
    • мітки з префіксом node.kubernetes.io/

Використання будь-яких інших міток під префіксами 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, підтримують розширення тому:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

Для отримання додаткової інформації про persistent volume claims, дивіться PersistentVolumeClaims.

PodNodeSelector

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.5 [alpha]

Тип: Валідаційний.

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

Цей контролер допуску стандартно вимкнено.

Формат конфігураційного файлу

PodNodeSelector використовує конфігураційний файл для налаштування параметрів поведінки бекенду. Зверніть увагу, що формат конфігураційного файлу буде змінено на версійований файл у майбутньому випуску. Цей файл може бути у форматі json або yaml і має наступний формат:

podNodeSelectorPluginConfig:
  clusterDefaultNodeSelector: name-of-node-selector
  namespace1: name-of-node-selector
  namespace2: name-of-node-selector

Зверніться до конфігураційного файлу PodNodeSelector з файлу, наданого прапорцем командного рядка API-сервера --admission-control-config-file:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodNodeSelector
  path: podnodeselector.yaml
...

Формат анотації конфігурації

PodNodeSelector використовує ключ анотації scheduler.alpha.kubernetes.io/node-selector для призначення селекторів вузлів до namespace.

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/node-selector: name-of-node-selector
  name: namespace3

Внутрішня поведінка

Цей контролер допуску має наступну поведінку:

  1. Якщо Namespace має анотацію з ключем scheduler.alpha.kubernetes.io/node-selector, використовуйте її значення як селектор вузлів.
  2. Якщо namespace не має такої анотації, використовуйте clusterDefaultNodeSelector, визначений у конфігураційному файлі втулка PodNodeSelector, як селектор вузлів.
  3. Оцініть селектор вузлів Podʼа щодо селектора вузлів namespace на предмет конфліктів. Конфлікти призводять до відхилення.
  4. Оцініть селектор вузлів Podʼа щодо дозволеного селектора, визначеного у конфігураційному файлі плагіну для конкретного namespace. Конфлікти призводять до відхилення.

PodSecurity

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Тип: Валідаційний.

Контролер допуску PodSecurity перевіряє нові Podʼи перед їх допуском і визначає, чи варто їх допускати на основі запитуваного контексту безпеки та обмежень щодо дозволених Стандартів безпеки для Podʼів для namespace, в якому буде знаходитися Pod.

Дивіться Pod Security Admission для отримання додаткової інформації.

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.

Приклад анотацій для namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: apps-that-need-nodes-exclusively
  annotations:
    scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
    scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'

Цей контролер допуску стандатно вимкнено.

Priority

Тип: Модифікуючий та Валідаційний.

Контролер допуску Priority використовує поле priorityClassName і заповнює ціле значення пріоритету. Якщо клас пріоритету не знайдено, Pod відхиляється.

ResourceQuota

Тип: Валідаційний.

Цей контролер допуску спостерігає за вхідним запитом і гарантує, що він не порушує жодних обмежень, перерахованих у обʼєкті ResourceQuota у Namespace. Якщо ви використовуєте обʼєкти ResourceQuota у вашому розгортанні Kubernetes, ви МАЄТЕ використовувати цей контролер допуску для забезпечення дотримання квот.

Дивіться довідник ResourceQuota API та приклад Resource Quota для отримання додаткових деталей.

RuntimeClass

Тип: Модифікуючий та Валідаційний.

Якщо ви визначаєте RuntimeClass з налаштованими накладними витратами, повʼязаними з роботою Podʼів, цей контролер допуску перевіряє вхідні Podʼи. При увімкненні, цей контролер допуску відхиляє будь-які запити на створення Podʼів, які вже мають встановлений overhead. Для Podʼів, які мають налаштований і обраний у своєму .spec RuntimeClass, цей контролер допуску встановлює .spec.overhead у Pod на основі значення, визначеного у відповідному RuntimeClass.

Дивіться також Накладні витрати, повʼязані з роботою Podʼів для отримання додаткової інформації.

ServiceAccount

Тип: Модифікуючий та Валідаційний.

Цей контролер допуску реалізує автоматизацію для службових облікових записів. Проєкт 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 або MutatingWebhookConfiguration.

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

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "pod-policy.example.com"
webhooks:
- name: "pod-policy.example.com"
  rules:
  - apiGroups:   [""]
    apiVersions: ["v1"]
    operations:  ["CREATE"]
    resources:   ["pods"]
    scope:       "Namespaced"
  clientConfig:
    service:
      namespace: "example-namespace"
      name: "example-service"
    caBundle: <CA_BUNDLE>
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 5

Поле scope вказує, чи тільки ресурси з області кластера ("Cluster") або з області простору імен ("Namespaced") будуть відповідати цьому правилу. "∗" означає, що обмежень області немає.

Коли сервер API отримує запит, що відповідає одному з rules, сервер API надсилає запит admissionReview до вебхуку, як зазначено в clientConfig.

Після створення конфігурації вебхуку, системі знадобиться кілька секунд, щоб визнати нову конфігурацію.

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

Якщо вашим вебхукам для допуску потрібна автентифікація, ви можете налаштувати сервери API для використання базової автентифікації, токенів на предʼявника (bearer token) або сертифікатів для автентифікації себе у вебхуках. Налаштування складається з трьох кроків.

  • Під час запуску сервера API вкажіть розташування файлу конфігурації керування допуском за допомогою прапорця --admission-control-config-file.

  • У файлі конфігурації керування допуском вкажіть, де контролери MutatingAdmissionWebhook та ValidatingAdmissionWebhook повинні читати облікові дані. Облікові дані зберігаються у файлах kubeConfig (так, це та сама схема, що використовується kubectl), тому назва поля — kubeConfigFile. Ось приклад файлу конфігурації керування допуском:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: WebhookAdmissionConfiguration
    kubeConfigFile: "<path-to-kubeconfig-file>"
- name: MutatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: WebhookAdmissionConfiguration
    kubeConfigFile: "<path-to-kubeconfig-file>"


# Застаріло у v1.17 на користь apiserver.config.k8s.io/v1
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
  configuration:
    # Застаріло у v1.17 на користь apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfiguration
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: "<path-to-kubeconfig-file>"
- name: MutatingAdmissionWebhook
  configuration:
    # Застаріло у v1.17 на користь apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfiguration
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: "<path-to-kubeconfig-file>"

Для отримання додаткової інформації про AdmissionConfiguration, дивіться документацію по AdmissionConfiguration (v1). Дивіться розділ конфігурації вебхуку для деталей про кожне поле конфігурації.

У файлі kubeConfig вкажіть облікові дані:

apiVersion: v1
kind: Config
users:
# 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 у своїй конфігурації:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  admissionReviewVersions: ["v1", "v1beta1"]

admissionReviewVersions є обов’язковим полем при створенні конфігурацій вебхуків. Вебхуки повинні підтримувати принаймні одну версію AdmissionReview, яка зрозуміла поточному та попередньому API-серверу.

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

Цей приклад показує дані, що містяться в об’єкті AdmissionReview для запиту на оновлення субресурсу scale для Deployment з групи apps/v1:

apiVersion: admission.k8s.io/v1
kind: AdmissionReview
request:
  # Випадковий uid, що унікально ідентифікує цей виклик підтвердження
  uid: 705ab4f5-6393-11e8-b7cc-42010a800002

  # Повністю кваліфікована група/версія/тип вхідного об’єкта
  kind:
    group: autoscaling
    version: v1
    kind: Scale

  # Повністю кваліфікована група/версія/тип ресурсу, що змінюється
  resource:
    group: apps
    version: v1
    resource: deployments

  # субресурс, якщо запит стосується субресурсу
  subResource: scale

  # Повністю кваліфікована група/версія/тип вхідного об’єкта в початковому запиті до API-сервера.
  # Це відрізняється від `kind`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.
  requestKind:
    group: autoscaling
    version: v1
    kind: Scale

  # Повністю кваліфікована група/версія/тип ресурсу, що змінюється в початковому запиті до API-сервера.
  # Це відрізняється від `resource`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.
  requestResource:
    group: apps
    version: v1
    resource: deployments

  # субресурс, якщо запит стосується субресурсу
  # Це відрізняється від `subResource`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.
  requestSubResource: scale

  # Ім’я ресурсу, що змінюється
  name: my-deployment

  # Простір імен ресурсу, що змінюється, якщо ресурс має простір імен (або є об’єктом Namespace)
  namespace: my-namespace

  # операція може бути CREATE, UPDATE, DELETE або CONNECT
  operation: UPDATE

  userInfo:
    # Ім’я користувача автентифікованого користувача, що робить запит до 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/v1
    kind: Scale

  # oldObject є існуючим об’єктом.
  # Це null для операцій CREATE та CONNECT.
  oldObject:
    apiVersion: autoscaling/v1
    kind: Scale

  # options містить параметри операції, що підлягає допуску, як-от meta.k8s.io/v1 CreateOptions, UpdateOptions або DeleteOptions.
  # Це null для операцій CONNECT.
  options:
    apiVersion: meta.k8s.io/v1
    kind: 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

Приклад мінімальної відповіді від вебхука для дозволу запиту:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": true
  }
}

Приклад мінімальної відповіді від вебхука для заборони запиту:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": 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=

Отже, відповідь вебхука для додавання цієї мітки буде такою:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": true,
    "patchType": "JSONPatch",
    "patch": "W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0="
  }
}

Вебхуки допуску можуть за бажанням повертати попереджувальні повідомлення, які повертаються клієнту, що зробив запит, у HTTP-заголовках Warning з кодом попередження 299. Попередження можуть бути надіслані з дозволеними або відхиленими відповідями на допуск.

Якщо ви реалізуєте вебхук, що повертає попередження:

  • Не включайте префікс "Warning:" у повідомлення
  • Використовуйте попереджувальні повідомлення для опису проблем, які клієнт, що робить API-запит, має виправити або про які має знати
  • За можливості, обмежуйте попередження до 120 символів
{
  "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/v1beta1 deployments і replicasets:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["apps"]
    apiVersions: ["v1", "v1beta1"]
    resources: ["deployments", "replicasets"]
    scope: "Namespaced"
  ...

Відповідність запитам на створення для всіх ресурсів (але не субресурсів) у всіх групах і версіях API:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*"]
        scope: "*"

Відповідність запитам на оновлення для всіх субресурсів status у всіх групах і версіях API:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    rules:
      - operations: ["UPDATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*/status"]
        scope: "*"

Відповідність запитів: objectSelector

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

Обʼєкт, що дорівнює null (oldObject у випадку створення або newObject у випадку видалення), або обʼєкт, який не може мати міток (наприклад, обʼєкт DeploymentRollback або PodProxyOptions), не вважається відповідним.

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

Цей приклад показує модифікуючий вебхук, який відповідатиме CREATE для будь-якого ресурсу (але не субресурсів) з міткою foo: bar:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  objectSelector:
    matchLabels:
      foo: bar
  rules:
  - operations: ["CREATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["*"]
    scope: "*"

Див. концепцію міток для більшої кількості прикладів селекторів міток.

Відповідність запитів: namespaceSelector

Вебхуки можуть за бажанням обмежувати, які запити на ресурси в межах простору імен перехоплюються, на основі міток простору імен, до якого вони належать, вказуючи namespaceSelector.

namespaceSelector вирішує, чи слід запускати вебхук для запиту на ресурс у межах простору імен (або обʼєкт Namespace), на основі того, чи відповідають мітки простору імен селектору. Якщо обʼєкт сам є простором імен, відповідність виконується за object.metadata.labels. Якщо обʼєкт є кластерним ресурсом, відмінним від Namespace, namespaceSelector не впливає.

Цей приклад показує модифікуючий вебхук, який відповідає CREATE для будь-якого ресурсу в межах простору імен, який не має мітки "runlevel" зі значенням "0" або "1":

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    namespaceSelector:
      matchExpressions:
        - key: runlevel
          operator: NotIn
          values: ["0","1"]
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*"]
        scope: "Namespaced"

Цей приклад показує валідаційний вебхук, який відповідає CREATE для будь-якого ресурсу в межах простору імен, асоційованого з "environment" зі значенням "prod" або "staging":

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    namespaceSelector:
      matchExpressions:
        - key: environment
          operator: In
          values: ["prod","staging"]
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*"]
        scope: "Namespaced"

Див. концепцію міток для більшої кількості прикладів селекторів міток.

Відповідність запитів: 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:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  matchPolicy: Equivalent
  rules:
  - operations: ["CREATE","UPDATE","DELETE"]
    apiGroups: ["apps"]
    apiVersions: ["v1"]
    resources: ["deployments"]
    scope: "Namespaced"

matchPolicy для вебхуків допуску за замовчуванням дорівнює Equivalent.

Відповідність запитів: matchConditions

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [stable] (стандартно увімкнено: true)

Ви можете визначити умови відповідності для вебхуків, якщо вам потрібна точніша фільтрація запитів. Ці умови корисні, якщо правила відповідності, objectSelectors та namespaceSelectors не надають необхідної фільтрації при викликах по HTTP. Умови відповідності є CEL виразами. Всі умови відповідності повинні оцінюватися як true для виклику вебхука.

Ось приклад, що ілюструє декілька різних способів використання умов відповідності:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    matchPolicy: Equivalent
    rules:
      - operations: ['CREATE','UPDATE']
        apiGroups: ['*']
        apiVersions: ['*']
        resources: ['*']
    failurePolicy: 'Ignore' # Fail-open (опційно)
    sideEffects: None
    clientConfig:
      service:
        namespace: my-namespace
        name: my-webhook
      caBundle: '<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.com
    matchPolicy: Equivalent
    rules:
      - operations: ['CREATE','UPDATE']
        apiGroups: ['rbac.authorization.k8s.io']
        apiVersions: ['*']
        resources: ['*']
    failurePolicy: 'Fail' # Fail-closed (стандартно)
    sideEffects: None
    clientConfig:
      service:
        namespace: my-namespace
        name: my-webhook
      caBundle: '<omitted>'
    # Ви можете мати до 64 умов відповідності на вебхук
    matchConditions:
      - name: 'breakglass'
        # Пропуск запитів, зроблених користувачами, авторизованими для 'breakglass' на цьому вебхуку.
        # Дієслово API 'breakglass' не повинно існувати за межами цієї перевірки.
        expression: '!authorizer.group("admissionregistration.k8s.io").resource("validatingwebhookconfigurations").name("my-webhook.example.com").check("breakglass").allowed()'

Умови відповідності мають доступ до наступних CEL змінних:

  • object — Обʼєкт з вхідного запиту. Значення є null для DELETE запитів. Версія обʼєкта може бути конвертована на основі matchPolicy.
  • oldObject — Наявний обʼєкт. Значення є null для CREATE запитів.
  • request — Частина запиту AdmissionReview, виключаючи object та oldObject.
  • authorizer — CEL Authorizer. Може використовуватись для виконання перевірок авторизації для головного облікового запису (автентифікованого користувача) запиту. Дивіться Authz у документації бібліотеки Kubernetes CEL для додаткової інформації.
  • authorizer.requestResource — Скорочення для перевірки авторизації, налаштованої на ресурс запиту (група, ресурс, (субресурс), простір імен, імʼя).

Для отримання додаткової інформації про CEL вирази, зверніться до довідника Загальна мова виразів у Kubernetes.

У разі помилки оцінки умови відповідності вебхук ніколи не викликається. Чи відхилити запит визначається наступним чином:

  1. Якщо будь-яка умова відповідності оцінилася як false (незалежно від інших помилок), API сервер пропускає вебхук.
  2. Інакше:
    • для failurePolicy: Fail, запит відхиляється (без виклику вебхука).
    • для failurePolicy: Ignore, продовжити запит, але пропустити вебхук.

Звернення до вебхука

Коли сервер 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):

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  clientConfig:
    url: "https://my-webhook.example.com:9443/my-webhook-path"

Посилання на сервіс

Розділ service всередині clientConfig є посиланням на сервіс для цього вебхука. Якщо вебхук працює всередині кластера, вам слід використовувати service замість url. Необхідно вказати простір імен та імʼя сервісу. Порт є необовʼязковим і стандартно дорівнює 443. Шлях є необовʼязковим і стандартно дорівнює "/".

Ось приклад конфігурації модифікуючого вебхука для виклику сервісу на порту "1234" за підшляхом "/my-path", і для перевірки TLS-зʼєднання проти ServerName my-service-name.my-service-namespace.svc з використанням власного набору CA:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  clientConfig:
    caBundle: <CA_BUNDLE>
    service:
      namespace: my-service-namespace
      name: my-service-name
      path: /my-path
      port: 1234

Побічні ефекти

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

Вебхуки, які здійснюють зміни поза межами ("побічні ефекти"), повинні також мати механізм узгодження (наприклад, контролер), який періодично визначає фактичний стан системи та коригує дані поза межами, змінені вебхуком допуску, щоб відобразити реальність. Це тому, що виклик до вебхука допуску не гарантує, що прийнятий обʼєкт буде збережений таким, яким він є, або взагалі. Пізніші вебхуки можуть змінити вміст обʼєкта, може виникнути конфлікт під час запису в сховище, або сервер може вимкнутися до збереження обʼєкта.

Крім того, вебхуки з побічними ефектами повинні пропускати ці побічні ефекти, коли обробляються запити допуску з dryRun: true. Вебхук повинен явно вказати, що він не матиме побічних ефектів при запуску з dryRun, інакше запит dry-run не буде надіслано до вебхука, і API-запит замість цього не вдасться.

Вебхуки вказують, чи мають вони побічні ефекти, за допомогою поля sideEffects у конфігурації вебхука:

  • None: виклик вебхука не матиме побічних ефектів.
  • NoneOnDryRun: виклик вебхука може мати побічні ефекти, але якщо до вебхука надіслано запит з dryRun: true, вебхук придушить побічні ефекти (вебхук враховує dryRun).

Ось приклад конфігурації вебхука перевірки, який вказує, що він не має побічних ефектів при запитах з dryRun: true:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    sideEffects: NoneOnDryRun

Тайм-аути

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

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

Значення тайм-ауту повинно бути між 1 і 30 секунд.

Ось приклад конфігурації вебхука перевірки з кастомним тайм-аутом у 2 секунди:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    timeoutSeconds: 2

Тайм-аут для вебхука допуску стандартно становить 10 секунд.

Політика повторного виклику

Одне впорядкування втулків модифікуючого допуску (включаючи вебхуки) не підходить для всіх випадків (див. приклад у https://issue.k8s.io/64333). Модифікуючий вебхук може додати нову підструктуру до обʼєкта (наприклад, додати container до pod), а інші модифікуючи втулки, які вже виконані, можуть мати вплив на ці нові структури (наприклад, встановити imagePullPolicy для всіх контейнерів).

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

reinvocationPolicy може бути встановлено на Never або IfNeeded. Стандартно встановлено у Never.

  • Never: вебхук не повинен викликатися більше одного разу в рамках однієї оцінки допуску.
  • IfNeeded: вебхук може бути викликаний знову в рамках оцінки допуску, якщо обʼєкт, що авторизується, змінюється іншими втулками допуску після початкового виклику вебхука.

Важливі моменти, на які слід звернути увагу:

  • Кількість додаткових викликів не гарантується як точно одна.
  • Якщо додаткові виклики призводять до подальших змін обʼєкта, не гарантується, що вебхуки будуть викликані знов.
  • Вебхуки, які використовують цей параметр, можуть бути переупорядковані для мінімізації кількості додаткових викликів.
  • Щоб перевірити обʼєкт після того, як всі модифікації гарантовано завершені, використовуйте вебхук допуску (рекомендується для вебхуків з побічними ефектами).

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

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  reinvocationPolicy: IfNeeded

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

Політика обробки помилок

failurePolicy визначає, як обробляються невизнані помилки та помилки тайм-ауту від вебхука допуску. Допустимі значення: Ignore або Fail.

  • Ignore означає, що помилка при виклику вебхука ігнорується, і запит API дозволяється продовжити.
  • Fail означає, що помилка при виклику вебхука призводить до невдачі допуску та відхилення запиту API.

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

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  failurePolicy: Fail

Стандартна політика обробки помилок failurePolicy для вебхуків допуску Fail.

Моніторинг вебхуків авторизації

Сервер API надає способи моніторингу поведінки вебхуків допуску. Ці механізми моніторингу допомагають адміністраторам кластерів відповісти на запитання, як:

  1. Який модифікуючий вебхук змінив обʼєкт у запиті API?

  2. Яку зміну модифікуючий вебхук застосував до обʼєкта?

  3. Які вебхуки часто відхиляють запити 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\"}"
        # інші анотації
        ...
    }
    # інші поля
    ...
}

    # десеріалізоване значення анотації
{
    "configuration": "my-other-mutating-webhook-configuration.example.com",
    "webhook": "my-webhook-always-mutate.example.com",
    "patchType": "JSONPatch",
    "patch": [
        {
            "op": "add",
            "path": "/data/mutation-stage",
            "value": "yes"
        }
    ]
}

Метрики вебхуків допуску

Сервер 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

Найкращі практики та попередження

Ідемпотентність

Ідемпотентний вебхук допуску, що змінює дані, може успішно обробляти обʼєкт, який він вже допустив і, можливо, змінив. Допуск можна застосовувати кілька разів, не змінюючи результат поза початковою обробкою.

Приклади ідемпотентних модифікуючих вебхуків допуску:

  1. Для запиту CREATE Pod задайте поле .spec.securityContext.runAsNonRoot в значення true, щоб застосувати найкращі практики безпеки.

  2. Для запиту запиту CREATE Pod стандартно встановлюються обмеження ресурсів, якщо поле .spec.containers[].resources.limits контейнера не встановлено.

  3. Для запиту запиту CREATE Pod додається додатковий контейнер з імʼям foo-sidecar, якщо контейнер із імʼям foo-sidecar ще не існує.

У випадках, наведених вище, вебхук може безпечно повторно викликатися або допускати обʼєкт, у якого вже встановлені ці поля.

Приклади неідемпотентних модифікуючих вебхуків допуску:

  1. Для запиту CREATE Pod додається sidecar контейнер з імʼям foo-sidecar, суфіксований поточним часовим позначенням (наприклад, foo-sidecar-19700101-000000).

  2. Для CREATE/UPDATE Pod відхиляються запити, якщо позначка "env" установлена, в іншому випадку додається позначка "env": "prod".

  3. Для запиту 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, автентифікатор службового облікового запису витягне і перевірить ці заявки. Якщо вказаний обʼєкт або ServiceAccount знаходяться в процесі видалення (наприклад, через завершувач), то протягом будь-якого моменту, через 60 секунд (або більше) після дати .metadata.deletionTimestamp, автентифікація з використанням цього токена буде неуспішною. Якщо обʼєкт, на який він посилається, більше не існує (або його metadata.uid не збігається), запит не буде автентифікований.

Додаткові метадані в токенах, повʼязаних з Pod

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta] (стандартно увімкнено: true)

Коли токен службового облікового запису привʼязаний до обʼєкта Pod, додаткові метадані також вбудовуються в токен, що вказує на значення поля spec.nodeName повʼязаного Pod і uid цього вузла, якщо це можливо.

Ця інформація про вузол не перевіряється kube-apiserver, коли токен використовується для автентифікації. Вона включена, щоб інтегратори не повинні були отримувати обʼєкти API Pod або Node для перевірки повʼязаного імені вузла та uid при інспекції JWT.

Перевірка та інспекція приватних заявок

API TokenReview може використовуватися для перевірки та вилучення приватних заявок з токена:

  1. Спочатку припустимо, що у вас є Pod з назвою test-pod і службовий обліковий запис з назвою my-sa.

  2. Створіть токен, привʼязаний до цього Pod:

    kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod"

  3. Скопіюйте цей токен у новий файл з назвою tokenreview.yaml:

    apiVersion: authentication.k8s.io/v1
kind: TokenReview
spec:
  token: <токен з кроку 2>

  4. Надішліть цей ресурс до apiserver для перевірки:

    kubectl create -o yaml -f tokenreview.yaml # ми використовуємо '-o yaml', щоб можна було перевірити вихідні дані

Ви повинні побачити вихідні дані, подібні до наведених нижче:

apiVersion: authentication.k8s.io/v1
kind: TokenReview
metadata:
  creationTimestamp: null
spec:
  token: <token>
status:
  audiences:
  - https://kubernetes.default.svc.cluster.local
  authenticated: true
  user:
    extra:
      authentication.kubernetes.io/credential-id:
      - JTI=7ee52be0-9045-4653-aa5e-0da57b8dccdc
      authentication.kubernetes.io/node-name:
      - kind-control-plane
      authentication.kubernetes.io/node-uid:
      - 497e9d9a-47aa-4930-b0f6-9f2fb574c8c6
      authentication.kubernetes.io/pod-name:
      - test-pod
      authentication.kubernetes.io/pod-uid:
      - e87dbbd6-3d7e-45db-aafb-72b24627dff5
    groups:
    - system:serviceaccounts
    - system:serviceaccounts:default
    - system:authenticated
    uid: f8b4161b-2e2b-11e9-86b7-2afc33b31a7e
    username: system:serviceaccount:default:my-sa

Механізм томів привʼязаного токена службового облікового запису

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable] (стандартно увімкнено: true)

Стандартно, панель управління Kubernetes (зокрема, ServiceAccount admission controller) додає projected том до Pod, і цей том містить токен для доступу до API Kubernetes.

Ось приклад, як це виглядає для запущеного Pod:

...
  - name: kube-api-access-<random-suffix>
    projected:
      sources:
        - serviceAccountToken:
            path: token # має збігатися з шляхом, який очікує застосунок
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

Цей фрагмент маніфесту визначає projected том, що складається з трьох джерел. У цьому випадку, кожне джерело також представляє один шлях у цьому томі. Три джерела такі:

  1. Джерело serviceAccountToken, яке містить токен, який kubelet отримує з kube-apiserver. Kubelet отримує токени з обмеженим терміном дії за допомогою API TokenRequest. Токен, наданий для TokenRequest, закінчується або при видаленні Pod, або після визначеного терміну дії (стандартно, це 1 година). Kubelet також оновлює цей токен перед тим, як термін його дії закінчиться. Токен привʼязаний до конкретного Pod і має kube-apiserver як свою аудиторію. Цей механізм замінив попередній механізм, який додавав том на основі Secret, де Secret представляв ServiceAccount для Pod, але не мав терміну дії.
  2. Джерело configMap. ConfigMap містить набір даних центру сертифікації. Pod можуть використовувати ці сертифікати, щоб упевнитись, що вони підключаються до kube-apiserver вашого кластера (а не до проміжного блоку або випадково неправильно налаштованого колеги).
  3. Джерело downwardAPI, яке шукає імʼя простору імен, що містить Pod, і надає цю інформацію про імʼя для коду застосунку, що виконується всередині Pod.

Будь-який контейнер у Pod, який монтує цей том, може отримати доступ до вищевказаної інформації.

Ручне управління Secret для ServiceAccounts

Версії Kubernetes до v1.22 автоматично створювали облікові дані для доступу до API Kubernetes. Цей старіший механізм був заснований на створенні токенів Secret, які потім могли бути змонтовані в запущені Podʼи.

У новіших версіях, включаючи Kubernetes v1.31, API облікові дані отримуються безпосередньо за допомогою TokenRequest, і монтуються в Podʼи за допомогою projected тому. Токени, отримані за допомогою цього методу, мають обмежений термін дії та автоматично анулюються, коли Pod, в який вони змонтовані, видаляється.

Ви все ще можете створити вручну Secret для збереження токена службового облікового запису; наприклад, якщо вам потрібен токен, який ніколи не закінчується.

Після того, як ви вручну створите Secret і звʼяжете його зі службовим обліковим записом, панель управління Kubernetes автоматично заповнює токен у цьому Secret.

Автоматичне очищення застарілих токенів ServiceAccount

До версії 1.24 Kubernetes автоматично генерував токени на основі Secret для ServiceAccount. Щоб розрізнити автоматично згенеровані токени та створені вручну, Kubernetes перевіряє посилання з поля секретів ServiceAccount. Якщо Secret згадується в полі secrets, він вважається автоматично згенерованим застарілим токеном. В іншому випадку він вважається вручну створеним застарілим токеном. Наприклад:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
  namespace: default
secrets:
  - name: build-robot-secret # зазвичай НЕ присутній для вручну створеного токена

Починаючи з версії 1.29, застарілі токени службових облікових записів, які були згенеровані автоматично, будуть позначені як недійсні, якщо вони залишатимуться невикористаними протягом певного періоду часу (стандартно один рік). Токени, які продовжують залишатися невикористаними протягом цього визначеного періоду (знову ж таки, стандартно один рік), будуть згодом видалені панеллю управління.

Якщо користувачі використовують анульований автоматично згенерований токен, валідатор токенів:

  1. додасть анотацію аудиту для пари ключ-значення authentication.k8s.io/legacy-token-invalidated: <secret name>/<namespace>,
  2. збільшить лічильник метрики invalid_legacy_auto_token_uses_total,
  3. оновить мітку Secret kubernetes.io/legacy-token-last-used з новою датою,
  4. поверне помилку, вказуючи, що токен був анульований.

При отриманні цієї помилки валідації користувачі можуть оновити Secret, щоб видалити мітку kubernetes.io/legacy-token-invalid-since, щоб тимчасово дозволити використання цього токена.

Ось приклад автоматично згенерованого застарілого токена, який був позначений мітками kubernetes.io/legacy-token-last-used і kubernetes.io/legacy-token-invalid-since:

apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  namespace: default
  labels:
    kubernetes.io/legacy-token-last-used: 2022-10-24
    kubernetes.io/legacy-token-invalid-since: 2023-10-25
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token

Деталі панелі управління

Контролер ServiceAccount

Контролер 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 він виконує наступні дії:

  1. Якщо у Pod не встановлено значення .spec.serviceAccountName, контролер допуску встановлює імʼя ServiceAccount default для цього Pod.
  2. Контролер допуску забезпечує наявність ServiceAccount, на який посилається Pod. Якщо не існує ServiceAccount з відповідним імʼям, контролер допуску відхиляє Pod. Ця перевірка застосовується навіть для default ServiceAccount.
  3. Якщо поле automountServiceAccountToken у ServiceAccount або в Podʼі не встановлено в false:
    • контролер допуску змінює Pod, додаючи додатковий том, що містить токен для доступу до API.
    • контролер допуску додає volumeMount до кожного контейнера в Podʼі, пропускаючи контейнери, які вже мають визначений шлях для монтування тому /var/run/secrets/kubernetes.io/serviceaccount. Для Linux-контейнерів цей том монтується за адресою /var/run/secrets/kubernetes.io/serviceaccount; на Windows-вузлах монтування знаходиться ну еквівалентному шляху.
  4. Якщо в специфікації Pod не містяться жодні imagePullSecrets, контролер допуску додає imagePullSecrets, копіюючи їх з ServiceAccount.

Контролер відстеження токенів застарілих ServiceAccount

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable] (стандартно увімкнено: true)

Цей контролер створює ConfigMap з назвою kube-system/kube-apiserver-legacy-service-account-token-tracking у просторі імен kube-system. ConfigMap фіксує мітку часу, коли система почала відстежувати застарілі токени службових облікових записів.

Очищувач токенів застарілих ServiceAccount

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [stable] (стандартно увімкнено: true)

Очищувач токенів застарілих 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 не використовується протягом визначеного часу, очищувач видаляє його.

API TokenRequest

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable]

Ви використовуєте субресур TokenRequest з ServiceAccount, щоб отримати токен з обмеженим часом дії для цього ServiceAccount. Вам не потрібно викликати його для отримання API-токена для використання в контейнері, оскільки kubelet налаштовує це для вас, використовуючи projected том.

Якщо ви хочете використовувати API TokenRequest через kubectl, див. Ручне створення API-токена для ServiceAccount.

Панель управління Kubernetes (зокрема, контролер допуску ServiceAccount) додає projected том до Podʼів, а kubelet забезпечує, що цей том містить токен, який дозволяє контейнерам автентифікуватися як відповідний ServiceAccount.

(Цей механізм замінив попередній механізм, який додавав том на основі Secret, де Secret представляв ServiceAccount для Pod, але не мав терміну дії.)

Ось приклад того, як це виглядає для запущеного Pod:

...
  - name: kube-api-access-<random-suffix>
    projected:
      defaultMode: 420 # десятичний еквівалент вісімкового 0644
      sources:
        - serviceAccountToken:
            expirationSeconds: 3607
            path: token
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

Цей фрагмент маніфесту визначає projected том, який обʼєднує інформацію з трьох джерел:

  1. Джерело serviceAccountToken, що містить токен, який kubelet отримує від kube-apiserver. Kubelet отримує токени з обмеженим часом дії, використовуючи API TokenRequest. Токен, виданий для TokenRequest, спливає або коли Pod видаляється, або через визначений термін життя (стандартно — 1 година). Токен привʼязаний до конкретного Podʼа та має kube-apiserver як свою аудиторію.
  2. Джерело configMap. ConfigMap містить пакет даних сертифікаційного центру. Podʼи можуть використовувати ці сертифікати, щоб переконатися, що вони підключаються до kube-apiserver вашого кластера (а не до проміжного блоку або випадково неправильно налаштованого колеги).
  3. Джерело downwardAPI. Цей том downwardAPI робить імʼя простору імен, що містить Pod, доступним для коду програми, що працює всередині Podʼа.

Будь-який контейнер у Podʼі, що монтує цей том, може отримати доступ до вищезазначеної інформації.

Створення додаткових API токенів

Для створення постійного API токена для ServiceAccount, створіть Secret типу kubernetes.io/service-account-token з анотацією, що посилається на ServiceAccount. Панель управління потім генерує довгостроковий токен і оновлює цей Secret з даними згенерованого токена.

Ось приклад маніфесту для такого Secret:

secret/serviceaccount/mysecretname.yaml 
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: mysecretname
  annotations:
    kubernetes.io/service-account.name: myserviceaccount

Для створення Secret на основі цього прикладу, виконайте:

kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml

Для перегляду деталей цього Secret, виконайте:

kubectl -n examplens describe secret mysecretname

Результат буде подібним до:

Name:           mysecretname
Namespace:      examplens
Labels:         <none>
Annotations:    kubernetes.io/service-account.name=myserviceaccount
                kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1362 bytes
namespace:      9 bytes
token:          ...

Якщо ви запустите новий Pod у просторі імен examplens, він може використовувати Secret токену службового облікового запису myserviceaccount, який ви щойно створили.

Видалення/деактивація токена ServiceAccount

Якщо ви знаєте назву Secret, що містить токен, який ви хочете видалити:

kubectl delete secret name-of-secret

Інакше спочатку знайдіть Secret для ServiceAccount.

# Це передбачає, що у вас вже є простір імен 'examplens'
kubectl -n examplens get serviceaccount/example-automated-thing -o yaml

Результат буде подібним до:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}}      
  creationTimestamp: "2019-07-21T07:07:07Z"
  name: example-automated-thing
  namespace: examplens
  resourceVersion: "777"
  selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing
  uid: f23fd170-66f2-4697-b049-e1e266b7f835
secrets:
  - name: example-automated-thing-token-zyxwv

Потім видаліть Secret, назву якого ви тепер знаєте:

kubectl -n examplens delete secret/example-automated-thing-token-zyxwv

Прибирання

Якщо ви створили простір імен examplens для експериментів, ви можете його видалити:

kubectl delete namespace examplens

Що далі

3.11 - Сертифікати та запити на їх підписування

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 годин
  • Усі запити: автоматично видаляються після того, як видача сертифіката закінчиться після спливання часу дії

Авторизація підпису сертифікатів

Для можливості створення запиту на підпис сертифіката та отримання будь-якого запиту на підпис сертифіката:

  • Дієслова: create, get, list, watch, група: certificates.k8s.io, ресурс: certificatesigningrequests

Наприклад:

access/certificate-signing-request/clusterrole-create.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-creator
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - create
  - get
  - list
  - watch

Для можливості схвалення запиту на підпис сертифіката:

  • Дієслова: get, list, watch, група: certificates.k8s.io, ресурс: certificatesigningrequests
  • Дієслова: update, група: certificates.k8s.io, ресурс: certificatesigningrequests/approval
  • Дієслова: approve, група: certificates.k8s.io, ресурс: signers, resourceName: <signerNameDomain>/<signerNamePath> або <signerNameDomain>/*

Наприклад:

access/certificate-signing-request/clusterrole-approve.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-approver
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/approval
  verbs:
  - update
- apiGroups:
  - certificates.k8s.io
  resources:
  - signers
  resourceNames:
  - example.com/my-signer-name # example.com/* може використовуватись для авторизації всіх підписувачів в домені 'example.com'
  verbs:
  - approve

Для можливості підписання запиту на підпис сертифіката:

  • Дієслова: get, list, watch, група: certificates.k8s.io, ресурс: certificatesigningrequests
  • Дієслова: update, група: certificates.k8s.io, ресурс: certificatesigningrequests/status
  • Дієслова: sign, група: certificates.k8s.io, ресурс: signers, resourceName: <signerNameDomain>/<signerNamePath> або <signerNameDomain>/*
access/certificate-signing-request/clusterrole-sign.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-signer
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/status
  verbs:
  - update
- apiGroups:
  - certificates.k8s.io
  resources:
  - signers
  resourceNames:
  - example.com/my-signer-name # example.com/* може використовуватись для авторизації всіх підписувачів в домені 'example.com'
  verbs:
  - sign

Підписувачі

Підписувачі абстрактно представляють сутність або сутності, які можуть підписувати або вже підписали сертифікат.

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

  1. Розподіл довіри: як розподіляються якорі довіри (CA-сертифікати або набори сертифікатів).
  2. Дозволені субʼєкти: будь-які обмеження та поведінка, коли запитано недопустимий субʼєкт.
  3. Дозволені розширення x509: включаючи IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames тощо, та поведінка, коли запитано недопустиме розширення.
  4. Дозволені використання ключів / розширені використання ключів: будь-які обмеження та поведінка, коли використання, відмінне від використання, визначеного підписувачем, вказане в CSR.
  5. Термін дії / термін життя сертифіката: чи він фіксується підписувачем, настроюваний адміністратором, визначений полем spec.expirationSeconds CSR тощо, та поведінка, коли термін дії, визначений підписувачем, відрізняється від поля spec.expirationSeconds CSR.
  6. Дозволені / заборонені прапорці 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.

Підписувачі Kubernetes

Kubernetes надає вбудовані підписувачі для підпису сертифікатів, кожен з яких має широко відоме імʼя підписувача signerName:

  1. kubernetes.io/kube-apiserver-client: підписує сертифікати, які мають вважатись сертифікатами клієнтів сервером API. Ніколи автоматично не затверджуються kube-controller-manager.

    1. Розподіл довіри: підписані сертифікати мають вважатись клієнтськими сертифікатами для доступу до API-сервера. Набір ЦС не поширюється жодним іншим способом.
    2. Дозволені субʼєкти: немає обмежень для субʼєктів, однак затверджувачі та підписувачі можуть відхилити запити на затвердження та підпис. Певні субʼєкти подібні до користувачів та груп на рівні кластера є різними поміж різними дистрибутивами, що вимагає додаткових перевірок перед затвердженням та підписуванням. Втулок допуску CertificateSubjectRestrictions є стандартно увімкненим для обмеження system:masters, але в кластері є не тільки субʼєкти рівня адміністраторів кластера.
    3. Дозволені розширення x509: враховують subjectAltNames та використання ключів, відкидаючи інші розширення.
    4. Використання дозволених ключів: мають включати ["client auth"]. Не мають містити використання ключів поза ["digital signature", "key encipherment", "client auth"].
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.

  2. kubernetes.io/kube-apiserver-client-kubelet: підписує сертифікати, які мають вважатись сертифікатами клієнтів сервером API. Можуть бути автоматично затверджені kube-controller-manager.

    1. Розподіл довіри: підписані сертифікати мають вважатись клієнтськими сертифікатами для доступу до API-сервера. Набір ЦС не поширюється жодним іншим способом.
    2. Дозволені субʼєкти: організації є безумовно ["system:nodes"], загальні імена — "system:node:${NODE_NAME}".
    3. Дозволені розширення x509: враховують розширення з використанням ключів, забороняють розширення subjectAltNames та відкидає інші розширення.
    4. Дозволені використання ключів: ["key encipherment", "digital signature", "client auth"] або ["digital signature", "client auth"].
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.

  3. kubernetes.io/kubelet-serving: підписує сертифікати, які мають вважатись сертифікатами, які обслуговуються kubelet, але не мають жодних гарантій. Ніколи автоматично не затверджуються kube-controller-manager.

    1. Розподіл довіри: підписані сертифікати мають вважатись API сервером дійсними для обробки зʼєднань з kubelet. Набір ЦС не поширюється жодним іншим способом.
    2. Дозволені субʼєкти: організації є безумовно ["system:nodes"], загальні імена  — "system:node:${NODE_NAME}".
    3. Дозволені розширення x509: враховують використання ключів та розширень DNSName/IPAddress subjectAltName extensions, забороняють розширення EmailAddress та URI subjectAltName, відкидають інші розширення. Принаймні один субʼєкт DNS чи IP повинен бути у subjectAltNames.
    4. Дозволені використання ключів: ["key encipherment", "digital signature", "server auth"] або ["digital signature", "server auth"].
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.

  4. kubernetes.io/legacy-unknown: не має гарантій довіри взагалі. Деякі сторонні дистрибутиви Kubernetes можуть використовувати сертифікати клієнтів, підписані ним. Стабільний API CertificateSigningRequest (версії certificates.k8s.io/v1 та пізніше) не дозволяють встановлювати signerName на kubernetes.io/legacy-unknown. Ніколи автоматично не затверджується kube-controller-manager.

    1. Розподіл довіри: Немає. Для цього підписувача не існує стандартної довіри або розподілу в кластері Kubernetes.
    2. Дозволені субʼєкти: будь-які
    3. Дозволені розширення x509: враховуються subjectAltNames та використання ключів, відкидаються інші розширення.
    4. Дозволені використання ключів: будь-які
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.

kube-controller-manager реалізує підписування панелю управління для кожного з вбудованих підписувачів. Збої для всіх цих операцій повідомляються лише в логах kube-controller-manager.

Розподіл довіри відбувається поза рамками для цих підписувачів. Будь-яка довіра за межами описаного вище є строго випадковою. Наприклад, деякі дистрибутиви можуть приймати 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.

Підписувачі на основі API

Користувачі REST API можуть підписувати CSRs, надсилаючи запит UPDATE до субресурсу status CSR, який потрібно підписати.

У рамках цього запиту поле status.certificate повинно бути встановлено, щоб містити підписаний сертифікат. Це поле містить один або більше сертифікатів, закодованих у форматі PEM.

Всі PEM блоки повинні мати мітку "CERTIFICATE", не містити заголовків, а закодовані дані повинні бути структурою сертифіката BER, закодованого в ASN.1, як описано в розділі 4 RFC5280.

Приклад вмісту сертифіката:

-----BEGIN CERTIFICATE-----
MIIDgjCCAmqgAwIBAgIUC1N1EJ4Qnsd322BhDPRwmg3b/oAwDQYJKoZIhvcNAQEL
BQAwXDELMAkGA1UEBhMCeHgxCjAIBgNVBAgMAXgxCjAIBgNVBAcMAXgxCjAIBgNV
BAoMAXgxCjAIBgNVBAsMAXgxCzAJBgNVBAMMAmNhMRAwDgYJKoZIhvcNAQkBFgF4
MB4XDTIwMDcwNjIyMDcwMFoXDTI1MDcwNTIyMDcwMFowNzEVMBMGA1UEChMMc3lz
dGVtOm5vZGVzMR4wHAYDVQQDExVzeXN0ZW06bm9kZToxMjcuMC4wLjEwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDne5X2eQ1JcLZkKvhzCR4Hxl9+ZmU3
+e1zfOywLdoQxrPi+o4hVsUH3q0y52BMa7u1yehHDRSaq9u62cmi5ekgXhXHzGmm
kmW5n0itRECv3SFsSm2DSghRKf0mm6iTYHWDHzUXKdm9lPPWoSOxoR5oqOsm3JEh
Q7Et13wrvTJqBMJo1GTwQuF+HYOku0NF/DLqbZIcpI08yQKyrBgYz2uO51/oNp8a
sTCsV4OUfyHhx2BBLUo4g4SptHFySTBwlpRWBnSjZPOhmN74JcpTLB4J5f4iEeA7
2QytZfADckG4wVkhH3C2EJUmRtFIBVirwDn39GXkSGlnvnMgF3uLZ6zNAgMBAAGj
YTBfMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMB
Af8EAjAAMB0GA1UdDgQWBBTREl2hW54lkQBDeVCcd2f2VSlB1DALBgNVHREEBDAC
ggAwDQYJKoZIhvcNAQELBQADggEBABpZjuIKTq8pCaX8dMEGPWtAykgLsTcD2jYr
L0/TCrqmuaaliUa42jQTt2OVsVP/L8ofFunj/KjpQU0bvKJPLMRKtmxbhXuQCQi1
qCRkp8o93mHvEz3mTUN+D1cfQ2fpsBENLnpS0F4G/JyY2Vrh19/X8+mImMEK5eOy
o0BMby7byUj98WmcUvNCiXbC6F45QTmkwEhMqWns0JZQY+/XeDhEcg+lJvz9Eyo2
aGgPsye1o3DpyXnyfJWAWMhOz7cikS5X2adesbgI86PhEHBXPIJ1v13ZdfCExmdd
M1fLPhLyR54fGaY+7/X8P9AZzPefAkwizeXwe9ii6/a08vWoiE4=
-----END CERTIFICATE-----

Не-PEM вміст може зʼявлятися до або після блоків CERTIFICATE PEM і не перевіряється, щоб дозволити пояснювальний текст, як описано в розділі 5.2 RFC7468.

При кодуванні в JSON або YAML це поле закодоване в base-64. Запит на підпис сертифіката (CertificateSigningRequest), що містить приклад сертифіката вище, виглядатиме так:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."

Схвалення або відхилення

Перед тим, як підписувач видасть сертифікат на основі запиту на підписання сертифіката (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.

Щоб схвалити CSR за допомогою kubectl:

kubectl certificate approve <certificate-signing-request-name>

Аналогічно, щоб відхилити CSR:

kubectl certificate deny <certificate-signing-request-name>

Схвалення або відхилення за допомогою API Kubernetes

Користувачі REST API можуть схвалювати CSRs, надсилаючи запит UPDATE до субресурсу approval CSR, який потрібно схвалити. Наприклад, ви можете написати оператор, який слідкує за певним видом CSR, а потім надсилає UPDATE для їх схвалення.

Коли ви робите запит на схвалення або відхилення, встановіть або умову статусу Approved, або Denied залежно від визначеного стану:

Для схвалених CSR:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  conditions:
  - lastUpdateTime: "2020-02-08T11:37:35Z"
    lastTransitionTime: "2020-02-08T11:37:35Z"
    message: Approved by my custom approver controller
    reason: ApprovedByMyPolicy # Ви можете вказати тут будь-який рядок
    type: Approved

Для відхилених CSR:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  conditions:
  - lastUpdateTime: "2020-02-08T11:37:35Z"
    lastTransitionTime: "2020-02-08T11:37:35Z"
    message: Denied by my custom approver controller
    reason: DeniedByMyPolicy # Ви можете вказати тут будь-який рядок
    type: Denied

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

Пакети довіри кластера

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [alpha]

ClusterTrustBundles — це обʼєкт масштабу кластера для розподілу якорів довіри X.509 (кореневих сертифікатів) до робочих навантажень у кластері. Вони розроблені для гарної роботи з концепцією підписувача із запитів на підписання сертифікатів (CertificateSigningRequests).

ClusterTrustBundles можна використовувати у двох режимах: звʼязаний з підписувачем та незвʼязаний з підписувачем.

Загальні властивості та валідація

Усі обʼєкти 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/v1alpha1
kind: ClusterTrustBundle
metadata:
  name: example.com:mysigner:foo
spec:
  signerName: example.com/mysigner
  trustBundle: "<... 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/v1alpha1
kind: ClusterTrustBundle
metadata:
  name: foo
spec:
  # 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 по стандартні групи.

openssl genrsa -out myuser.key 2048
openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"

Створення запиту на підписання сертифікату

Створіть запит на підписання сертифікату (CertificateSigningRequest) і подайте його до кластера Kubernetes через kubectl. Нижче наведено скрипт для CertificateSigningRequest.

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # один день
  usages:
  - client auth
EOF

Декілька моментів, на які варто звернути увагу:

  • usages має бути 'client auth'.
  • expirationSeconds можна зробити довшим (наприклад, 864000 для десяти днів) або коротшим (наприклад, 3600 для однієї години).
  • request — це base64-кодоване значення вмісту файлу CSR. Ви можете отримати цей вміст за допомогою такої команди:
cat myuser.csr | base64 | tr -d "\n"

Схвалення CertificateSigningRequest

Використовуйте kubectl, щоб створити CSR та схвалити його.

Отримайте список CSR:

kubectl get csr

Схваліть CSR:

kubectl certificate approve myuser

Отримання сертифіката

Отримайте сертифікат з CSR:

kubectl get csr/myuser -o yaml

Значення сертифіката знаходиться в форматі Base64-кодування в status.certificate.

Експортуйте виданий сертифікат з CertificateSigningRequest.

kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt

Створення Role та RoleBinding

Зі створеним сертифікатом, час визначити Role та RoleBinding для цього користувача для доступу до ресурсів кластера Kubernetes.

Ось приклад команди для створення Role для цього нового користувача:

kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods

Ось приклад команди для створення RoleBinding для цього нового користувача:

kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser

Додавання до kubeconfig

Останній крок — додати цього користувача до файлу kubeconfig.

Спершу, вам потрібно додати нові облікові дані:

kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true

Потім, вам потрібно додати контекст:

kubectl config set-context myuser --cluster=kubernetes --user=myuser

Для перевірки, змініть контекст на myuser:

kubectl config use-context myuser

Що далі

3.12 - Зіставлення PodSecurityPolicies зі стандартами безпеки Podʼів

Нижче наведено таблиці, що перераховують параметри конфігурації обʼєктів PodSecurityPolicy, чи поле змінює або перевіряє контейнери, та як значення конфігурації зіставляються з Стандартами безпеки Podʼів.

Для кожного параметра, до якого це застосовується, перераховані допустимі значення для Baseline та Restricted профілів. Все, що перебуває за межами допустимих значень для цих профілів, підпадає під Privileged профіль. "Немає думки" означає, що всі значення допустимі для всіх стандартів безпеки Podʼів.

Для покрокового керівництва міграції див. Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity.

Специфікація PodSecurityPolicy

Поля, перераховані в цій таблиці, є частиною PodSecurityPolicySpec, яка вказана в шляху поля .spec.

Зіставлення політики безпеки PodSecurityPolicySpec зі стандартами безпеки Podʼів
PodSecurityPolicySpecТипЕквівалент стандартів безпеки Podʼів
privilegedПеревіркаBaseline & Restricted: false / undefined / nil
defaultAddCapabilitiesЗміна & ПеревіркаВимоги відповідають allowedCapabilities нижче.
allowedCapabilitiesПеревірка

Baseline: підмножина

  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • KILL
  • MKNOD
  • NET_BIND_SERVICE
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT

Обмежений: пустий / undefined / nil АБО список, що містить тільки NET_BIND_SERVICE

requiredDropCapabilitiesЗміна & Перевірка

Baseline: немає думки

Baseline: повинен містити ALL

volumesПеревірка

Baseline: будь-що крім

  • hostPath
  • *

Restricted: підмножина

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • ephemeral
  • persistentVolumeClaim
  • projected
  • secret
hostNetworkПеревіркаBaseline & Restricted: false / undefined / nil
hostPortsПеревіркаBaseline & Restricted: undefined / nil / пустий
hostPIDПеревіркаBaseline & Restricted: false / undefined / nil
hostIPCПеревіркаBaseline & Restricted: false / undefined / nil
seLinuxЗміна & Перевірка

Baseline & Restricted: seLinux.rule is MustRunAs, з наступними options

  • user не встановлено ("" / undefined / nil)
  • role не встановлено ("" / undefined / nil)
  • type не встановлено або один із: container_t, container_init_t, container_kvm_t, container_engine_t
  • level є будь-чим
runAsUserЗміна & Перевірка

Baseline: Будь-що

Restricted: rule є MustRunAsNonRoot

runAsGroupЗміна (MustRunAs) & ПеревіркаНемає думки
supplementalGroupsЗміна & ПеревіркаНемає думки
fsGroupЗміна & ПеревіркаНемає думки
readOnlyRootFilesystemЗміна & ПеревіркаНемає думки
defaultAllowPrivilegeEscalationЗмінаНемає думки
allowPrivilegeEscalationЗміна & Перевірка

Лише зміна, якщо встановлено false

Baseline: Немає думки

Restricted: false

allowedHostPathsПеревіркаНемає думки (пріоритет мають volumes)
allowedFlexVolumesПеревіркаНемає думки (пріоритет мають volumes)
allowedCSIDriversПеревіркаНемає думки (пріоритет мають volumes)
allowedUnsafeSysctlsПеревіркаBaseline & Restricted: undefined / nil / empty
forbiddenSysctlsПеревіркаНемає думки
allowedProcMountTypes
(альфа-функція)		ПеревіркаBaseline & Restricted: ["Default"] АБО undefined / nil / empty
runtimeClass
 .defaultRuntimeClassName		ЗмінаНемає думки
runtimeClass
 .allowedRuntimeClassNames		ПеревіркаНемає думки

Анотації PodSecurityPolicy

Анотації, перераховані в цій таблиці, можуть бути вказані у .metadata.annotations обʼєкту PodSecurityPolicy.

Зіставлення анотацій PodSecurityPolicy зі стандартами безпеки Podʼів
Анотація PSPТипЕквівалент стандартів безпеки Podʼів
seccomp.security.alpha.kubernetes.io
/defaultProfileName		ЗмінаНемає думки
seccomp.security.alpha.kubernetes.io
/allowedProfileNames		Перевірка

Baseline: "runtime/default," (Кома в кінці, щоб встановити unset)

Restricted: "runtime/default" (Без коми в кінці)

Значення localhost/* також дозволені як для Baseline, так і для Restricted.

apparmor.security.beta.kubernetes.io
/defaultProfileName		ЗмінаНемає думки
apparmor.security.beta.kubernetes.io
/allowedProfileNames		Перевірка

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
  • див. документацію з автентифікації apiserver для отримання додаткових відомостей

Щоб увімкнути використання 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-діяДієслово запиту
POSTcreate
GET, HEADget
PUTupdate
PATCHpatch
DELETEdelete

Ресурс та субресурс визначаються з шляху вхідного запиту:

Kubelet APIРесурсСубресурс
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
/checkpoint/*nodescheckpoint
всі іншіnodesproxy

Атрибути простору імен та групи 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 виконує наступне:

  1. Шукає свій файл kubeconfig.
  2. Отримує URL-адресу сервера API та облікові дані, зазвичай ключ TLS та підписаний сертифікат з файлу kubeconfig.
  3. Намагається спілкуватися з сервером API, використовуючи облікові дані.

Припускаючи, що kube-apiserver успішно перевіряє облікові дані kubelet, він буде вважати kubelet дійсним вузлом та почне призначати для нього Podʼи.

Зауважте, що вищевказаний процес залежить від:

  • Існування ключа та сертифіката на локальному хості у kubeconfig.
  • Підписання сертифіката центром сертифікації (CA), якому довіряє kube-apiserver.

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

  1. Створення ключа та сертифіката CA.
  2. Розповсюдження сертифіката CA на вузли панелі управління, де запущений kube-apiserver.
  3. Створення ключа та сертифіката для кожного kubelet; наполегливо рекомендується мати унікальний ключ з унікальним CN для кожного kubelet.
  4. Підписання сертифіката kubelet за допомогою ключа CA.
  5. Розповсюдження ключа та підписаного сертифіката kubelet на конкретний вузол, на якому працює kubelet.

Початкове завантаження TLS, описане у цьому документі, призначене спростити та частково або повністю автоматизувати кроки з 3 по 14, оскільки вони є найбільш поширеними при ініціалізації або масштабуванні кластера.

Ініціалізація початкового завантаження

Під час процесу ініціалізації початкового завантаження відбувається наступне:

  1. kubelet починає роботу.
  2. kubelet бачить, що у нього немає файлу kubeconfig.
  3. kubelet шукає та знаходить файл bootstrap-kubeconfig.
  4. kubelet читає свій файл ініціалізації початкового завантаження, отримуючи URL-адресу сервера API та обмежений "токен".
  5. kubelet підключається до сервера API, автентифікується за допомогою токена.
  6. у kubelet тепер є обмежені облікові дані для створення та отримання запиту на підпис сертифіката (CSR).
  7. kubelet створює CSR для себе з встановленим signerName kubernetes.io/kube-apiserver-client-kubelet.
  8. CSR затверджується одним з двох способів:
    • Якщо налаштовано, kube-controller-manager автоматично затверджує CSR.
    • Якщо налаштовано, зовнішній процес, можливо, людина, затверджує CSR за допомогою API Kubernetes або через kubectl.
  9. Сертифікат створюється для kubelet.
  10. Сертифікат видано для kubelet.
  11. kubelet отримує сертифікат.
  12. kubelet створює належний kubeconfig з ключем та підписаним сертифікатом.
  13. kubelet починає нормальну роботу.
  14. Опціонально: якщо налаштовано, kubelet автоматично запитує поновлення сертифіката, коли той наближається до закінчення строку дії.
  15. Поновлений сертифікат затверджується та видається, або автоматично, або вручну, залежно від налаштувань.

Усі інші розділи цього документу описують необхідні кроки для налаштування початкового завантаження 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, рекомендується використовувати наступні два автентифікатори для полегшення надання прав.

  1. Токени початкового завантаження
  2. Файл автентифікації токенів

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

Який би метод ви не обрали, вимога полягає в тому, щоб kubelet міг автентифікуватися як користувач з правами на:

  1. створення та отримання CSRs
  2. автоматичне затвердження запиту клієнтських сертифікатів вузлів, якщо увімкнено автоматичне затвердження.

Kubelet, який автентифікується за допомогою початкових токенів, автентифікується як користувач у групі system:bootstrappers, що є стандартним методом використання.

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

Токени початкового завантаження

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

Процес складається з двох етапів:

  1. Створити Secret Kubernetes з ідентифікатором токена, секретом і областю(ями).
  2. Видати токен 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.

Файл токенів повинен виглядати як у наступному прикладі, де перші три значення можуть бути будь-якими, а імʼя групи в лапках повинно бути таким, як показано:

02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"

Додайте прапорець --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/v1
kind: ClusterRoleBinding
metadata:
  name: create-csrs-for-bootstrapping
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:node-bootstrapper
  apiGroup: 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-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"

Наприклад:

--cluster-signing-cert-file="/var/lib/kubernetes/ca.pem" --cluster-signing-key-file="/var/lib/kubernetes/ca-key.pem"

Тривалість дійсності підписаних сертифікатів можна налаштувати за допомогою прапорця:

--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/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-csrs-for-group
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
  apiGroup: rbac.authorization.k8s.io

Щоб дозволити kubelet оновлювати власний клієнтський сертифікат, створіть ClusterRoleBinding, що звʼязує групу, в якій є членом повнофункціональний вузол, system:nodes, з ClusterRole, що надає їй дозвіл, system:certificates.k8s.io:certificatesigningrequests:selfnodeclient:

# Затвердження запитів на оновлення CSR для групи "system:nodes"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-renewals-for-nodes
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
  apiGroup: 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. Приклад файлу може виглядати наступним чином:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /var/lib/kubernetes/ca.pem
    server: https://my.server.example.com:6443
  name: bootstrap
contexts:
- context:
    cluster: bootstrap
    user: kubelet-bootstrap
  name: bootstrap
current-context: bootstrap
preferences: {}
users:
- name: kubelet-bootstrap
  user:
    token: 07401b.f395accd246ae52d

Важливі елементи:

  • certificate-authority: шлях до файлу CA, використовується для перевірки сертифіката сервера, представленого kube-apiserver
  • server: URL до kube-apiserver
  • token: токен для використання

Формат токена не має значення, головне, щоб він відповідав очікуванням kube-apiserver. У наведеному прикладі ми використали початковий токен. Як зазначалося раніше, будь-який дійсний метод автентифікації може бути використаний, а не тільки токени.

Оскільки початковий kubeconfig є стандартним kubeconfig, ви можете використовувати kubectl для його створення. Щоб створити вищезазначений приклад файлу:

kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/var/lib/kubernetes/ca.pem
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap

Щоб вказати kubelet використовувати початковий kubeconfig, використовуйте наступний прапорець:

--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"

Під час запуску 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

Інші складові автентифікації

Усі процеси завантаження 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 не вказаним.

Початок роботи з правилами перевірки допуску

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

Створення ValidatingAdmissionPolicy

Нижче наведено приклад ValidatingAdmissionPolicy.

validatingadmissionpolicy/basic-example-policy.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 5"

spec.validations містить вирази CEL, які використовують Мову загальних виразів (CEL), щоб перевірити запит. Якщо вираз обчислюється як false, перевірка валідації застосовується згідно з полем spec.failurePolicy.

Для налаштування правил перевірки допуску для використання в кластері потрібна привʼязка. Нижче наведено приклад ValidatingAdmissionPolicyBinding.:

validatingadmissionpolicy/basic-example-binding.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding-test.example.com"
spec:
  policyName: "demo-policy.example.com"
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: test

Спробувавши створити Deployment з репліками, які не відповідають виразу валідації, буде повернута помилка з повідомленням:

ValidatingAdmissionPolicy 'demo-policy.example.com' with binding 'demo-binding-test.example.com' denied request: failed expression: object.spec.replicas <= 5

Вище наведено простий приклад використання 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 з конфігурацією параметра.

validatingadmissionpolicy/policy-with-param.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "replicalimit-policy.example.com"
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: rules.example.com/v1
    kind: ReplicaLimit
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= params.maxReplicas"
      reason: Invalid

Поле spec.paramKind ValidatingAdmissionPolicy вказує на вид використовуваних ресурсів для параметризації цього правила. У цьому прикладі це налаштовано за допомогою ресурсів ReplicaLimit. Зверніть увагу в цьому прикладі, як вираз CEL посилається на параметри через змінну CEL params, наприклад, params.maxReplicas. spec.matchConstraints вказує, для яких ресурсів ця правило призначена для валідації. Зверніть увагу, що як параметр можуть використовуватися і стандартні типи, такі як ConfigMap.

Поля spec.validations містять вирази CEL. Якщо вираз оцінюється як false, то валідаційна перевірка здійснюється відповідно до поля spec.failurePolicy.

Автор правил перевірки допуску відповідає за надання параметра CRD ReplicaLimit.

Для налаштування правил перевірки допуску для використання в кластері створюються привʼязка та ресурс параметра. Наведено приклад ValidatingAdmissionPolicyBinding який використовує кластерний параметр — той самий параметр буде використовуватися для валідації кожного запиту до ресурсу, який відповідає привʼязці:

validatingadmissionpolicy/binding-with-param.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "replicalimit-binding-test.example.com"
spec:
  policyName: "replicalimit-policy.example.com"
  validationActions: [Deny]
  paramRef:
    name: "replica-limit-test.example.com"
    namespace: "default"
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: test

Зверніть увагу, що ця привʼязка застосовує параметр до правил для всіх ресурсів, які знаходяться в середовищі test.

Ресурс параметра може мати наступний вигляд:

validatingadmissionpolicy/replicalimit-param.yaml 
apiVersion: rules.example.com/v1
kind: ReplicaLimit
metadata:
  name: "replica-limit-test.example.com"
  namespace: "default"
maxReplicas: 3

Цей ресурс параметра правил обмежує Deployments до максимуму 3 репліки.

В правилі допуску може бути кілька привʼязок. Щоб привʼязати всі інші середовища до обмеження maxReplicas 100, створіть інший ValidatingAdmissionPolicyBinding:

validatingadmissionpolicy/binding-with-param-prod.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  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: environment
        operator: NotIn
        values:
        - test

Зверніть увагу, що ця привʼязка застосовує різний параметр до ресурсів, які не знаходяться в середовищі test.

Та має ресурс параметра:

validatingadmissionpolicy/replicalimit-param-prod.yaml 
apiVersion: rules.example.com/v1
kind: ReplicaLimit
metadata:
  name: "replica-limit-prod.example.com"
maxReplicas: 100

Для кожного запиту на допуск, сервер 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) || (params.optionalNumber >= 5 && params.optionalNumber <= 10)

Тут спочатку ми перевіряємо, що необовʼязковий параметр присутній за допомогою !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:

validatingadmissionpolicy/failure-policy-ignore.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
spec:
...
failurePolicy: Ignore # стандартно "Fail"
validations:
- expression: "object.spec.xyz == params.x"

Вирази валідації

spec.validations[i].expression представляє вираз, який буде оцінений за допомогою CEL. Для отримання додаткової інформації див. Специфікацію мови CEL. Вирази CEL мають доступ до вмісту запиту/відповіді допуску, організованого в змінні CEL, а також деяких інших корисних змінних:

  • 'object' — Обʼєкт з вхідного запиту. Значення null для запитів DELETE.
  • 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE.
  • 'request' — Атрибути запиту допуску.
  • 'params' — Ресурс параметра, на який посилається привʼязка правила, яке оцінюється. Значення null, якщо ParamKind не вказано.
  • namespaceObject — Простір імен, як ресурс Kubernetes, до якого належить вхідний обʼєкт. Значення null, якщо вхідний обʼєкт має область видимості кластера.
  • authorizer — Авторизатор CEL. Може використовуватися для виконання перевірок авторизації для принципала (автентифікованого користувача) запиту. Див. AuthzSelectors та 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 з неперетинаючимися ключами додаються, зберігаючи їх частковий порядок.

Приклади виразів валідації

ВиразПризначення
object.minReplicas <= object.replicas && object.replicas <= object.maxReplicasПеревірка правильного порядку трьох полів, що визначають репліки
'Available' in object.stateCountsПеревірка наявності запису з ключем 'Available' в map
(size(object.list1) == 0) != (size(object.list2) == 0)Перевірка, що один із двох списків не порожній, але не обидва
!('MY_KEY' in object.map1) || object['MY_KEY'].matches('^[a-zA-Z]*$')Перевірка значення map для певного ключа, якщо він є в map
object.envars.filter(e, e.name == 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')Перевірка поля 'value' запису у listMap, де значення ключа 'name' - 'MY_ENV'
has(object.expired) && object.created + object.ttl < object.expiredПеревірка, що дата 'expired' пізніше дати 'create' плюс тривалість 'ttl'
object.health.startsWith('ok')Перевірка, що рядок 'health' починається з префікса 'ok'
object.widgets.exists(w, w.key == 'x' && w.foo < 10)Перевірка, що поле 'foo' запису у listMap з ключем 'x' менше 10
type(object) == string ? object == '100%' : object == 1000Перевірка поля типу int або string на значення int та string
object.metadata.name.startsWith(object.prefix)Перевірка, що імʼя обʼєкта має префікс значення іншого поля
object.set1.all(e, !(e in object.set2))Перевірка, що два listSet не перетинаються
size(object.names) == size(object.details) && object.names.all(n, n in object.details)Перевірка, що map 'details' має ключі, визначені елементами списку 'names'
size(object.clusters.filter(c, c.name == object.primary)) == 1Перевірка, що властивість 'primary' має лише один випадок в listMap 'clusters'

Для отримання додаткової інформації щодо правил CEL прочитайте Supported evaluation on CEL.

spec.validation[i].reason представляє машинночитаний опис причини невдачі цієї валідації. Якщо це перша валідація в списку, яка завершується невдачею, ця причина, а також відповідний код відповіді HTTP використовуються у відповіді HTTP клієнту. Підтримувані зараз причини: Unauthorized, Forbidden, Invalid, RequestEntityTooLarge. Якщо не встановлено, StatusReasonInvalid використовується у відповіді клієнту.

Відповідність запитів: matchConditions

Ви можете визначити умови відповідності для ValidatingAdmissionPolicy, якщо вам потрібно дотримуватися детального фільтрування запитів. Ці умови корисні, якщо ви виявите, що правила відповідності, objectSelectors та namespaceSelectors все ще не забезпечують потрібного фільтрування. Умови відповідності — це вирази CEL. Усі умови відповідності повинні оцінюватися як true для ресурсу, який має бути оцінений.

Нижче наведено приклад, що ілюструє кілька різних використань умов відповідності:

access/validating-admission-policy-match-conditions.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    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, що й вирази валідації.

У випадку помилки при оцінці умови відповідності правило не оцінюється. Рішення про відхилення запиту визначається наступним чином:

  1. Якщо будь-яка умова відповідності оцінюється як false (незалежно від інших помилок), сервер API пропускає політику.
  2. В іншому випадку:
    • для failurePolicy: Fail, відхилити запит (без оцінки правил).
    • для failurePolicy: Ignore, продовжити з запитом, але пропустити політику.

Анотації аудиту

auditAnnotations можна використовувати для включення анотацій аудиту в аудит-подію запиту API.

Наприклад, ось правила допуску з анотацією аудиту:

access/validating-admission-policy-audit-annotation.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    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. На відміну від валідації, вираз повідомлення має повертати рядок.

Наприклад, щоб краще інформувати користувача про причину відхилення, коли правило посилається на параметр, ми можемо мати наступну валідацію:

access/deployment-replicas-policy.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "deploy-replica-policy.example.com"
spec:
  paramKind:
    apiVersion: rules.example.com/v1
    kind: ReplicaLimit
  matchConstraints:
    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=5
error: 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 означає, що помилок не виявлено.

Наприклад, з наступним визначенням правил:

validatingadmissionpolicy/typechecking.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  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

Статус надасть таку інформацію:

status:
  typeChecking:
    expressionWarnings:
    - fieldRef: spec.validations[0].expression
      warning: |-
        apps/v1, Kind=Deployment: ERROR: <input>:1:7: undefined field 'replicas'
         | object.replicas > 1
         | ......^

Якщо в spec.matchConstraints збігається кілька ресурсів, всі ресурси, які мають збіг, будуть перевірені. Наприклад, наступне визначення правил:

validatingadmissionpolicy/typechecking-multiple-match.yaml 
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  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

буде мати декілька типів та результат перевірки типів кожного типу у повідомленні про попередження.

status:
  typeChecking:
    expressionWarnings:
    - fieldRef: spec.validations[0].expression
      warning: |-
        apps/v1, Kind=Deployment: ERROR: <input>:1:7: undefined field 'replicas'
         | object.replicas > 1
         | ......^
        apps/v1, Kind=ReplicaSet: ERROR: <input>:1:7: undefined field 'replicas'
         | object.replicas > 1
         | ......^

Перевірка типів має такі обмеження:

  • Відсутнє зіставлення за шаблоном. Якщо spec.matchConstraints.resourceRules містить "*" у будь-якому з apiGroups, apiVersions або resources, типи, які відповідають "*", не будуть перевірені.
  • Кількість збігів типів обмежена до 10. Це робиться для запобігання використанню правил, що вручну вказує занадто багато типів, що може споживати занадто багато обчислювальних ресурсів. Порядок спадання групи, версії, а потім ресурсу, 11-а комбінація та після буде ігноруватися.
  • Перевірка типів не впливає на поведінку правил жодним чином. Навіть якщо під час перевірки типів виявляються помилки, політика буде продовжувати оцінюватися. Якщо під час оцінки виникають помилки, політика вибере свій результат.
  • Перевірка типів не застосовується до CRD, включаючи відповідні типи CRD та посилання на paramKind. Підтримка CRD зʼявиться у майбутній версії.

Склад змінних

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

spec:
  variables:
    - name: foo
      expression: "'foo' in object.spec.metadata.labels ? object.spec.metadata.labels['foo'] : 'default'"
  validations:
    - expression: variables.foo == 'bar'

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

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

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

access/image-matches-namespace-environment.policy.yaml 
# Це правило забезпечує виконання умови, що всі контейнери deployment повинні мати збіг репозиторієв образів з міткою середовища його простору імен.
# За винятком deployment, позначених як "exempt", або будь-яких контейнерів, які не належать організації "example.com" (наприклад, загальні sidecar).
# Наприклад, якщо у просторі імен є мітка {"environment": "staging"}, всі контейнери повинні мати репозиторій, який є або staging.example.com/*
# або не містить "example.com" взагалі, якщо deployment має мітку {"exempt": "true"}.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "image-matches-namespace-environment.policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  variables:
  - name: environment
    expression: "'environment' in namespaceObject.metadata.labels ? namespaceObject.metadata.labels['environment'] : 'prod'"
  - name: exempt
    expression: "'exempt' in object.metadata.labels && object.metadata.labels['exempt'] == 'true'"
  - name: containers
    expression: "object.spec.template.spec.containers"
  - name: containersToCheck
    expression: "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 буде відхилена.

kubectl create deploy --image=dev.example.com/nginx invalid

Повідомлення про помилку буде схоже на таке.

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

apf.kubernetes.io/autoupdate-spec

Тип: Annotation

Приклад: apf.kubernetes.io/autoupdate-spec: "true"

Використовується для: Обʼєктів FlowSchema та PriorityLevelConfiguration

Якщо ця анотація встановлена в значення true для FlowSchema або PriorityLevelConfiguration, то spec для цього обʼєкта управляється kube-apiserver. Якщо сервер API не розпізнає обʼєкт APF, а ви анотуєте його для автоматичного оновлення, сервер API видаляє весь обʼєкт. У іншому випадку сервер API не управляє специфікацією обʼєкта. Докладніше читайте Обслуговування обовʼязкових та рекомендованих обʼєктів конфігурації.

app.kubernetes.io/component

Тип: Label

Приклад: app.kubernetes.io/component: "database"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Компонент в архітектурі застосунку.

Одна з рекомендованих міток.

app.kubernetes.io/created-by (deprecated)

Тип: Label

Приклад: app.kubernetes.io/created-by: "controller-manager"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Контролер/користувач, який створив цей ресурс.

app.kubernetes.io/instance

Тип: Label

Приклад: app.kubernetes.io/instance: "mysql-abcxyz"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Унікальне імʼя, що ідентифікує екземпляр застосунку. Для призначення неунікального імені використовуйте app.kubernetes.io/name.

Одна з рекомендованих міток.

app.kubernetes.io/managed-by

Тип: Label

Приклад: app.kubernetes.io/managed-by: "helm"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Інструмент, що використовується для управління роботою застосунку.

Одна з рекомендованих міток.

app.kubernetes.io/name

Тип: Label

Приклад: app.kubernetes.io/name: "mysql"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Назва застосунку.

Одна з рекомендованих міток.

app.kubernetes.io/part-of

Тип: Label

Приклад: app.kubernetes.io/part-of: "wordpress"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Назва застосунку вищого рівня, частиною якого є цей обʼєкт.

Одна з рекомендованих міток.

app.kubernetes.io/version

Тип: Label

Приклад: app.kubernetes.io/version: "5.7.21"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Поточна версія застосунку.

Загальні форми значень включають:

Одна з рекомендованих міток.

applyset.kubernetes.io/additional-namespaces (alpha)

Тип: Annotation

Приклад: applyset.kubernetes.io/additional-namespaces: "namespace1,namespace2"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського обʼєкта, який використовується для відстеження ApplySet для розширення області застосування ApplySet поза власним простором імен батьківського обʼєкта (якщо є). Значення — це розділені комами імена просторів імен, в яких знаходяться обʼєкти, відмінні від простору імен батьківського обʼєкта.

applyset.kubernetes.io/contains-group-kinds (alpha)

Тип: Annotation

Приклад: applyset.kubernetes.io/contains-group-kinds: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського об’єкта, який використовується для відстеження ApplySet для оптимізації списку об’єктів-членів ApplySet. Не є обовʼязковою у специфікації ApplySet, оскільки інструменти можуть виконувати виявлення або використовувати іншу оптимізацію. Однак, починаючи з версії Kubernetes 1.31, kubectl вимагає її наявності. Якщо присутнє, значення цієї анотації має бути розділеним комами списком типів груп у форматі повної назви, тобто. <resource>.<group>.

applyset.kubernetes.io/contains-group-resources (deprecated)

Тип: Annotation

Приклад: applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського об’єкта, який використовується для відстеження ApplySet для оптимізації списку об’єктів-членів ApplySet. Не є обовʼязковою у специфікації ApplySet, оскільки інструменти можуть виконувати виявлення або використовувати іншу оптимізацію. Однак, починаючи з версії Kubernetes 1.31, kubectl вимагає її наявності. Якщо присутнє, значення цієї анотації має бути розділеним комами списком типів груп у форматі повної назви, тобто. <resource>.<group>.

applyset.kubernetes.io/id (alpha)

Тип: Label

Приклад: applyset.kubernetes.io/id: "applyset-0eFHV8ySqp7XoShsGvyWFQD3s96yqwHmzc4e0HR1dsY-v1"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї мітки є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю мітку на 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 обʼєкта немає звʼязку.

applyset.kubernetes.io/is-parent-type (alpha)

Тип: Label

Приклад: applyset.kubernetes.io/is-parent-type: "true"

Використовується для: Custom Resource Definition (CRD)

Використання цієї мітки є альфа-версією. Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ви можете встановити цю мітку на CustomResourceDefinition (CRD), щоб ідентифікувати тип власного ресурсу, який він визначає (а не сам CRD) як дозволеного батька для ApplySet. Єдиним допустимим значенням для цієї мітки є "true"; якщо ви хочете позначити CRD як такий, що не є дійсним батьком для ApplySets, пропустіть цю мітку.

applyset.kubernetes.io/part-of (alpha)

Тип: Label

Приклад: applyset.kubernetes.io/part-of: "applyset-0eFHV8ySqp7XoShsGvyWFQD3s96yqwHmzc4e0HR1dsY-v1"

Використовується для: Всі обʼєкти.

Використання цієї мітки є альфа-версією. Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця мітка робить обʼєкт членом ApplySet. Значення мітки повинно збігатися зі значенням мітки applyset.kubernetes.io/id у батьківському обʼєкті.

applyset.kubernetes.io/tooling (alpha)

Тип: Annotation

Приклад: applyset.kubernetes.io/tooling: "kubectl/v1.31"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на 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ʼів.

resource.kubernetes.io/pod-claim-name

Тип: Annotation

Приклад: resource.kubernetes.io/pod-claim-name: "my-pod-claim"

Використовується для: ResourceClaim

Ця анотація додається до створених вимог на ресурси. Її значення відповідає назві вимоги ресурсу у файлі .spec будь-якого Podʼа(ів), для якого було створено ResourceClaim. Ця анотація є внутрішньою деталлю реалізації динамічного розподілу ресурсів. Вам не потрібно читати або змінювати значення цієї анотації.

cluster-autoscaler.kubernetes.io/safe-to-evict

Тип: Annotation

Приклад: cluster-autoscaler.kubernetes.io/safe-to-evict: "true"

Використовується для: Pod

Коли ця анотація має значення "true", автомасштабувальнику кластера дозволяється виселяти Pod навіть якщо інші правила зазвичай забороняють це робити. Автомасштабувальник кластера ніколи не виселяє Podʼи, для яких ця анотація явно встановлена у значення "false"; ви можете встановити це значення для важливого Podʼа, який ви хочете продовжувати виконувати. Якщо цю анотацію не задано, то автомасштабувальник кластера поводитиметься так, як він поводиться на рівні Podʼа.

config.kubernetes.io/local-config

Тип: Annotation

Приклад: config.kubernetes.io/local-config: "true"

Використовується для: Всі обʼєкти

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

Значення "true" для цієї анотації вказує, що обʼєкт використовується лише клієнтськими інструментами і не повинен бути надісланий на сервер API.

Значення "false" може бути використане для вказівки, що обʼєкт повинен бути надісланий на сервер API, навіть якщо в іншому випадку він вважався б локальним.

Ця анотація є частиною специфікації функцій Kubernetes Resource Model (KRM), яка використовується Kustomize та подібними сторонніми інструментами. Наприклад, Kustomize видаляє обʼєкти з цією анотацією з кінцевого результату збирання коду.

container.apparmor.security.beta.kubernetes.io/* (beta)

Тип: Annotation

Приклад: container.apparmor.security.beta.kubernetes.io/my-container: my-custom-profile

Використовується для: Pods

Ця анотація дозволяє вам вказати профіль безпеки AppArmor для контейнера в межах Podʼа Kubernetes. Починаючи з версії Kubernetes 1.30, це слід налаштовувати за допомогою поля appArmorProfile. Щоб дізнатися більше, перегляньте підручник з AppArmor. У підручнику показано, як використовувати AppArmor для обмеження можливостей і доступу контейнера.

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

internal.config.kubernetes.io/* (reserved prefix)

Тип: Annotation

Використовується для: Всі обʼєкти

Цей префікс зарезервований для внутрішнього використання інструментами, які діють як оркестратори відповідно до специфікації функцій Моделі Ресурсів Kubernetes (KRM). Анотації з цим префіксом є внутрішніми для процесу оркестрування та не зберігаються в маніфестах у файловій системі. Іншими словами, інструмент-оркестратор повинен встановлювати ці анотації при зчитуванні файлів з локальної файлової системи та видаляти їх при записі результатів роботи функцій назад у файлову систему.

Функція KRM не повинна змінювати анотації з цим префіксом, якщо не зазначено інше для конкретної анотації. Це дозволяє інструментам оркестрування додавати додаткові внутрішні анотації без необхідності вносити зміни в існуючі функції.

internal.config.kubernetes.io/path

Тип: Annotation

Приклад: internal.config.kubernetes.io/path: "relative/file/path.yaml"

Використовується для: Всі обʼєкти

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

Ця анотація є частиною специфікації функцій Моделі Ресурсів 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ʼа.

kubernetes.io/metadata.name

Тип: Label

Приклад: kubernetes.io/metadata.name: "mynamespace"

Використовується для: Namespaces

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.

kubernetes.io/config.hash

Тип: Annotation

Приклад: kubernetes.io/config.hash: "df7cc47f8477b6b1226d7d23a904867b"

Використовується для: Pod

Коли kubelet створює статичний Pod на основі заданого маніфесту, він додає цю анотацію до статичного Pod. Значення анотації — це UID Pod. Зверніть увагу, що kubelet також встановлює .spec.nodeName у поточне імʼя вузла, ніби Pod було заплановано на цей вузол.

kubernetes.io/config.mirror

Тип: Annotation

Приклад: kubernetes.io/config.mirror: "df7cc47f8477b6b1226d7d23a904867b"

Використовується для: 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.

kubernetes.io/config.seen

Тип: Annotation

Приклад: kubernetes.io/config.seen: "2023-10-27T04:04:56.011314488Z"

Використовується для: Pod

Коли kubelet вперше бачить Pod, він може додати цю анотацію до Pod зі значенням поточного часу у форматі RFC3339.

addonmanager.kubernetes.io/mode

Тип: Label

Приклад: addonmanager.kubernetes.io/mode: "Reconcile"

Використовується для: Всі обʼєкти

Для вказання того, як слід керувати надбудовою, ви можете використовувати мітку addonmanager.kubernetes.io/mode. Ця мітка може мати одне з трьох значень: Reconcile, EnsureExists або Ignore.

  • Reconcile: Ресурси надбудови періодично будуть зведені до очікуваного стану. Якщо є будь-які відмінності, менеджер надбудов буде переробляти, змінювати конфігурацію або видаляти ресурси за потреби. Цей режим є стандартним режимом, якщо мітка не вказана.
  • EnsureExists: Ресурси надбудов будуть перевірятися лише на наявність, але не будуть змінюватися після створення. Менеджер надбудов створить або переробить ресурси, коли відсутній жоден екземпляр ресурсу з таким імʼям.
  • Ignore: Ресурси надбудов будуть ігноруватися. Цей режим корисний для надбудов, які не сумісні з менеджером надбудов або керуються іншим контролером.

Для отримання докладнішої інформації див. Addon-manager.

beta.kubernetes.io/arch (deprecated)

Тип: Label

Ця мітка є застарілою. Використовуйте натомість kubernetes.io/arch.

beta.kubernetes.io/os (deprecated)

Тип: Label

Ця мітка є застарілою. Використовуйте натомість kubernetes.io/os.

kube-aggregator.kubernetes.io/automanaged

Тип: Label

Приклад: kube-aggregator.kubernetes.io/automanaged: "onstart"

Використовується для: APIService

kube-apiserver встановлює цю мітку для будь-якого обʼєкта APIService, який сервер API створив автоматично. Мітка позначає, як панель управління повинна керувати цим APIService. Ви не повинні додавати, змінювати або видаляти цю мітку самостійно.

Є два можливих значення:

  • onstart: APIService повинен бути зведений до очікуваного стану при старті сервера API, але не під час інших операцій.
  • true: Сервер API повинен безперервно зводити цей APIService до очікуваного стану.

service.alpha.kubernetes.io/tolerate-unready-endpoints (deprecated)

Тип: Annotation

Використовується для: StatefulSet

Ця анотація на Service вказує, чи повинен контролер точок доступу створювати точки доступу для неготових Podʼів. Точки доступу цих Service зберігають свої DNS-записи і продовжують отримувати трафік для Service з моменту, коли kubelet запускає всі контейнери у Pod і позначає його як Running, до моменту, коли kubelet зупиняє всі контейнери і видаляє Pod з сервера API.

autoscaling.alpha.kubernetes.io/behavior (deprecated)

Тип: Annotation

Використовується для: HorizontalPodAutoscaler

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

kubernetes.io/hostname

Тип: Label

Приклад: kubernetes.io/hostname: "ip-172-20-114-199.ec2.internal"

Використовується для: Node

Kubelet заповнює цю мітку імʼям хоста вузла. Зверніть увагу, що імʼя хоста може бути змінене з "фактичного" імʼя хоста за допомогою прапорця --hostname-override для kubelet.

Ця мітка також використовується як частина ієрархії топології. Дивіться topology.kubernetes.io/zone для отримання додаткової інформації.

kubernetes.io/change-cause

Тип: Annotation

Приклад: kubernetes.io/change-cause: "kubectl edit --record deployment foo"

Використовується для: Всіх обʼєктів

Ця анотація є найкращою спробою пояснення причини зміни чого-небудь.

Вона заповнюється при додаванні параметру --record до команди kubectl, яка може змінити обʼєкт.

kubernetes.io/description

Тип: Annotation

Приклад: kubernetes.io/description: "Description of K8s object."

Використовується для: Всіх обʼєктів

Ця анотація використовується для опису конкретної поведінки вказаного обʼєкта.

kubernetes.io/enforce-mountable-secrets

Тип: Annotation

Приклад: kubernetes.io/enforce-mountable-secrets: "true"

Використовується для: ServiceAccount

Значення цієї анотації повинно бути true, щоб вона набула чинності. Коли ви встановлюєте цю анотацію у значення "true", Kubernetes застосовує наступні правила для Podʼів, що працюють з цим ServiceAccount:

  1. Secretʼи, змонтовані як томи, повинні бути перелічені в полі secrets ServiceAccount.
  2. Secretʼи, на які посилаються у полі envFrom для контейнерів (включаючи контейнери sidecar і контейнери ініціалізації), також повинні бути перелічені в полі secrets ServiceAccount. Якщо будь-який контейнер в Podʼі посилається на Secret, який не перелічений в полі secrets ServiceAccount (навіть якщо посилання позначене як optional), то Pod не запуститься, і буде згенеровано помилку, що вказує на невідповідне посилання на секрет.
  3. Secretʼи, на які посилається у полі imagePullSecrets Podʼа, повинні бути присутніми в полі imagePullSecrets ServiceAccount, Pod не запуститься, і буде згенеровано помилку, що вказує на невідповідне посилання на секрет для отримання образу.

Під час створення або оновлення Podʼа перевіряються ці правила. Якщо Pod не відповідає їм, він не запуститься, і ви побачите повідомлення про помилку. Якщо Pod уже працює, і ви змінюєте анотацію kubernetes.io/enforce-mountable-secrets на значення true, або ви редагуєте повʼязаний ServiceAccount для видалення посилання на Secret, який вже використовується Podʼом, Pod продовжить працювати.

node.kubernetes.io/exclude-from-external-load-balancers

Тип: Label

Приклад: node.kubernetes.io/exclude-from-external-load-balancers

Використовується для: Node

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

kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers=true

controller.kubernetes.io/pod-deletion-cost

Тип: Annotation

Приклад: controller.kubernetes.io/pod-deletion-cost: "10"

Використовується для: Pod

Ця анотація використовується для встановлення Вартості видалення Podʼа, що дозволяє користувачам впливати на порядок зменшення масштабування ReplicaSet. Значення анотації аналізується як тип int32.

cluster-autoscaler.kubernetes.io/enable-ds-eviction

Тип: Annotation

Приклад: cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"

Використовується для: Pod

Ця анотація контролює, чи повинен бути виселений Pod DaemonSet за допомогою ClusterAutoscaler. Ця анотація повинна бути вказана на Pod DaemonSet у маніфесті DaemonSet. Коли ця анотація встановлена в значення "true", ClusterAutoscaler дозволяє виселити Pod DaemonSet, навіть якщо інші правила зазвичай цього уникнули б. Щоб заборонити ClusterAutoscaler виселяти Pod DaemonSet, ви можете встановити цю анотацію в значення "false" для важливих Pod DaemonSet. Якщо ця анотація не встановлена, тоді ClusterAutoscaler діє згідно своєї загальної поведінки (тобто виселяє Pod DaemonSets на основі своєї конфігурації).

kubernetes.io/ingress-bandwidth

Тип: Annotation

Приклад: kubernetes.io/ingress-bandwidth: 10M

Використовується для: Pod

Ви можете застосувати обмеження пропускної здатності відповідно для якості обслуговування до Pod щоб ефективно обмежити його доступну пропускну здатність. Вхідний трафік до Podʼа обробляється за допомогою упорядкованої черги пакетів для ефективного керування даними. Щоб обмежити пропускну здатність Podʼа, напишіть файл визначення обʼєкта JSON і вкажіть швидкість передачі даних за допомогою анотації kubernetes.io/ingress-bandwidth. Одиницею, яка використовується для вказівки швидкості вхідної передачі, є біти на секунду, в форматі Кількості. Наприклад, 10M означає 10 мегабіт на секунду.

kubernetes.io/egress-bandwidth

Тип: Annotation

Приклад: kubernetes.io/egress-bandwidth: 10M

Використовується для: Pod

Вихідний трафік з Podʼа обробляється за допомогою застосування політик, які просто відкидають пакети, що перевищують налаштовану швидкість. Обмеження, які ви встановлюєте на Pod, не впливають на пропускну здатність інших Podʼів. Щоб обмежити пропускну здатність Podʼа, напишіть файл визначення обʼєкта JSON і вкажіть швидкість передачі даних за допомогою анотації kubernetes.io/egress-bandwidth. Одиницею, яка використовується для вказівки швидкості вихідної передачі, є біти на секунду, в форматі Кількості. Наприклад, 10M означає 10 мегабіт на секунду.

beta.kubernetes.io/instance-type (deprecated)

Тип: Label

node.kubernetes.io/instance-type

Тип: Label

Приклад: node.kubernetes.io/instance-type: "m3.medium"

Використовується для: Node

Kubelet заповнює це значенням типу екземпляра, як визначено постачальником хмарних послуг. Це буде встановлено лише в разі використання постачальника хмарних послуг. Це налаштування є зручним, якщо ви хочете спрямувати певні робочі навантаження на певні типи екземплярів, але, як правило, ви хочете покладатися на планувальник Kubernetes для виконання планування на основі ресурсів. Ви повинні намагатися планувати на основі властивостей, а не на основі типів екземплярів (наприклад, потребувати GPU, замість потреби в g2.2xlarge).

failure-domain.beta.kubernetes.io/region (deprecated)

Тип: Label

failure-domain.beta.kubernetes.io/zone (deprecated)

Тип: Label

pv.kubernetes.io/bind-completed

Тип: Annotation

Приклад: pv.kubernetes.io/bind-completed: "yes"

Використовується для: PersistentVolumeClaim

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

pv.kubernetes.io/bound-by-controller

Тип: Annotation

Приклад: pv.kubernetes.io/bound-by-controller: "yes"

Використовується для: PersistentVolume, PersistentVolumeClaim

Якщо ця анотація встановлена на PersistentVolume або PersistentVolumeClaim, це вказує на те, що звʼязка зберігання (PersistentVolume → PersistentVolumeClaim або PersistentVolumeClaim → PersistentVolume) була встановлена контролером. Якщо анотація не встановлена, а звʼязка зберігання вже існує, відсутність цієї анотації означає, що звʼязка була встановлена вручну. Значення цієї анотації не має значення.

pv.kubernetes.io/provisioned-by

Тип: Annotation

Приклад: pv.kubernetes.io/provisioned-by: "kubernetes.io/rbd"

Використовується для: PersistentVolume

Ця анотація додається до PersistentVolume (PV), який був динамічно розподілений Kubernetes. Її значення — це імʼя втулка тому, який створив том. Вона служить як користувачам (щоб показати, звідки походить PV), так і Kubernetes (щоб визначити динамічно розподілені PV у своїх рішеннях).

pv.kubernetes.io/migrated-to

Тип: Annotation

Приклад: pv.kubernetes.io/migrated-to: pd.csi.storage.gke.io

Використовується для: PersistentVolume, PersistentVolumeClaim

Ця анотація додається до PersistentVolume (PV) та PersistentVolumeClaim (PVC), які мають бути динамічно розподілені або видалені відповідним драйвером CSI через власну функціональну можливість CSIMigration. Коли ця анотація встановлена, компоненти Kubernetes "припиняють боротьбу", і external-provisioner діятиме з обʼєктами.

statefulset.kubernetes.io/pod-name

Тип: Label

Приклад: statefulset.kubernetes.io/pod-name: "mystatefulset-7"

Використовується для: Pod

Коли контролер StatefulSet створює Pod для StatefulSet, панель управління встановлює цю мітку на Podʼі. Значення мітки — це імʼя створеного Podʼа.

Дивіться Мітка імені Podʼа у темі StatefulSet для отримання більш детальної інформації.

scheduler.alpha.kubernetes.io/node-selector

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/node-selector: "name-of-node-selector"

Використовується для: Namespace

PodNodeSelector використовує цей ключ анотації для призначення селекторів вузла до Podʼів у просторах імен.

topology.kubernetes.io/region

Тип: Label

Приклад: topology.kubernetes.io/region: "us-east-1"

Використовується для: Node, PersistentVolume

Див. topology.kubernetes.io/zone.

topology.kubernetes.io/zone

Тип: Label

Приклад: topology.kubernetes.io/zone: "us-east-1c"

Використовується для: Node, PersistentVolume

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

На PersistentVolume: постачальники томів, що мають відомості про топологію, автоматично встановлюють обмеження на спорідненість вузла для PersistentVolume.

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

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

Kubernetes робить кілька припущень щодо структури зон та регіонів:

  1. регіони та зони є ієрархічними: зони є строгими підмножинами регіонів, і жодна зона не може бути в двох регіонах;
  2. імена зон є унікальними у всіх регіонах; наприклад, регіон "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ʼам монтувати томи в інших зонах. Якщо ваша інфраструктура не має цього обмеження, вам не потрібно додавати мітки зони до томів взагалі.

volume.beta.kubernetes.io/storage-provisioner (deprecated)

Тип: Annotation

Приклад: volume.beta.kubernetes.io/storage-provisioner: "k8s.io/minikube-hostpath"

Використовується для: PersistentVolumeClaim

Ця анотація застаріла починаючи з v1.23. Дивіться volume.kubernetes.io/storage-provisioner.

volume.beta.kubernetes.io/storage-class (deprecated)

Тип: Annotation

Приклад: volume.beta.kubernetes.io/storage-class: "example-class"

Використовується для: PersistentVolume, PersistentVolumeClaim

Ця анотація може використовуватися для PersistentVolume(PV) або PersistentVolumeClaim(PVC), щоб вказати імʼя StorageClass. Коли обидва атрибути storageClassName та анотація volume.beta.kubernetes.io/storage-class вказані, анотація volume.beta.kubernetes.io/storage-class має перевагу над атрибутом storageClassName.

Ця анотація застаріла. Замість цього встановіть поле storageClassName для PersistentVolumeClaim або PersistentVolume.

volume.beta.kubernetes.io/mount-options (deprecated)

Тип: Annotation

Example : volume.beta.kubernetes.io/mount-options: "ro,soft"

Використовується для: PersistentVolume

Адміністратор Kubernetes може вказати додаткові опції монтування для того, коли PersistentVolume монтується на вузлі.

volume.kubernetes.io/storage-provisioner

Тип: Annotation

Використовується для: PersistentVolumeClaim

Ця анотація додається до PVC, яка має бути динамічно наданою. Її значення — це імʼя втулка тому, який має надати том для цієї PVC.

volume.kubernetes.io/selected-node

Тип: Annotation

Використовується для: PersistentVolumeClaim

Ця анотація додається до PVC, яка активується планувальником для динамічного надання. Її значення — це імʼя вибраного вузла.

volumes.kubernetes.io/controller-managed-attach-detach

Тип: Annotation

Використовується для: Node

Якщо вузол має анотацію volumes.kubernetes.io/controller-managed-attach-detach, його операції прикріплення та відʼєднання зберігання керуються контролером прикріплення/відʼєднання тому.

Значення анотації не має значення.

node.kubernetes.io/windows-build

Тип: Label

Приклад: node.kubernetes.io/windows-build: "10.0.17763"

Використовується для: Node

Коли kubelet працює на операційній системі Microsoft Windows, він автоматично позначає міткою свій вузол, щоб зафіксувати версію Windows Server, що використовується.

Значення мітки має формат "MajorVersion.MinorVersion.BuildNumber".

storage.alpha.kubernetes.io/migrated-plugins

Тип: Annotation

Приклад:storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/cinder"

Використовується для: CSINode (API розширення)

Цю анотацію буде автоматично додано до обʼєкта CSINode, який зіставляється з вузлом, на якому встановлено CSIDriver. Ця анотація показує назву вбудованого втулка, який було перенесено. Його значення залежить від вбудованого коду хмарного провайдера зберігання.

Наприклад, якщо тип зберігання вбудованого хмарного провайдера є CSIMigrationvSphere, обʼєкт CSINodes для вузла повинен бути оновлений наступним чином: storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/vsphere-volume"

service.kubernetes.io/headless

Тип: Label

Приклад: service.kubernetes.io/headless: ""

Використовується для: Service

Панель управління додає цю мітку до об’єкта Endpoints, коли Service-власник є headless. Щоб дізнатися більше, прочитайте Headless Services.

service.kubernetes.io/topology-aware-hints (deprecated)

Приклад: service.kubernetes.io/topology-aware-hints: "Auto"

Використовується для: Service

Ця анотація використовувалася для увімкнення підказок про топологію на Serviceʼах. Підказки щодо топології з тих пір були перейменовані: концепцію зараз називають Маршрутизацією з урахуванням топології. Встановлення анотації на Auto для Service налаштовує панель управління Kubernetes додавати підказки про топологію на EndpointSlices, повʼязані з цим Service. Ви також можете явно встановити анотацію на Disabled.

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

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

service.kubernetes.io/topology-mode

Тип: Annotation

Приклад: service.kubernetes.io/topology-mode: Auto

Використовується для: Service

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

Дивіться Маршрутизація з урахуванням топології для отримання додаткових відомостей.

kubernetes.io/service-name

Тип: Label

Приклад: kubernetes.io/service-name: "my-website"

Використовується для: EndpointSlice

Kubernetes асоціює EndpointSlices з Services за допомогою цієї мітки.

Ця мітка записує імʼя Service, який підтримує EndpointSlice. Усі EndpointSlices повинні мати цю мітку встановлену на імʼя їх повʼязаного Service.

kubernetes.io/service-account.name

Тип: Annotation

Приклад: kubernetes.io/service-account.name: "sa-name"

Використовується для: Secret

Ця анотація записує імʼя ServiceAccount, яке представляє токен (збережений у Secret типу kubernetes.io/service-account-token).

kubernetes.io/service-account.uid

Тип: Annotation

Приклад: kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da

Використовується для: Secret

Ця анотація записує унікальний ідентифікатор ServiceAccount, який представляє токен (збережений у Secret типу kubernetes.io/service-account-token).

kubernetes.io/legacy-token-last-used

Тип: Label

Приклад: kubernetes.io/legacy-token-last-used: 2022-10-24

Використовується для: Secret

Панель управління додає цю мітку лише до Secretʼів, які мають тип kubernetes.io/service-account-token. Значення цієї мітки записує дату (в форматі ISO 8601, в часовому поясі UTC), коли панель управління востаннє бачила запит, де клієнт автентифікувався за допомогою токена службового облікового запису.

Якщо легасі-токен використовувався останній раз до того, як кластер отримав цю функцію (додану у Kubernetes v1.26), то мітка не встановлена.

kubernetes.io/legacy-token-invalid-since

Тип: Label

Приклад: kubernetes.io/legacy-token-invalid-since: 2023-10-27

Використовується для: Secret

Панель управління автоматично додає цю мітку до автогенерованих Secretʼів з типом kubernetes.io/service-account-token, за умови, що у вас увімкнено функціональну можливість LegacyServiceAccountTokenCleanUp. У Kubernetes 1.31 ця поведінка включена стандартно. Ця мітка позначає токен на основі Secret як недійсний для автентифікації. Значення цієї мітки записує дату (в форматі ISO 8601, в часовому поясі UTC), коли панель управління виявляє, що автогенерований Secret не використовувався протягом вказаного періоду (стандартно, один рік).

endpointslice.kubernetes.io/managed-by

Тип: Label

Приклад: endpointslice.kubernetes.io/managed-by: endpointslice-controller.k8s.io

Використовується для: EndpointSlices

Ця мітка використовується для позначення контролера або сутності, яка керує EndpointSlice. Мета цієї мітки — забезпечити можливість керувати різними обʼєктами EndpointSlice різними контролерами або сутностями в межах одного та самого кластера.

endpointslice.kubernetes.io/skip-mirror

Тип: Label

Приклад: endpointslice.kubernetes.io/skip-mirror: "true"

Використовується для: Endpoints

Цю мітку можна встановити на значення "true" для ресурсу Endpoints, щоб позначити, що контролер EndpointSliceMirroring не повинен дублювати цей ресурс за допомогою EndpointSlices.

service.kubernetes.io/service-proxy-name

Тип: Label

Приклад: service.kubernetes.io/service-proxy-name: "foo-bar"

Використовується для: Service

У kube-proxy ця мітка використовується для власного проксі, який делегує керування сервісом до власного проксі.

experimental.windows.kubernetes.io/isolation-type (deprecated)

Тип: Annotation

Приклад: experimental.windows.kubernetes.io/isolation-type: "hyperv"

Використовується для: Pod

Ця анотація використовується для запуску контейнерів Windows з ізоляцією Hyper-V.

ingressclass.kubernetes.io/is-default-class

Тип: Annotation

Приклад: ingressclass.kubernetes.io/is-default-class: "true"

Використовується для: IngressClass

Якщо ресурс IngressClass має цю анотацію встановлену на значення "true", новий ресурс Ingress без вказаного класу буде призначено цей стандартний клас.

nginx.ingress.kubernetes.io/configuration-snippet

Тип: Annotation

Приклад: nginx.ingress.kubernetes.io/configuration-snippet: " more_set_headers \"Request-Id: $req_id\";\nmore_set_headers \"Example: 42\";\n"

Використовується для: Ingress

Ви можете використовувати цю анотацію для налаштування додаткових параметрів Ingress, що використовує NGINX Ingress Controller. Анотація configuration-snippet стандартно ігнорується, починаючи з версії 1.9.0 контролера ingress. Щоб використовувати цю анотацію, потрібно явно увімкнути налаштування контролера NGINX ingress allow-snippet-annotations. Увімкнення цієї анотації може бути небезпечним у кластері з декількома орендарями, оскільки це може дозволити людям з обмеженими правами доступу отримувати всі Secrets у кластері.

kubernetes.io/ingress.class (deprecated)

Тип: Annotation

Використовується для: Ingress

storageclass.kubernetes.io/is-default-class

Тип: Annotation

Приклад: storageclass.kubernetes.io/is-default-class: "true"

Використовується для: StorageClass

Якщо один ресурс StorageClass має цю анотацію встановлену на значення "true", новий ресурс PersistentVolumeClaim без вказаного класу буде призначено цей стандартний клас.

alpha.kubernetes.io/provided-node-ip (alpha)

Тип: Annotation

Приклад: alpha.kubernetes.io/provided-node-ip: "10.0.0.1"

Використовується для: Node

Kubelet може встановити цю анотацію на вузлі, щоб вказати його налаштовану адресу IPv4 та/або IPv6.

Коли kubelet запускається з прапорцем --cloud-provider, встановленим на будь-яке значення (включає як зовнішні, так і застарілі постачальники хмарних служб у вбудованому коді), він встановлює цю анотацію на вузлі, щоб вказати IP-адресу, встановлену з командного рядка за допомогою прапорця --node-ip. Цей IP перевіряється постачальником хмарних послуг на дійсність за допомогою cloud-controller-manager.

batch.kubernetes.io/job-completion-index

Тип: Annotation, Label

Приклад: batch.kubernetes.io/job-completion-index: "3"

Використовується для: Pod

Контролер Job у kube-controller-manager встановлює це як мітку та анотацію для Podʼів, створених з режимом завершення Indexed.

Зверніть увагу, що для того, щоб це було додано як мітку Podʼа, необхідно увімкнути функціональну можливість PodIndexLabel, інакше це буде просто анотацією.

batch.kubernetes.io/cronjob-scheduled-timestamp

Тип: Annotation

Приклад: batch.kubernetes.io/cronjob-scheduled-timestamp: "2016-05-19T03:00:00-07:00"

Використовується для: Jobs and Pods controlled by CronJobs

Ця анотація використовується для запису оригінального (очікуваного) часу створення для завдання, коли це завдання є частиною CronJob. Панель управління встановлює значення цього часового позначення у форматі RFC3339. Якщо завдання належить до CronJob з вказаною часовою зоною, тоді мітка часу знаходиться в цій часовій зоні. В іншому випадку мітка часу відображається в локальному часі controller-manager.

kubectl.kubernetes.io/default-container

Тип: Annotation

Приклад: kubectl.kubernetes.io/default-container: "front-end-app"

Значення анотації — це імʼя контейнера, яке є типовим для цього Podʼа. Наприклад, команди kubectl logs або kubectl exec без прапорця -c або --container використовуватимуть цей типовий контейнер.

kubectl.kubernetes.io/default-logs-container (deprecated)

Тип: Annotation

Приклад: kubectl.kubernetes.io/default-logs-container: "front-end-app"

Значення анотації — це імʼя контейнера, яке є типовим для логування для цього Podʼа. Наприклад, команда kubectl logs без прапорця -c або --container використовуватиме цей типовий контейнер.

kubectl.kubernetes.io/last-applied-configuration

Тип: Annotation

Приклад: дивіться наступний код

kubectl.kubernetes.io/last-applied-configuration: >
  {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"example","namespace":"default"},"spec":{"selector":{"matchLabels":{"app.kubernetes.io/name":foo}},"template":{"metadata":{"labels":{"app.kubernetes.io/name":"foo"}},"spec":{"containers":[{"image":"container-registry.example/foo-bar:1.42","name":"foo-bar","ports":[{"containerPort":42}]}]}}}}

Використовується для: Всі обʼєкти

Командний рядок інструменту kubectl використовує цю анотацію як застарілий механізм для відстеження змін. Цей механізм був замінений на Server-Side Apply.

kubectl.kubernetes.io/restartedAt

Тип: Annotation

Приклад: kubectl.kubernetes.io/restartedAt: "2024-06-21T17:27:41Z"

Використовується для: Deployment, ReplicaSet, StatefulSet, DaemonSet, Pod

Ця анотація містить останній час перезапуску ресурсу (Deployment, ReplicaSet, StatefulSet або DaemonSet), під час якого kubectl запустив розгортання для примусового створення нових Podʼів. Команда kubectl rollout restart <RESOURCE> ініціює перезапуск шляхом виправлення шаблону метаданих усіх Podʼів ресурсу з цією анотацією. У наведеному вище прикладі останній час перезапуску показано як 21 червня 2024 року о 17:27:41 UTC.

Не слід вважати, що ця анотація відображає дату/час останнього оновлення; окремі зміни могли бути внесені з моменту останнього ручного розгортання.

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

endpoints.kubernetes.io/over-capacity

Тип: Annotation

Приклад: endpoints.kubernetes.io/over-capacity:truncated

Використовується для: Endpoints

Панель управління додає цю анотацію до обʼєкта Endpoints, якщо повʼязаний Service має більше 1000 резервних точок доступу. Анотація вказує на те, що обʼєкт Endpoints перевищив потужність, і кількість точок доступу була скорочена до 1000.

Якщо кількість резервних точок доступу опускається нижче 1000, то панель управління видаляє цю анотацію.

endpoints.kubernetes.io/last-change-trigger-time

Тип: Annotation

Приклад: endpoints.kubernetes.io/last-change-trigger-time: "2023-07-20T04:45:21Z"

Використовується для: Endpoints

Ця анотація встановлює обʼєкт Endpoints, який представляє мітку часу (Мітка часу зберігається у форматі дата-часового рядка RFC 3339. Наприклад, '2018-10-22T19:32:52.1Z'). Це позначка часу останньої зміни в деякому обʼєкті Pod або Service, яка спричинила зміну в обʼєкті Endpoints.

control-plane.alpha.kubernetes.io/leader (deprecated)

Тип: Annotation

Приклад: control-plane.alpha.kubernetes.io/leader={"holderIdentity":"controller-0","leaseDurationSeconds":15,"acquireTime":"2023-01-19T13:12:57Z","renewTime":"2023-01-19T13:13:54Z","leaderTransitions":1}

Використовується для: 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

controller-uid (deprecated)

Тип: Label

Приклад: controller-uid: "$UID"

Використовується для: Jobs та Pods, що керуються через Jobs

batch.kubernetes.io/job-name

Тип: Label

Приклад: batch.kubernetes.io/job-name: "pi"

Використовується для: Jobs та Pods, що керуються через Jobs

Ця мітка використовується як зручний спосіб для отримання Podʼів, що належать Job. Мітка job-name походить від імені Job і надає простий спосіб отримати Podʼи, що належать Job.

batch.kubernetes.io/controller-uid

Тип: Label

Приклад: batch.kubernetes.io/controller-uid: "$UID"

Використовується для: Jobs та Pods, що керуються через Jobs

Ця мітка використовується як програмний спосіб отримати всі Podʼи, що належать Job. controller-uid є унікальним ідентифікатором, який встановлюється в поле selector, щоб контролер Job міг отримати всі відповідні Podʼи.

scheduler.alpha.kubernetes.io/defaultTolerations

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Equal", "value": "value1", "effect": "NoSchedule", "key": "dedicated-node"}]'

Використовується для: Namespace

Ця анотація вимагає активування контролера допуску PodTolerationRestriction. Ключ цієї анотації дозволяє призначати толерантності для простору імен, і будь-які нові створені в цьому просторі імен Podʼи отримають ці толерантності.

scheduler.alpha.kubernetes.io/tolerationsWhitelist

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'

Використовується для: Namespace

Ця анотація корисна лише тоді, коли активований контролер допуску (Alpha) PodTolerationRestriction. Значення анотації — це JSON-документ, який визначає список допустимих толерантностей для простору імен, який анотується. Під час створення Pod або зміни його толерантностей, сервер API перевіряє толерантності, щоб переконатися, що вони згадуються у списку дозволених. Pod буде прийнятий лише у випадку успішної перевірки.

scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated)

Тип: Annotation

Використовується для: Node

Ця анотація вимагає активації втулка планування NodePreferAvoidPods. Однак цей втулок застарів починаючи з Kubernetes 1.22. Замість цього використовуйте Позначення та толерантності.

node.kubernetes.io/not-ready

Тип: Taint

Приклад: node.kubernetes.io/not-ready: "NoExecute"

Використовується для: Node

Контролер Node визначає, чи готовий Node, відстежуючи стан його справності, і відповідно додає або видаляє це позначення.

node.kubernetes.io/unreachable

Тип: Taint

Приклад: node.kubernetes.io/unreachable: "NoExecute"

Використовується для: Node

Контролер Node додає позначення на Node відповідно до NodeCondition Ready, якщо воно має значення Unknown.

node.kubernetes.io/unschedulable

Тип: Taint

Приклад: node.kubernetes.io/unschedulable: "NoSchedule"

Використовується для: Node

Позначення буде додано до вузла під час його ініціалізації, щоб уникнути стану перегонів.

node.kubernetes.io/memory-pressure

Тип: Taint

Приклад: node.kubernetes.io/memory-pressure: "NoSchedule"

Використовується для: Node

Kubelet виявляє тиск на памʼять на основі значень memory.available і allocatableMemory.available, спостережуваних на вузлі. Потім спостережені значення порівнюються з відповідними пороговими значеннями, які можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.

node.kubernetes.io/disk-pressure

Тип: Taint

Приклад: node.kubernetes.io/disk-pressure :"NoSchedule"

Використовується для: Node

Kubelet виявляє тиск на дискову памʼять на основі значень imagefs.available, imagefs.inodesFree, nodefs.available і nodefs.inodesFree (тільки для Linux), спостережуваних на вузлі. Потім спостережені значення порівнюються з відповідними пороговими значеннями, які можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.

node.kubernetes.io/network-unavailable

Тип: Taint

Приклад: node.kubernetes.io/network-unavailable: "NoSchedule"

Використовується для: Node

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

node.kubernetes.io/pid-pressure

Тип: Taint

Приклад: node.kubernetes.io/pid-pressure: "NoSchedule"

Використовується для: Node

Kubelet перевіряє D-значення розміру /proc/sys/kernel/pid_max та PID, використані Kubernetes на вузлі, щоб отримати кількість доступних PID, які вказуються метрикою pid.available. Потім цю метрику порівнюють з відповідним пороговим значенням, яке можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.

node.kubernetes.io/out-of-service

Тип: Taint

Приклад: node.kubernetes.io/out-of-service:NoExecute

Використовується для: Node

Користувач може вручну додати позначення на вузол, відмітивши його як такий що вийшов з ладу. Якщо у kube-controller-manager увімкнути функціональну можливість NodeOutOfServiceVolumeDetach, і вузол позначений як такий, що вийшов з ладу з цим позначенням, то при відсутності відповідних толерантностей на ньому, Podʼи на вузлі будуть примусово видалені, і операції відʼєднання томів для Podʼів, які завершуються на вузлі, відбудуться негайно. Це дозволяє Podʼам, що є в стані виходу з ладу на одному вузлі швидко відновитися на іншому вузлі.

node.cloudprovider.kubernetes.io/uninitialized

Тип: Taint

Приклад: node.cloudprovider.kubernetes.io/uninitialized: "NoSchedule"

Використовується для: Node

Встановлює цю позначку на вузлі, щоб позначити його як непридатний для використання, коли kubelet запускається з "зовнішнім" хмарним постачальником, доки контролер з cloud-controller-manager ініціалізує цей вузол, а потім видаляє позначку.

node.cloudprovider.kubernetes.io/shutdown

Тип: Taint

Приклад: node.cloudprovider.kubernetes.io/shutdown: "NoSchedule"

Використовується для: Node

Якщо вузол перебуває у визначеному хмарним постачальником стані вимкнення, вузол отримує відповідну позначку з node.cloudprovider.kubernetes.io/shutdown і ефект позначки NoSchedule.

feature.node.kubernetes.io/*

Тип: Label

Приклад: feature.node.kubernetes.io/network-sriov.capable: "true"

Використовується для: Node

Ці мітки використовуються компонентом виявлення функцій вузла (NFD), щоб оголошувати функції на вузлі. Усі вбудовані мітки використовують простір імен мітки feature.node.kubernetes.io та мають формат feature.node.kubernetes.io/<назва-функції>: "true". NFD має багато точок розширення для створення міток, специфічних для постачальника або застосунку. Для отримання детальної інформації дивіться посібник з налаштування.

nfd.node.kubernetes.io/master.version

Тип: Annotation

Приклад: nfd.node.kubernetes.io/master.version: "v0.6.0"

Використовується для: Node

Для вузлів, на яких заплановано master виявлення функцій вузла (NFD) , ця анотація записує версію майстра NFD. Вона використовується лише для інформаційних цілей.

nfd.node.kubernetes.io/worker.version

Тип: Annotation

Приклад: nfd.node.kubernetes.io/worker.version: "v0.4.0"

Використовується для: Nodes

Антоація записує версію робочого процесу виявлення функцій вузла (NFD), якщо він працює на вузлі. Вона використовується лише для інформаційних цілей.

nfd.node.kubernetes.io/feature-labels

Тип: Annotation

Приклад: nfd.node.kubernetes.io/feature-labels: "cpu-cpuid.ADX,cpu-cpuid.AESNI,cpu-hardware_multithreading,kernel-version.full"

Використовується для: Nodes

Ця анотація записує список міток функцій вузла, розділених комами, керованих виявленням функцій вузла (NFD). NFD використовує це для внутрішнього механізму. Ви не повинні редагувати цю анотацію самостійно.

nfd.node.kubernetes.io/extended-resources

Тип: Annotation

Приклад: nfd.node.kubernetes.io/extended-resources: "accelerator.acme.example/q500,example.com/coprocessor-fx5"

Використовується для: Nodes

Ця анотація зберігає розділені комами список розширених ресурсів, керованих виявленням функцій вузла (NFD). NFD використовує це для внутрішнього механізму. Ви не повинні редагувати цю анотацію самостійно.

nfd.node.kubernetes.io/node-name

Тип: Label

Приклад: nfd.node.kubernetes.io/node-name: node-1

Використовується для: Nodes

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

service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "5"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Значення визначає, як часто балансувальник навантаження записує записи логу. Наприклад, якщо ви встановите значення на 5, записи логу будуть відбуватися з інтервалом у 5 секунд.

service.beta.kubernetes.io/aws-load-balancer-access-log-enabled (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "false"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Ведення логу доступу активується, якщо ви встановите анотацію на значення "true".

service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: example

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Балансувальник навантаження записує логи до корзини S3 з іменем, яке ви вказуєте.

service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "/example"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Балансувальник навантаження записує обʼєкти журналів з префіксом, який ви вказуєте.

service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "Environment=demo,Project=example"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує теґи (концепція AWS) для балансувальника навантаження на основі розділених комами пар ключ/значення у значенні цієї анотації.

service.beta.kubernetes.io/aws-load-balancer-alpn-policy (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-alpn-policy: HTTP2Optional

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-attributes (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-attributes: "deletion_protection.enabled=true"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Для отримання додаткової інформації дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-backend-protocol (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує прослуховувач балансувальника навантаження на основі значення цієї анотації.

service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "false"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Налаштування затримки зʼєднання балансувальника навантаження залежить від значення, яке ви встановлюєте.

service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60"

Використовується для: Service

Якщо ви налаштовуєте затримку зʼєднання для Service з type: LoadBalancer, і ви використовуєте хмару AWS, інтеграція налаштовує період затримки на основі цієї анотації. Значення, яке ви встановлюєте, визначає тайм-аут затримки у секундах.

service.beta.kubernetes.io/aws-load-balancer-ip-address-type (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ip-address-type: ipv4

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Балансувальник має налаштований період тайм-ауту бездіяльності (у секундах), який застосовується до його зʼєднань. Якщо протягом періоду тайм-ауту бездіяльності не було відправлено або отримано жодних даних, балансувальник закриває зʼєднання.

service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Якщо ви встановите цю анотацію в значення "true", кожен вузол балансувальника навантаження розподіляє запити рівномірно серед зареєстрованих цілей у всіх увімкнених зонах доступності. Якщо ви вимкнете перехресне балансування зон, кожен вузол балансувальника навантаження розподіляє запити рівномірно серед зареєстрованих цілей лише у своїй зоні доступності.

service.beta.kubernetes.io/aws-load-balancer-eip-allocations (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-eip-allocations: "eipalloc-01bcdef23bcdef456,eipalloc-def1234abc4567890"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення є розділеним комами списком ідентифікаторів виділення еластичних IP-адрес.

Ця анотація має сенс тільки для Service з type: LoadBalancer, де балансувальник навантаження є мережевим балансувальником AWS.

service.beta.kubernetes.io/aws-load-balancer-extra-security-groups (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-12abcd3456,sg-34dcba6543"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації є розділеним комами списком додаткових груп безпеки AWS VPC для налаштування балансувальника навантаження.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "3"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає кількість послідовних успішних перевірок стану для бекенду, щоб вважати його справним для передавання трафіку.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "30"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає інтервал, в секундах, між запитами перевірки стану, які виконує балансувальник навантаження.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /healthcheck

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає частину шляху URL, яка використовується для HTTP перевірок стану.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-port (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "24"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає порт, до якого підключається балансувальник навантаження під час виконання перевірок стану.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає спосіб, яким балансувальник навантаження перевіряє стан бекендів.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "3"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації вказує кількість секунд до того, як запит, який ще не вдався, автоматично вважається неуспішним.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає кількість послідовних невдалих перевірок стану, необхідних для того, щоб бекенд вважася несправним для передачі трафіку.

service.beta.kubernetes.io/aws-load-balancer-internal (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-internal: "true"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Коли ви встановлюєте цю анотацію у значення "true", інтеграція налаштовує внутрішній балансувальник навантаження.

Якщо ви використовуєте контролер балансувальника навантаження AWS, дивіться service.beta.kubernetes.io/aws-load-balancer-scheme.

service.beta.kubernetes.io/aws-load-balancer-manage-backend-security-group-rules (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-manage-backend-security-group-rules: "true"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-name (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-name: my-elb

Використовується для: Service

Якщо ви встановлюєте цю анотацію на Service, і також анотуєте цей Service з service.beta.kubernetes.io/aws-load-balancer-type: "external", і ви використовуєте контролер балансувальника навантаження AWS у вашому кластері, тоді контролер балансувальника навантаження AWS встановлює назву цього балансувальника на значення, яке ви встановлюєте для цієї анотації.

Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-nlb-target-type (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "true"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses: "198.51.100.0,198.51.100.64"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-proxy-protocol (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"

Використовується для: Service

Офіційна інтеграція Kubernetes з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Єдине допустиме значення — "*", що вказує на те, що балансувальник навантаження повинен обгортати TCP-зʼєднання до бекенду Pod за допомогою протоколу PROXY.

service.beta.kubernetes.io/aws-load-balancer-scheme (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-scheme: internal

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-security-groups (deprecated)

Приклад: service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f,sg-8725gr62r"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію для вказівки розділеного комами списку груп безпеки, які ви хочете прикріпити до балансувальника навантаження AWS. Підтримуються як імʼя, так і ID груп безпеки, де імʼя відповідає тегу Name, а не атрибуту groupName.

Коли ця анотація додається до Service, контролер балансувальника навантаження прикріплює групи безпеки, на які вказує анотація, до балансувальника навантаження. Якщо ви пропускаєте цю анотацію, контролер балансувальника навантаження AWS автоматично створює нову групу безпеки і прикріплює її до балансувальника навантаження.

service.beta.kubernetes.io/load-balancer-source-ranges (deprecated)

Приклад: service.beta.kubernetes.io/load-balancer-source-ranges: "192.0.2.0/25"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Вам слід встановити .spec.loadBalancerSourceRanges для Service замість цього.

service.beta.kubernetes.io/aws-load-balancer-ssl-cert (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012"

Використовується для: Service

Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації — це імʼя ресурсу AWS (ARN) сертифіката X.509, який повинен використовувати прослуховувач балансувальника навантаження.

(Протокол TLS базується на старій технології, яка скорочується до SSL.)

service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: ELBSecurityPolicy-TLS-1-2-2017-01

Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації — це імʼя політики AWS для взаємодії TLS з клієнтом.

service.beta.kubernetes.io/aws-load-balancer-ssl-ports (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "*"

Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації може бути або "*", що означає, що всі порти балансувальника навантаження повинні використовувати TLS, або це може бути розділений комами список номерів портів.

service.beta.kubernetes.io/aws-load-balancer-subnets (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-subnets: "private-a,private-b"

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

service.beta.kubernetes.io/aws-load-balancer-target-group-attributes (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: "stickiness.enabled=true,stickiness.type=source_ip"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-target-node-labels (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "kubernetes.io/os=Linux,topology.kubernetes.io/region=us-east-2"

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

service.beta.kubernetes.io/aws-load-balancer-type (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-type: external

Офіційні інтеграції 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/azure-load-balancer-disable-tcp-reset (deprecated)

Приклад: service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset: "false"

Використовується для: Service

Ця анотація працює лише для Service, підтримуваних стандартним балансувальником навантаження Azure. Вона використовується у Service для вказівки, чи слід вимикати або вмикати скидання TCP при бездіяльності. Якщо увімкнено, це допомагає застосункам працювати більш передбачувано, виявляти обриви зʼєднання, видаляти застарілі зʼєднання та ініціювати нові. Ви можете встановити значення як true або false.

Дивіться Скидання TCP балансувальника навантаження для отримання додаткової інформації.

pod-security.kubernetes.io/enforce

Тип: Label

Приклад: pod-security.kubernetes.io/enforce: "baseline"

Використовується для: Namespace

Значення обовʼязково повинно бути одним із privileged, baseline або restricted, що відповідає рівням стандарту безпеки для Podʼів. Зокрема, мітка enforce забороняє створення будь-якого Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні.

Для отримання додаткової інформації перегляньте Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/enforce-version

Тип: Label

Приклад: pod-security.kubernetes.io/enforce-version: "1.31"

Використовується для: Namespace

Значення має бути latest або дійсна версія Kubernetes у форматі v<major>.<minor>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються при перевірці Podʼа.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/audit

Тип: Label

Приклад: pod-security.kubernetes.io/audit: "baseline"

Використовується для: Namespace

Значення має бути одним із privileged, baseline або restricted, що відповідають рівням стандарту безпеки для Podʼів. Зокрема, мітка audit не перешкоджає створенню Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні, але додає цю анотацію до Podʼа.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/audit-version

Тип: Label

Приклад: pod-security.kubernetes.io/audit-version: "1.31"

Використовується для: Namespace

Значення повинно бути latest або дійсна версія Kubernetes у форматі v<major>.<minor>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються під час перевірки Podʼа.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/warn

Тип: Label

Приклад: pod-security.kubernetes.io/warn: "baseline"

Використовується для: Namespace

Значення має бути одним із privileged, baseline або restricted, що відповідають рівням стандарту безпеки для Podʼів. Зокрема, мітка warn не перешкоджає створенню Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні, але повертає попередження користувачу після цього.

Зверніть увагу, що попередження також відображаються при створенні або оновленні обʼєктів, які містять шаблони Podʼа, такі як Deployments, Jobs, StatefulSets тощо.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/warn-version

Тип: Label

Приклад: pod-security.kubernetes.io/warn-version: "1.31"

Використовується для: Namespace

Значення повинно бути latest або дійсна версія Kubernetes у форматі v<основний>.<додатковий>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються при перевірці поданих Podʼів. Зверніть увагу, що попередження також відображаються при створенні або оновленні обʼєктів, які містять шаблони Podʼа, такі як Deployments, Jobs, StatefulSets тощо.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

rbac.authorization.kubernetes.io/autoupdate

Тип: Annotation

Приклад: rbac.authorization.kubernetes.io/autoupdate: "false"

Використовується для: 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.31 не підтримує API PodSecurityPolicy.

Коли контролер допуску PodSecurityPolicy дав дозвіл Podʼу, він модифікував Pod так, щоб мати цю анотацію. Значення анотації було імʼям PodSecurityPolicy, яке використовувалось для валідації.

seccomp.security.alpha.kubernetes.io/pod (non-functional)

Тип: Annotation

Використовується для: Pod

Кубернетес до версії 1.25 дозволяв вам налаштовувати поведінку seccomp за допомогою цієї анотації. Див. Обмеження системних викликів контейнера за допомогою seccomp, щоб дізнатися, як вказувати обмеження seccomp для Pod.

container.seccomp.security.alpha.kubernetes.io/[NAME] (non-functional)

Тип: Annotation

Використовується для: Pod

До версії 1.25 Kubernetes дозволяв налаштовувати поведінку seccomp за допомогою цієї анотації. Дивіться Обмеження системних викликів контейнера за допомогою seccomp, щоб дізнатися підтримуваний спосіб вказування обмежень seccomp для Pod.

snapshot.storage.kubernetes.io/allow-volume-mode-change

Тип: Annotation

Приклад: snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"

Використовується для: VolumeSnapshotContent

Значення може бути або true, або false. Це визначає, чи може користувач змінювати режим джерельного тому при створенні PersistentVolumeClaim із VolumeSnapshot.

Зверніться до Зміна режиму тому знімка та Документації розробника Kubernetes CSI для отримання додаткової інформації.

scheduler.alpha.kubernetes.io/critical-pod (deprecated)

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/critical-pod: ""

Використовується для: Pod

Ця анотація повідомляє панель управління Kubernetes, що Pod є критичним, щоб descheduler не видаляв цей Pod.

Анотації, що використовуються для аудиту

Дивіться більше деталей на сторінці Анотації аудиту.

kubeadm

kubeadm.alpha.kubernetes.io/cri-socket

Тип: Annotation

Приклад: kubeadm.alpha.kubernetes.io/cri-socket: unix:///run/containerd/container.sock

Використовується для: Node

Анотація, яку kubeadm використовує для збереження інформації про сокет CRI, наданої kubeadm під час init/join для подальшого використання. kubeadm додає цю інформацію як анотацію до обʼєкта Node. Ця анотація залишається "альфа", оскільки в ідеалі це має бути поле в KubeletConfiguration.

kubeadm.kubernetes.io/etcd.advertise-client-urls

Тип: Annotation

Приклад: kubeadm.kubernetes.io/etcd.advertise-client-urls: https://172.17.0.18:2379

Використовується для: Pod

Анотація, яку kubeadm додає до локально керованих Podʼів etcd для відстеження списку URL-адрес, до яких повинні підключатися клієнти etcd. Це використовується головним чином для перевірки стану справності кластера etcd.

kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint

Тип: Annotation

Приклад: kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https://172.17.0.18:6443

Використовується для: Pod

Анотація, яку kubeadm додає до локально керованих Podʼів kube-apiserver для відстеження оголошеної адреси/порту для цього екземпляра API-сервера.

kubeadm.kubernetes.io/component-config.hash

Тип: Annotation

Приклад: kubeadm.kubernetes.io/component-config.hash: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

Використовується для: ConfigMap

Анотація, яку kubeadm додає до ConfigMapʼів, що ним керуються для налаштування компонентів. Вона містить хеш (SHA-256), який використовується для визначення, чи застосував користувач налаштування, відмінні від стандартних налаштувань для конкретного компонента.

node-role.kubernetes.io/control-plane

Тип: Label

Використовується для: Node

Мітка-маркер, що вказує, що вузол використовується для запуску компонентів панелі управління. Інструмент kubeadm застосовує цю мітку до вузлів панелі управління, якими він керує. Інші інструменти управління кластером зазвичай також встановлюють це позачення.

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

node-role.kubernetes.io/control-plane

Тип: Taint

Приклад: node-role.kubernetes.io/control-plane:NoSchedule

Використовується для: Node

Позначення, що kubeadm накладає на вузли панелі управління для обмеження розміщення Podʼів і дозволяє розміщувати на них лише певні Podʼи.

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

kubectl taint nodes <node-name> node-role.kubernetes.io/control-plane:NoSchedule-

node-role.kubernetes.io/master (deprecated)

Тип: Taint

Використовується для: Node

Приклад: node-role.kubernetes.io/master:NoSchedule

Позначення, що раніше kubeadm застосовував на вузли панелі управління, щоб дозволити розміщувати на них лише критичні навантаження. Замінений позначенням node-role.kubernetes.io/control-plane. kubeadm більше не встановлює або не використовує це застаріле позначення.

4.1 - Анотації аудиту

Ця сторінка служить довідником по анотаціях аудиту простору імен kubernetes.io. Ці анотації застосовуються до обʼєктів Event з API-групи audit.k8s.io.

k8s.io/deprecated

Приклад: k8s.io/deprecated: "true"

Значення повинно бути "true" або "false". Значення "true" вказує на те, що в запит використовував застарілу версію API.

k8s.io/removed-release

Приклад: k8s.io/removed-release: "1.22"

Значення повинно бути у форматі ".". Встановлюється на цільовий випуск видалення на запити до застарілих версій API з цільовим випуском видалення.

pod-security.kubernetes.io/exempt

Приклад: pod-security.kubernetes.io/exempt: namespace

Значення повинно бути одним із user, namespace або runtimeClass, що відповідає вимогам виключень безпеки Pod. Ця анотація вказує на те, на чому засновано виключення з дотримання безпеки Pod.

pod-security.kubernetes.io/enforce-policy

Приклад: pod-security.kubernetes.io/enforce-policy: restricted:latest

Значення повинно бути privileged:<version>, baseline:<version>, restricted:<version>, що відповідає рівням стандарту безпеки Pod, супроводжуваних версією, яка повинна бути latest або дійсною версією Kubernetes у форматі v<MAJOR>.<MINOR>. Ця анотація надає інформацію про рівень виконання, який дозволив або відхилив Pod під час допуску PodSecurity.

Див. Стандарти безпеки Pod для отримання додаткової інформації.

pod-security.kubernetes.io/audit-violations

Приклад: pod-security.kubernetes.io/audit-violations: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), ...

Значення деталізує порушення аудиту політики, воно містить рівень стандарту безпеки Pod, який був порушений, а також конкретні політики з полів, які були порушені з дотримання безпеки Pod.

Див. Стандарти безпеки Pod для отримання додаткової інформації.

authorization.k8s.io/decision

Приклад: authorization.k8s.io/decision: "forbid"

Значення має бути forbid або allow. Ця анотація вказує на те, чи було дозволено запит у логах аудиту Kubernetes.

Див. Аудит для отримання додаткової інформації.

authorization.k8s.io/reason

Приклад: authorization.k8s.io/reason: "Людиночитана причина рішення"

Ця анотація вказує причину для рішення в логах аудиту Kubernetes.

Див. Аудит для отримання додаткової інформації.

missing-san.invalid-cert.kubernetes.io/$hostname

Приклад: 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+.

Додаткову інформацію можна знайти в документації Go: Відключення загального імені X.509.

insecure-sha1.invalid-cert.kubernetes.io/$hostname

Приклад: insecure-sha1.invalid-cert.kubernetes.io/example-svc.example-namespace.svc: "використовує небезпечний підпис SHA-1"

Використовується у Kubernetes версії v1.24 та пізніше.

Ця анотація вказує, що вебхук або агрегований API-сервер використовує недійсний сертифікат, підписаний небезпечним хешем SHA-1. Підтримка цих небезпечних сертифікатів відключена у Kubernetes 1.24 та буде видалена в майбутніх версіях.

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

Додаткову інформацію можна знайти в документації Go: Відхилення сертифікатів SHA-1.

validation.policy.admission.k8s.io/validation_failure

Приклад: validation.policy.admission.k8s.io/validation_failure: '[{"message": "Недійсне значення", {"policy": "policy.example.com", {"binding": "policybinding.example.com", {"expressionIndex": "1", {"validationActions": ["Audit"]}]'

Використовується у 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 є колекцією контейнерів, які можуть працювати на одному хості. Цей ресурс створюється клієнтами та розміщується на хостах.

PodSpec

PodSpec — це опис Pod.

Контейнери

  • containers ([]Container), обовʼязково

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список контейнерів, що належать Podʼу. Зараз контейнери не можуть бути додані або видалені. В Podʼі повинен бути принаймні один контейнер. Не може бути оновлено.

  • initContainers ([]Container)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список контейнерів ініціалізації, що належать Podʼу. Контейнери ініціалізації виконуються у визначеному порядку перед запуском звичайних контейнерів. Якщо будь-який контейнер ініціалізації зазнає збою, Pod вважається збійним та обробляється відповідно до restartPolicy. Імʼя контейнера ініціалізації або звичайного контейнера повинно бути унікальним серед усіх контейнерів. Контейнери ініціалізації не можуть мати дій Lifecycle, Readiness probes, Liveness probes, або Startup probes. resourceRequirements контейнера ініціалізації враховуються під час планування, знаходячи найбільше значення запиту/ліміту для кожного типу ресурсів, а потім використовуючи максимум цього значення або суму цих значень для звичайних контейнерів. Ліміти застосовуються до контейнерів ініціалізації аналогічним чином. Контейнери ініціалізації зараз не можуть бути додані або видалені. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

  • ephemeralContainers ([]EphemeralContainer)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список ефемерних контейнерів, що запущені у цьому Pod. Ефемерні контейнери можуть бути запущені в наявному Podʼі для виконання дій, ініційованих користувачем, таких як налагодження. Цей список не може бути вказаний при створенні Podʼа, і його не можна змінити, оновивши специфікацію Podʼа. Щоб додати ефемерний контейнер до наявного Podʼа, використовуйте субресурс ефемерних контейнерів Podʼа.

  • imagePullSecrets ([]LocalObjectReference)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    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, наступні поля не повинні бути встановлені:

    • spec.hostPID
    • spec.hostIPC
    • spec.hostUsers
    • spec.securityContext.appArmorProfile
    • spec.securityContext.seLinuxOptions
    • spec.securityContext.seccompProfile
    • spec.securityContext.fsGroup
    • spec.securityContext.fsGroupChangePolicy
    • spec.securityContext.sysctls
    • spec.shareProcessNamespace
    • spec.securityContext.runAsUser
    • spec.securityContext.runAsGroup
    • spec.securityContext.supplementalGroups
    • spec.securityContext.supplementalGroupsPolicy
    • spec.containers[*].securityContext.appArmorProfile
    • spec.containers[*].securityContext.seLinuxOptions
    • spec.containers[*].securityContext.seccompProfile
    • spec.containers[*].securityContext.capabilities
    • spec.containers[*].securityContext.readOnlyRootFilesystem
    • spec.containers[*].securityContext.privileged
    • spec.containers[*].securityContext.allowPrivilegeEscalation
    • spec.containers[*].securityContext.procMount
    • spec.containers[*].securityContext.runAsUser
    • spec.containers[*].securityContext.runAsGroup

    PodOS визначає параметри операційної системи Pod.

    • os.name (string), обовʼязково

      Name — це назва операційної системи. Поточні підтримувані значення — linux і windows. Додаткове значення може бути визначено у майбутньому і може бути одним з: https://github.com/opencontainers/runtime-spec/blob/master/config.md#platform-specific-configuration. Клієнти повинні очікувати обробку додаткових значень і розглядати нерозпізнані значення у цьому полі як os: null.

Томи

  • volumes ([]Volume)

    Patch strategies: retainKeys, обʼєднання по ключу name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список томів, які можуть бути змонтовані контейнерами, що належать Podʼу. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes

Планування

  • nodeSelector (map[string]string)

    NodeSelector — це селектор, який має бути істинним, щоб Pod підходив для вузла. Селектор, який має відповідати міткам вузла для планування Podʼа на цьому вузлі. Докладніше: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

  • nodeName (string)

    Поле NodeName вказує, на якому вузлі (node) заплановано запуск цього podʼа. Якщо це поле порожнє, pod є кандидатом для планування за допомогою планувальника, визначеного в полі schedulerName. Після того як це поле встановлено, kubelet цього вузла стає відповідальним за життєвий цикл podʼа. Це поле не слід використовувати для вираження бажання запустити pod на конкретному вузлі. Детальніше: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodename

  • affinity (Affinity)

    Якщо вказано, це обмеження на планування Podʼа.

    Affinity — це група правил планування з урахуванням спорідненості.

    • affinity.nodeAffinity (NodeAffinity)

      Описує правила планування Podʼа з урахуванням спорідненості до вузла.

    • affinity.podAffinity (PodAffinity)

      Описує правила планування Podʼа з урахуванням спорідненості до інших Podʼів (наприклад, розташувати цей Pod на тому ж вузлі, у тій же зоні тощо, що й інші Podʼи).

    • affinity.podAntiAffinity (PodAntiAffinity)

      Описує правила планування Podʼа з урахуванням анти-спорідненості до інших Podʼів (наприклад, уникати розташування цього Podʼа на тому ж вузлі, у тій же зоні тощо, що й інші Podʼи).

  • tolerations ([]Toleration)

    Atomic: буде замінено під час злиття

    Якщо вказано, визначає толерантності 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, якщо не встановлено.

  • topologySpreadConstraints ([]TopologySpreadConstraint)

    Patch strategy: об’єднання за ключем topologyKey

    Map: під час об’єднання будуть збережені унікальні значення за ключами topologyKey, whenUnsatisfiable

    TopologySpreadConstraints описує, як група Podʼів повинна розподілятися по топологічних доменах. Планувальник розміщуватиме Podʼи таким чином, щоб дотримуватися обмежень. Всі topologySpreadConstraints поєднуються логічним оператором AND.

    TopologySpreadConstraint визначає, як розподіляти відповідні Podʼи серед заданої топології.

    • topologySpreadConstraints.maxSkew (int32), обовʼязково

      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 не допускається.

    • topologySpreadConstraints.topologyKey (string), обовʼязково

      TopologyKey — це ключ міток вузлів. Вузли, які мають мітку з цим ключем та ідентичними значеннями, вважаються такими, що належать до однієї топології. Ми розглядаємо кожен <key, value> як "кошик" і намагаємося розмістити збалансовану кількість Podʼів у кожному кошику. Ми визначаємо домен як конкретний екземпляр топології. Також ми визначаємо відповідний домен як домен, чиї вузли відповідають вимогам nodeAffinityPolicy та nodeTaintsPolicy. Наприклад, якщо TopologyKey — це "kubernetes.io/hostname", кожен вузол є доменом цієї топології. І, якщо TopologyKey — це "topology.kubernetes.io/zone", кожна зона є доменом цієї топології. Це обовʼязкове поле.

    • topologySpreadConstraints.whenUnsatisfiable (string), обовʼязково

      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). Іншими словами, кластер все ще може бути незбалансованим, але планувальник не зробить його більш незбалансованим. Це обовʼязкове поле.

    • topologySpreadConstraints.labelSelector (LabelSelector)

      LabelSelector використовується для знаходження відповідних Podʼів. Podʼи, які відповідають цьому label selector, враховуються для визначення кількості Podʼів у відповідному топологічному домені.

    • topologySpreadConstraints.matchLabelKeys ([]string)

      Atomic: буде замінено під час об’єднання

      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.

    • topologySpreadConstraints.nodeAffinityPolicy (string)

      NodeAffinityPolicy вказує, як ми будемо враховувати nodeAffinity/nodeSelector Podʼа при розрахунку перекосу розподілу топології Pod. Варіанти:

      • Honor: тільки вузли, що відповідають nodeAffinity/nodeSelector, включаються до розрахунків.
      • Ignore: nodeAffinity/nodeSelector ігноруються. Всі вузли включаються до розрахунків.

      Якщо це значення дорівнює null, поведінка еквівалентна полю Honor. Це функція на рівні бета, типово увімкнена за допомогою прапорця NodeInclusionPolicyInPodTopologySpread.

    • topologySpreadConstraints.nodeTaintsPolicy (string)

      NodeTaintsPolicy вказує, як ми будемо враховувати node taints при розрахунку перекосу розподілу топології Pod. Варіанти:

      • Honor: вузли без taints, разом з вузлами з taints, для яких вхідний Pod має толерантність, включаються.
      • Ignore: node taints ігноруються. Всі вузли включаються.

      Якщо це значення дорівнює null, поведінка еквівалентна полю Ignore. Це функція на рівні бета, типово увімкнена за допомогою прапорця NodeInclusionPolicyInPodTopologySpread.

  • overhead (map[string]Quantity)

    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

Життєвий цикл

  • restartPolicy (string)

    Політика перезапуску для всіх контейнерів у Podʼі. Одне з Always, OnFailure, Never. В деяких контекстах може бути дозволений лише субнабір цих значень. Стандартне значення — Always. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

  • terminationGracePeriodSeconds (int64)

    Необовʼязкова тривалість у секундах, необхідна для коректного завершення роботи Podʼа. Може бути зменшена у запиті на видалення. Значення повинно бути невідʼємним цілим числом. Значення нуль означає негайне припинення через сигнал kill (без можливості завершити роботу коректно). Якщо це значення є nil, буде використано стандартний період завершення. Період належного завершення — це тривалість у секундах після того, як процеси, що працюють у Podʼі, отримають сигнал про завершення, і до того, як вони будуть примусово зупинені сигналом kill. Встановіть це значення більше, ніж очікуваний час завершення вашого процесу. Стандартне значення — 30 секунд.

  • activeDeadlineSeconds (int64)

    Необовʼязкова тривалість у секундах, протягом якої Pod може бути активним на вузлі відносно StartTime, перш ніж система почне активно намагатися позначити його як несправний та припинити роботу повʼязаних контейнерів. Значення повинно бути додатним цілим числом.

  • readinessGates ([]PodReadinessGate)

    Atomic: буде замінено під час злиття

    Якщо вказано, всі readiness gates будуть оцінюватися для готовності Podʼа. Pod вважається готовим, коли всі його контейнери готові І всі умови, зазначені в readiness gates, мають статус "True". Докладніше: https://git.k8s.io/enhancements/keps/sig-network/580-pod-readiness-gates

    PodReadinessGate містить посилання на стан Podʼа

    • readinessGates.conditionType (string), обовʼязково

      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

    Map: унікальні значення ключа ip будуть збережені під час злиття

    HostAliases є необовʼязковим списком хостів та IP, які будуть впроваджені у файл hosts Podʼа, якщо вказано.

    HostAlias містить зітсавлення між IP та іменами хостів, які будуть впроваджені як запис у файл hosts Podʼа.

    • hostAliases.ip (string), обовʼязково

      Запис IP-адреси у файлі hosts.

    • hostAliases.hostnames ([]string)

      Atomic: буде замінено під час злиття

      Імена хостів для вищевказаної IP-адреси.

  • dnsConfig (PodDNSConfig)

    Вказує параметри DNS Podʼа. Параметри, вказані тут, будуть обʼєднані зі згенерованою DNS-конфігурацією на основі DNSPolicy.

    PodDNSConfig визначає параметри DNS Podʼа на додаток до тих, що генеруються з DNSPolicy.

    • dnsConfig.nameservers ([]string)

      Atomic: буде замінено під час злиття

      Список IP-адрес DNS-серверів імен. Він буде доданий до основних серверів імен, згенерованих з DNSPolicy. Дубльовані сервери імен будуть видалені.

    • dnsConfig.options ([]PodDNSConfigOption)

      Atomic: буде замінено під час злиття

      Список опцій DNS-резолвера. Він буде обʼєднаний з основними опціями, згенерованими з DNSPolicy. Дубльовані записи будуть видалені. Опції розвʼязування імен, зазначені в Options, замінять ті, що зʼявляються в основній DNSPolicy.

      PodDNSConfigOption визначає опції DNS-резольвера Podʼа.

      • dnsConfig.options.name (string)

        Обовʼязкове.

      • dnsConfig.options.value (string)

    • dnsConfig.searches ([]string)

      Atomic: буде замінено під час злиття

      Список доменів пошуку 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.

Службовий обліковий запис

  • serviceAccountName (string)

    ServiceAccountName — це імʼя службового облікового запису, який використовується для запуску цього Podʼа. Детальніше: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

  • automountServiceAccountToken (boolean)

    AutomountServiceAccountToken вказує, чи повинен токен службового облікового запису автоматично монтуватися.

Контекст безпеки

  • securityContext (PodSecurityContext)

    SecurityContext містить атрибути безпеки на рівні Podʼа та загальні налаштування контейнера. Необовʼязково: стандартне значення — порожньо. Див. опис типу для стандартних значень для кожного поля.

    PodSecurityContext містить атрибути безпеки на рівні Podʼа та загальні налаштування контейнера. Деякі поля також присутні у container.securityContext. Значення полів container.securityContext мають пріоритет над значеннями полів PodSecurityContext.

    • securityContext.appArmorProfile (AppArmorProfile)

      appArmorProfile — параметри AppArmor, які будуть використовуватися контейнерами у цьому pod'і. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      AppArmorProfile визначає налаштування AppArmor для контейнера або podʼа.

      • securityContext.appArmorProfile.type (string), обовʼязково

        Поле type вказує, який тип профілю AppArmor буде застосовано. Дійсні варіанти:

        • Localhost — профіль, попередньо завантажений на вузлі.
        • RuntimeDefault — стандартний профіль середовища виконання контейнрів.
        • Unconfined — без примусового виконання правил AppArmor.

      • securityContext.appArmorProfile.localhostProfile (string)

        localhostProfile вказує профіль, завантажений на вузлі, який слід використовувати. Профіль має бути попередньо налаштований на вузлі для коректної роботи. Назва профілю повинна відповідати завантаженій назві. Це поле повинно бути встановлене, якщо і тільки якщо тип дорівнює "Localhost".

    • securityContext.fsGroup (int64)

      Спеціальна додаткова група, яка застосовується до всіх контейнерів у Podʼі. Деякі типи томів дозволяють Kubelet змінювати право власності на цей том, щоб він належав Podʼу:

      1. GID власника буде FSGroup
      2. Встановлюється біт setgid (нові файли, створені в томі, будуть належати FSGroup)
      3. Біти дозволів обʼєднуються з rw-rw----

      Якщо не встановлено, Kubelet не змінює право власності та дозволи будь-якого тому. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.fsGroupChangePolicy (string)

      fsGroupChangePolicy визначає поведінку зміни прав власності та дозволів тому перед тим, як він буде доступний у Podʼі. Це поле застосовується лише до типів томів, які підтримують права власності на основі fsGroup (та дозволів). Це не впливає на ефемерні типи томів, такі як: secret, configmaps та emptydir. Дійсні значення: "OnRootMismatch" та "Always". Якщо не вказано, використовується "Always". Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.runAsUser (int64)

      UID, з яким запускається початковий процес контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано інше. Також може бути встановлено в PodSecurityContext. Якщо значення встановлено як у 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.seccompProfile (SeccompProfile)

      Параметри seccomp для використання контейнерами в цьому Podʼі. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      SeccompProfile визначає налаштування профілю seccomp для Podʼа/контейнера. Може бути встановлено лише одне джерело профілю.

      • securityContext.seccompProfile.type (string), обовʼязкове

        type вказує, який тип профілю seccomp буде застосовано. Допустимі варіанти:

        • Localhost — має бути використаний профіль, визначений у файлі на вузлі.
        • RuntimeDefault — має бути використаний стандартний профіль для середовища виконання контейнерів.
        • Unconfined — не застосовується жоден профіль.

      • securityContext.seccompProfile.localhostProfile (string)

        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.supplementalGroups ([]int64)

      Atomic: буде замінено під час злиття

      Список груп, які застосовуються до першого процесу, запущеного в кожному контейнері, на додачу до основного GID контейнера та fsGroup (якщо вказано). Якщо функція SupplementalGroupsPolicy увімкнена, поле supplementalGroupsPolicy визначає, чи будуть ці групи додані до вже визначених у контейнерному образі або замінять їх. Якщо не вказано, додаткові групи не додаються, хоча членство в групах, визначених в образі контейнера, може бути використане залежно від поля supplementalGroupsPolicy. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.supplementalGroupsPolicy (string)

      Визначає, як обчислюються додаткові групи для перших процесів контейнера. Дійсні значення: "Merge" і "Strict". Якщо не вказано, використовується значення "Merge". (Alpha) Використання цього поля вимагає ввімкненої функції SupplementalGroupsPolicy, і середовище виконання контейнерів повинно підтримувати цю функцію. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.sysctls ([]Sysctl)

      Atomic: буде замінено під час злиття

      Sysctls містять список sysctls з простором імен, що використовуються для Podʼа. Podʼи з непідтримуваними sysctl (середовищем виконання контейнера) можуть не запуститися. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      Sysctl визначає параметр ядра, який потрібно встановити

      • securityContext.sysctls.name (string), обовʼязкове

        Назва властивості

      • securityContext.sysctls.value (string), обовʼязкове

        Значення властивості

    • securityContext.windowsOptions (WindowsSecurityContextOptions)

      Параметри, специфічні для Windows, що застосовуються до всіх контейнерів. Якщо не зазначено, використовуються параметри у SecurityContext контейнера. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — linux.

      WindowsSecurityContextOptions містять параметри та облікові дані, специфічні для Windows.

      • securityContext.windowsOptions.gmsaCredentialSpec (string)

        GMSACredentialSpec — це місце, де веб-хук GMSA (https://github.com/kubernetes-sigs/windows-gmsa) вставляє вміст GMSA credential spec, зазначений у полі GMSACredentialSpecName.

      • securityContext.windowsOptions.gmsaCredentialSpecName (string)

        GMSACredentialSpecName — це ім’я специфікації облікових даних GMSA для використання.

      • securityContext.windowsOptions.hostProcess (boolean)

        HostProcess визначає, чи повинен контейнер запускатися як контейнер ʼHost Processʼ. Усі контейнери Podʼа повинні мати однакове ефективне значення HostProcess (не дозволяється змішування контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess дорівнює true, то HostNetwork також має бути встановлено на true.

      • securityContext.windowsOptions.runAsUserName (string)

        Ім’я користувача в 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, або безпосередньо, або через вказання ResourceClaimTemplate, який потім перетворюється на ResourceClaim для podʼа.

    Він додає до нього імʼя, яке унікально ідентифікує ResourceClaim всередині podʼа. Контейнери, яким потрібен доступ до цього ResourceClaim, посилаються на нього за цим імʼям.

    • resourceClaims.name (string), обовʼязкове

      Імʼя унікально ідентифікує цей ресурсний запит всередині Podʼа. Це повинно бути DNS_LABEL.

    • resourceClaims.resourceClaimName (string)

      ResourceClaimName — це імʼя обʼєкта ResourceClaim у тому ж просторі імен, що і цей Pod.

      Має бути задано точно одне з ResourceClaimName та ResourceClaimTemplateName.

    • resourceClaims.resourceClaimTemplateName (string)

      ResourceClaimTemplateName — це імʼя обʼєкта ResourceClaimTemplate у тому ж просторі імен, що і цей Pod.

      Шаблон буде використаний для створення нового ResourceClaim, який буде привʼязаний до цього Podʼа. Коли цей Pod буде видалений, ResourceClaim також буде видалений. Імʼя Podʼа та імʼя ресурсу разом з згенерованим компонентом будуть використані для формування унікального імені для ResourceClaim, яке буде записано в pod.status.resourceClaimStatuses.

      Це поле є незмінним, і після створення ResourceClaim панель управління не вноситиме жодних змін до відповідного ResourceClaim.

      Має бути встановлено точно одне з полів ResourceClaimName або ResourceClaimTemplateName.

  • schedulingGates ([]PodSchedulingGate)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення за ключем name будуть збережені під час обʼєднання

    SchedulingGates — це непрозорий список значень, які, якщо вказані, блокуватимуть планування Podʼа. Якщо schedulingGates не порожні, Pod залишатиметься в стані SchedulingGated, і планувальник не намагатиметься його розмістити.

    SchedulingGates можна встановити лише під час створення Podʼа і видаляти лише згодом.

    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.

  • imagePullPolicy (string)

    Політика отримання образу. Одне з значень: Always, Never, IfNotPresent. Стандартно — Always, якщо вказано теґ :latest, або IfNotPresent у іншому випадку. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/containers/images#updating-images

Точка входу

  • command ([]string)

    Atomic: буде замінено під час злиття

    Масив точок входу. Виконується безпосередньо, не у середовищі оболонки. Якщо не надано, буде використано 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)

    Atomic: буде замінено під час злиття

    Аргументи точки входу. Якщо не надано, буде використано 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

    Map: унікальні значення за ключем name будуть збережені під час обʼєднання

    Список змінних середовища для встановлення в контейнері. Не може бути оновлено.

    EnvVar представляє змінну середовища, присутню в контейнері.

    • env.name (string), обовʼязково

      Назва змінної середовища. Повинно бути C_IDENTIFIER.

    • env.value (string)

      Змінні посилання $(VAR_NAME) розгортаються за допомогою попередньо визначених змінних середовища в контейнері та будь-яких змінних середовища Service. Якщо змінну не вдається розʼязати, посилання відносно введеного рядка буде незмінним. Подвійний $$ зменшується до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): тобто "$$(VAR_NAME)" буде створювати літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгорнуті, незалежно від того, чи існує змінна, чи ні. Стандартне значення — "".

    • env.valueFrom (EnvVarSource)

      Джерело значення змінної середовища. Не може бути використано, якщо значення не є пустим.

      EnvVarSource представляє джерело значення EnvVar.

      • env.valueFrom.configMapKeyRef (ConfigMapKeySelector)

        Вибирає ключ з ConfigMap.

        Вибирає ключ з ConfigMap.

        • env.valueFrom.configMapKeyRef.key (string), обовʼязково

          Ключ для вибору.

        • env.valueFrom.configMapKeyRef.name (string)

          Назва обʼєкта на який посилаються. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.configMapKeyRef.optional (boolean)

          Вказує, чи має бути визначений ConfigMap або його ключ

      • env.valueFrom.fieldRef (ObjectFieldSelector)

        Вибирає поле Podʼа: підтримує metadata.name, metadata.namespace, metadata.labels['\<KEY>'], metadata.annotations['\<KEY>'], spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.

      • env.valueFrom.resourceFieldRef (ResourceFieldSelector)

        Вибирає ресурс контейнера: наразі підтримуються лише обмеження і запити ресурсів (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory та requests.ephemeral-storage).

      • env.valueFrom.secretKeyRef (SecretKeySelector)

        Вибирає ключ Secretʼа в просторі імен Podʼа

        SecretKeySelector вибирає ключ Secretʼа.

        • env.valueFrom.secretKeyRef.key (string), обовʼязково

          Ключ Secretʼа для вибору. Повинен бути дійсним ключем Secretʼа.

        • env.valueFrom.secretKeyRef.name (string)

          Назва посилання. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.secretKeyRef.optional (boolean)

          Зазначає, чи має бути визначений Secret або його ключ

  • envFrom ([]EnvFromSource)

    Atomic: буде замінено під час злиття

    Список джерел для заповнення змінних середовища в контейнері. Ключі, визначені в межах джерела, повинні бути C_IDENTIFIER. Усі хибні ключі будуть повідомлені як подія при запуску контейнера. Коли ключ існує в декількох джерелах, значення, що асоціюється з останнім джерелом, буде мати пріоритет. Значення, визначене за допомогою Env з дубльованим ключем, буде мати пріоритет. Не може бути оновлено.

    EnvFromSource представляє джерело набору ConfigMaps

    • envFrom.configMapRef (ConfigMapEnvSource)

      ConfigMap для вибору з

      ConfigMapEnvSource вибирає ConfigMap для заповнення змінними середовища.

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

      • envFrom.configMapRef.name (string)

        Назва посилання. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними/ Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.configMapRef.optional (boolean)

        Вказує, чи має бути визначений ConfigMap

    • envFrom.prefix (string)

      Необовʼязково ідентифікатор для вставлення перед кожним ключем в ConfigMap. Повинен бути C_IDENTIFIER.

    • envFrom.secretRef (SecretEnvSource)

      Secret для вибору з

      SecretEnvSource вибирає Secret для заповнення змінними середовища.

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

      • envFrom.secretRef.name (string)

        Назва посилання. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.secretRef.optional (boolean)

        Вказує, чи має бути визначений Secret

Томи

  • volumeMounts ([]VolumeMount)

    Patch strategy: обʼєднання за ключем mountPath

    Map: унікальні значення за ключем mountPath будуть збережені під час обʼєднання

    Томи, які будуть змонтовані в файлову систему контейнера. Не може бути оновлено.

    VolumeMount описує монтування Тому всередині контейнера.

    • volumeMounts.mountPath (string), обовʼязково

      Шлях всередині контейнера, за яким повинен бути змонтований том. Не повинен містити ':'.

    • volumeMounts.name (string), обовʼязково

      Повинно відповідати імені Тому.

    • volumeMounts.mountPropagation (string)

      mountPropagation визначає, як монтування розповсюджуються від хоста до контейнера і навпаки. Коли не встановлено, використовується MountPropagationNone. Це поле є бета-версією в 1.10. Коли RecursiveReadOnly встановлено в IfPossible або Enabled, MountPropagation повинен бути None або не вказаним (стандартно None).

    • volumeMounts.readOnly (boolean)

      Змонтований як тільки для читання, якщо true, для читання/запису в іншому випадку (false або не вказано). Стандартне значення — false.

    • volumeMounts.recursiveReadOnly (string)

      RecursiveReadOnly вказує, чи слід обробляти монтування тільки для читання рекурсивно.

      Якщо ReadOnly встановлено в false, це поле не має значення і не має бути вказаним.

      Якщо ReadOnly дорівнює true, і це поле встановлено в Disabled, монтування не стає рекурсивним тільки для читання. Якщо це поле встановлено в IfPossible, монтування стає рекурсивним тільки для читання, якщо це підтримується середовищем виконання контейнерів. Якщо це поле встановлено в Enabled, монтування стає рекурсивним тільки для читання, якщо це підтримується середовищем виконання контейнерів; в іншому випадку, pod не буде запущено і буде згенеровано помилку, щоб вказати причину.

      Якщо це поле встановлено в IfPossible або Enabled, MountPropagation має бути встановлено в None (або бути не вказаним, що стандартно дорівнює None).

      Якщо це поле не вказано, воно вважається еквівалентом Disabled.

    • volumeMounts.subPath (string)

      Шлях всередині тому, з якого має бути змонтований том контейнера. Стандартне значення — "" (корінь тому).

    • volumeMounts.subPathExpr (string)

      Розгорнутий шлях всередині тому, з якого має бути змонтований том контейнера. Поводиться схоже до SubPath, але посилання на змінні середовища $(VAR_NAME) розгортаються за допомогою середовища контейнера. Стандартне значення — "" (корінь тому). SubPathExpr і SubPath є взаємовиключними.

  • volumeDevices ([]VolumeDevice)

    Patch strategy: обʼєднання за ключем devicePath

    Map: унікальні значення за ключем devicePath будуть збережені під час обʼєднання

    volumeDevices — це список блочних пристроїв, які будуть використані контейнером.

    volumeDevice описує зіставлення необробленого блочного пристрою всередині контейнера.

    • volumeDevices.devicePath (string), обовʼязково

      devicePath — це шлях всередині контейнера, на який буде зіставлено пристрій.

    • volumeDevices.name (string), обовʼязково

      name повинно відповідати імені persistentVolumeClaim в Podʼі.

Ресурси

  • resources (ResourceRequirements)

    Обчислювальні ресурси, необхідні для цього контейнера. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    ResourceRequirements описує вимоги до обчислювальних ресурсів.

    • resources.claims ([]ResourceClaim)

      Map: унікальні значення за ключем будуть збережені під час обʼєднання

      Claims містить назви ресурсів, визначених в spec.resourceClaims, які використовуються цим контейнером.

      Це поле альфа-версії і вимагає включення функціоналу DynamicResourceAllocation.

      Це поле є незмінним. Його можна встановити тільки для контейнерів.

      ResourceClaim посилається на один запис в PodSpec.ResourceClaims.

      • resources.claims.name (string), обовʼязково

        Імʼя повинно відповідати імені одного запису в pod.spec.resourceClaims Podʼа, де використовується це поле. Це робить цей ресурс доступним всередині контейнера.

      • resources.claims.request (string)

        Request — це імʼя, вибране для запиту в зазначеній заявці. Якщо поле порожнє, буде доступно все з заявки; в іншому випадку, доступний буде лише результат цього запиту.

    • resources.limits (map[string]Quantity)

      Limits визначає максимальну кількість обчислювальних ресурсів, дозволених. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • resources.requests (map[string]Quantity)

      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 управління контейнером блокується, поки дія не буде завершена, якщо процес контейнера виявляється несправним, тоді обробник переривається.

    • lifecycle.postStart (LifecycleHandler)

      PostStart викликається негайно після створення контейнера. Якщо обробник не вдалося виконати, контейнер буде завершено і перезапущено згідно зі своєю політикою перезапуску. Інше управління контейнером блокується, поки хук не завершиться. Докладніше: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

    • lifecycle.preStop (LifecycleHandler)

      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. Не може бути оновлено.

  • livenessProbe (Probe)

    Періодичне тестування життєздатності контейнера. Контейнер буде перезапущено, якщо тест не вдасться. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • readinessProbe (Probe)

    Періодична перевірка готовності контейнера до обслуговування. Контейнер буде видалено з точок доступу Service, якщо проба зазнає невдачі. Неможливо оновити. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • startupProbe (Probe)

    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)

    SecurityContext визначає параметри безпеки, з якими має працювати контейнер. Якщо встановлено, поля SecurityContext замінять відповідні поля PodSecurityContext. Докладніше: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

    SecurityContext містить конфігурацію безпеки, яка буде застосована до контейнера. Деякі поля присутні як у SecurityContext, так і в PodSecurityContext. Якщо обидва встановлені, значення в SecurityContext мають пріоритет.

    • securityContext.allowPrivilegeEscalation (boolean)

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

      1. Запускається з привілеями (Privileged)
      2. Має CAP_SYS_ADMIN

      Зверніть увагу, що це поле не може бути встановлене, коли spec.os.name дорівнює windows.

    • securityContext.appArmorProfile (AppArmorProfile)

      appArmorProfile — це параметри AppArmor, які використовуються цим контейнером. Якщо встановлено, цей профіль переважає профіль AppArmor podʼа. Зверніть увагу, що це поле не може бути встановлене, коли spec.os.name дорівнює windows.

      AppArmorProfile визначає налаштування AppArmor для podʼа або контейнера.

      • securityContext.appArmorProfile.type (string), обовʼязково

        Поле type вказує, який тип профілю AppArmor буде застосовано. Дійсні варіанти:

        • Localhost — профіль, попередньо завантажений на вузлі.
        • RuntimeDefault — стандартний профіль середовища виконання контейнерів.
        • Unconfined — без примусового виконання правил AppArmor.

      • securityContext.appArmorProfile.localhostProfile (string)

        localhostProfile вказує профіль, завантажений на вузлі, який слід використовувати. Профіль має бути попередньо налаштований на вузлі для коректної роботи. Назва профілю повинна відповідати завантаженій назві. Це поле повинно бути встановлене, якщо і тільки якщо тип дорівнює "Localhost".

    • securityContext.capabilities (Capabilities)

      Можливості для додавання/видалення під час запуску контейнерів. Стандарто використовується набір можливостей, наданих середовищем виконання контейнера. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      Додає та видаляє можливості POSIX з працюючих контейнерів.

      • securityContext.capabilities.add ([]string)

        Atomic: буде замінено під час обʼєднання

        Додані можливості.

      • securityContext.capabilities.drop ([]string)

        Atomic: буде замінено під час обʼєднання

        Видалені можливості.

    • securityContext.procMount (string)

      procMount вказує тип монтування файлової системи /proc, який слід використовувати для контейнерів. Стандартне значення — Default, що використовує стандартні налаштування середовища виконання контейнерів для шляхів тільки для читання та замаскованих шляхів. Це вимагає ввімкнення функціональної можливості ProcMountType. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.privileged (boolean)

      Запуск контейнера у привілейованому режимі. Процеси у привілейованих контейнерах по суті еквівалентні root на хості. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.readOnlyRootFilesystem (boolean)

      Чи має цей контейнер кореневу файлову систему тільки для читання. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.runAsUser (int64)

      UID, з яким запускається початковий процес контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано інше. Також може бути встановлено в PodSecurityContext. Якщо значення встановлено як у 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.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, що застосовується до контейнера.

    • securityContext.seccompProfile (SeccompProfile)

      Параметри seccomp для використання контейнерами в цьому Podʼі. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      SeccompProfile визначає налаштування профілю seccomp для Podʼа/контейнера. Може бути встановлено лише одне джерело профілю.

      • securityContext.seccompProfile.type (string), обовʼязкове

        type вказує, який тип профілю seccomp буде застосовано. Допустимі варіанти:

        • Localhost — має бути використаний профіль, визначений у файлі на вузлі.
        • RuntimeDefault — має бути використаний стандартний профіль для середовища виконання контейнерів.
        • Unconfined — не застосовується жоден профіль.

      • securityContext.seccompProfile.localhostProfile (string)

        localhostProfile вказує, що має бути використаний профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі, щоб працювати. Має бути низхідний шлях, відносно до налаштованого розташування профілю seccomp kubelet. Має бути встановлено, якщо тип "Localhost". НЕ має бути встановлено для будь-якого іншого типу.

    • securityContext.windowsOptions (WindowsSecurityContextOptions)

      Специфічні налаштування для Windows, які застосовуються до всіх контейнерів. Якщо не вказано, використовуються опції з PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є linux.

      WindowsSecurityContextOptions містять специфічні для Windows параметри та облікові дані.

      • securityContext.windowsOptions.gmsaCredentialSpec (string)

        GMSACredentialSpec — це місце, де вебхук GMSA (https://github.com/kubernetes-sigs/windows-gmsa) вставляє вміст специфікації облікових даних GMSA, названої полем GMSACredentialSpecName.

      • securityContext.windowsOptions.gmsaCredentialSpecName (string)

        GMSACredentialSpecName — це назва специфікації облікових даних GMSA, яка буде використана.

      • securityContext.windowsOptions.hostProcess (boolean)

        HostProcess визначає, чи слід запускати контейнер як контейнер ʼHost Processʼ. Усі контейнери Pod повинні мати однакове значення HostProcess (не дозволено мати суміш контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess є true, то HostNetwork також повинен бути встановлений у true.

      • securityContext.windowsOptions.runAsUserName (string)

        Імʼя користувача в 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.

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

Образ

Точка входу

  • command ([]string)

    Atomic: буде замінено під час злиття

    Масив команд для точки входу. Не виконується в оболонці. Використовується 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)

    Atomic: буде замінено під час злиття

    Аргументи для точки входу. Якщо не надано, буде використано 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

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список змінних середовища для передачі в контейнер. Не може бути оновлено.

    EnvVar представляє змінну середовища, присутню в контейнері.

    • name (string), обовʼязково

      Назва змінної середовища. Повинно бути C_IDENTIFIER.

    • value (string)

      Змінні посилання $(VAR_NAME) розгортаються за допомогою попередньо визначених змінних середовища в контейнері та будь-яких змінних середовища Service. Якщо змінну не вдається розʼязати, посилання відносно введеного рядка буде незмінним. Подвійний $$ зменшується до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): тобто "$$(VAR_NAME)" буде створювати літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгорнуті, незалежно від того, чи існує змінна, чи ні. Стандартне значення — "".

    • env.valueFrom (EnvVarSource)

      Джерело значення змінної середовища. Не може бути використано, якщо значення не є пустим.

      EnvVarSource представляє джерело значення EnvVar.

      • env.valueFrom.configMapKeyRef (ConfigMapKeySelector)

        Вибирає ключ з ConfigMap.

        Вибирає ключ з ConfigMap.

        • env.valueFrom.configMapKeyRef.key (string), обовʼязково

          Ключ для вибору.

        • env.valueFrom.configMapKeyRef.name (string), обовʼязково

          Назва обʼєкта на який посилаються. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.configMapKeyRef.optional (boolean)

          Вказує, чи має бути визначений ConfigMap або його ключ

      • env.valueFrom.fieldRef (ObjectFieldSelector)

        Вибирає поле Podʼа: підтримує metadata.name, metadata.namespace, metadata.labels['\<KEY>'], metadata.annotations['\<KEY>'], spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.

      • env.valueFrom.resourceFieldRef (ResourceFieldSelector)

        Вибирає ресурс контейнера: наразі підтримуються лише обмеження і запити ресурсів (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory та requests.ephemeral-storage).

      • env.valueFrom.secretKeyRef (SecretKeySelector)

        Вибирає ключ Secretʼа в просторі імен Podʼа

        SecretKeySelector вибирає ключ Secretʼа.

        • env.valueFrom.secretKeyRef.key (string), обовʼязково

          Ключ Secretʼа для вибору. Повинен бути дійсним ключем Secretʼа.

        • env.valueFrom.secretKeyRef.name (string)

          Назва посилання. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.secretKeyRef.optional (boolean)

          Зазначає, чи має бути визначений Secret або його ключ

  • envFrom ([]EnvFromSource)

    Atomic: буде замінено під час злиття

    Список джерел для заповнення змінних середовища в контейнері. Ключі, визначені в межах джерела, повинні бути C_IDENTIFIER. Усі хибні ключі будуть повідомлені як подія при запуску контейнера. Коли ключ існує в декількох джерелах, значення, що асоціюється з останнім джерелом, буде мати пріоритет. Значення, визначене за допомогою Env з дубльованим ключем, буде мати пріоритет. Не може бути оновлено.

    EnvFromSource представляє джерело набору ConfigMaps

    • envFrom.configMapRef (ConfigMapEnvSource)

      ConfigMap для вибору з

      ConfigMapEnvSource вибирає ConfigMap для заповнення змінними середовища.

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

      • envFrom.configMapRef.name (string)

        Назва посилання. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.configMapRef.optional (boolean)

        Вказує, чи має бути визначений ConfigMap

    • envFrom.prefix (string)

      Необовʼязково ідентифікатор для вставлення перед кожним ключем в ConfigMap. Повинен бути C_IDENTIFIER.

    • envFrom.secretRef (SecretEnvSource)

      Secret для вибору з

      SecretEnvSource вибирає Secret для заповнення змінними середовища.

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

      • envFrom.secretRef.name (string)

        Назва посилання. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.secretRef.optional (boolean)

        Вказує, чи має бути визначений Secret

Томи

  • volumeMounts ([]VolumeMount)

    Patch strategy: обʼєднання за ключем mountPath

    Map: унікальні значення ключа mountPath будуть збережені під час злиття

    Томи Podʼів для монтування у файлову систему контейнера. Субшляхи монтування в ефемерних контейнерах не дозволяються. Не може бути оновлено.

    VolumeMount описує монтування Тому всередині контейнера.

    • volumeMounts.mountPath (string), обовʼязково

      Шлях всередині контейнера, за яким повинен бути змонтований том. Не повинен містити ':'.

    • volumeMounts.name (string), обовʼязково

      Повинно відповідати імені Тому.

    • volumeMounts.mountPropagation (string)

      mountPropagation визначає, як монтування розповсюджуються від хоста до контейнера і навпаки. Коли не встановлено, використовується MountPropagationNone. Це поле є бета-версією в 1.10. Коли RecursiveReadOnly встановлено на IfPossible або Enabled, MountPropagation повинно бути None або невказаним (що стандартно дорівнює None).

    • volumeMounts.readOnly (boolean)

      Змонтований як тільки для читання, якщо true, для читання/запису в іншому випадку (false або не вказано). Стандартне значення — false.

    • volumeMounts.recursiveReadOnly (string)

      RecursiveReadOnly визначає, чи повинні змонтовані в режимі "тільки для читання" ресурси оброблятися рекурсивно.

      Якщо ReadOnly дорівнює false, це поле не має значення і не повинно бути вказаним. Якщо ReadOnly дорівнює true і це поле встановлено на Disabled, монтування не виконується рекурсивно в режимі "тільки для читання". Якщо це поле встановлено на IfPossible, монтування виконується рекурсивно в режимі "тільки для читання", якщо це підтримується контейнерним середовищем. Якщо це поле встановлено на Enabled, монтування виконується рекурсивно в режимі "тільки для читання", якщо це підтримується контейнерним середовищем, інакше pod не буде запущено, і буде згенеровано помилку з відповідною причиною.

      Якщо це поле встановлено на IfPossible або Enabled, значення MountPropagation повинно бути встановлено на None (або бути невказаним, що стандартно дорівнює None).

      Якщо це поле не вказано, воно вважається еквівалентним до Disabled.

    • volumeMounts.subPath (string)

      Шлях всередині тому, з якого має бути змонтований том контейнера. Стандартне значення — "" (корінь тому).

    • volumeMounts.subPathExpr (string)

      Розгорнутий шлях всередині тому, з якого має бути змонтований том контейнера. Поводиться схоже до SubPath, але посилання на змінні середовища $(VAR_NAME) розгортаються за допомогою середовища контейнера. Стандартне значення — "" (корінь тому). SubPathExpr і SubPath є взаємовиключними.

  • volumeDevices ([]VolumeDevice)

    Patch strategy: обʼєднання за ключем devicePath

    Map: унікальні значення ключа 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)

    SecurityContext визначає параметри безпеки, з якими має працювати контейнер. Якщо встановлено, поля SecurityContext замінять відповідні поля PodSecurityContext. Докладніше: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

    SecurityContext містить конфігурацію безпеки, яка буде застосована до контейнера. Деякі поля присутні як у SecurityContext, так і в PodSecurityContext. Якщо обидва встановлені, значення в SecurityContext мають пріоритет.

    • securityContext.allowPrivilegeEscalation (boolean)

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

      AllowPrivilegeEscalation завжди має значення true за наступних умов:

      1. Контейнер запускається в привілейованому режимі (Privileged).
      2. Контейнер має CAP_SYS_ADMIN.

      Зверніть увагу, що це поле не можна встановити, якщо spec.os.name дорівнює windows.

    • securityContext.appArmorProfile (AppArmorProfile)

      appArmorProfile визначає параметри AppArmor, які використовуються для цього контейнера. Якщо встановлено, цей профіль замінює профіль AppArmor для всього podʼа. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      AppArmorProfile визначає налаштування AppArmor для podʼа або контейнера.

      • securityContext.appArmorProfile.type (string), обовʼязково

        Поле type вказує, який тип профілю AppArmor буде застосовано. Дійсні варіанти:

        • Localhost — профіль, попередньо завантажений на вузлі.
        • RuntimeDefault — стандартний профіль середовища виконання контейнерів.
        • Unconfined — без примусового виконання правил AppArmor.

      • securityContext.appArmorProfile.localhostProfile (string)

        localhostProfile вказує профіль, завантажений на вузлі, який слід використовувати. Профіль має бути попередньо налаштований на вузлі для коректної роботи. Назва профілю повинна відповідати завантаженій назві. Це поле повинно бути встановлене, якщо і тільки якщо тип дорівнює "Localhost".

    • securityContext.capabilities (Capabilities)

      Можливості для додавання/видалення під час запуску контейнерів. Стандарто використовується набір можливостей, наданих середовищем виконання контейнера. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      Додає та видаляє можливості POSIX з працюючих контейнерів.

      • securityContext.capabilities.add ([]string)

        Atomic: буде замінено під час злиття

        Додані можливості.

      • securityContext.capabilities.drop ([]string)

        Atomic: буде замінено під час злиття

        Видалені можливості.

    • securityContext.procMount (string)

      procMount позначає тип монтування proc, який слід використовувати для контейнерів. Стандартне значення — Default, яке використовує стандартні налаштування середовища виконання контейнера для шляхів тільки для читання та змаскованих шляхів. Це вимагає увімкнення прапорця функції ProcMountType. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.privileged (boolean)

      Запуск контейнера у привілейованому режимі. Процеси у привілейованих контейнерах по суті еквівалентні root на хості. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.readOnlyRootFilesystem (boolean)

      Чи має цей контейнер кореневу файлову систему тільки для читання. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.runAsUser (int64)

      UID, з яким запускається початковий процес контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано інше. Також може бути встановлено в PodSecurityContext. Якщо значення встановлено як у 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.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, що застосовується до контейнера.

    • securityContext.seccompProfile (SeccompProfile)

      Параметри seccomp для використання контейнерами в цьому Podʼі. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      SeccompProfile визначає налаштування профілю seccomp для Podʼа/контейнера. Може бути встановлено лише одне джерело профілю.

      • securityContext.seccompProfile.type (string), обовʼязкове

        type вказує, який тип профілю seccomp буде застосовано. Допустимі варіанти:

        • Localhost — має бути використаний профіль, визначений у файлі на вузлі.
        • RuntimeDefault — має бути використаний стандартний профіль для середовища виконання контейнерів.
        • Unconfined — не застосовується жоден профіль.

      • securityContext.seccompProfile.localhostProfile (string)

        localhostProfile вказує, що має бути використаний профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі, щоб працювати. Має бути низхідний шлях, відносно до налаштованого розташування профілю seccomp kubelet. Має бути встановлено, якщо тип "Localhost". НЕ має бути встановлено для будь-якого іншого типу.

    • securityContext.windowsOptions (WindowsSecurityContextOptions)

      Специфічні налаштування для Windows, які застосовуються до всіх контейнерів. Якщо не вказано, використовуються опції з PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є linux.

      WindowsSecurityContextOptions містять специфічні для Windows параметри та облікові дані.

      • securityContext.windowsOptions.gmsaCredentialSpec (string)

        GMSACredentialSpec — це місце, де вебхук GMSA (https://github.com/kubernetes-sigs/windows-gmsa) вставляє вміст специфікації облікових даних GMSA, названої полем GMSACredentialSpecName.

      • securityContext.windowsOptions.gmsaCredentialSpecName (string)

        GMSACredentialSpecName — це назва специфікації облікових даних GMSA, яка буде використана.

      • securityContext.windowsOptions.hostProcess (boolean)

        HostProcess визначає, чи слід запускати контейнер як контейнер ʼHost Processʼ. Усі контейнери Pod повинні мати однакове значення HostProcess (не дозволено мати суміш контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess є true, то HostNetwork також повинен бути встановлений у true.

      • securityContext.windowsOptions.runAsUserName (string)

        Імʼя користувача в 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ʼа, де використовується це поле. Це робить цей ресурс доступним всередині контейнера.

      • resources.claims.request (string)

        Request — це імʼя, вибране для запиту в зазначеній заявці. Якщо поле порожнє, буде доступно все з заявки; в іншому випадку, доступний буде лише результат цього запиту.

    • resources.limits (map[string]Quantity)

      Limits визначає максимальну кількість обчислювальних ресурсів, дозволених. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • resources.requests (map[string]Quantity)

      Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється в Limits, якщо це явно вказано, інакше — у значення, визначеного реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

  • lifecycle (Lifecycle)

    Для ефемерних контейнерів заборонено використовувати lifecycle.

    Lifecycle описує дії, які система управління повинна виконати у відповідь на події життєвого циклу контейнера. Для обробників життєвого циклу PostStart і PreStop управління контейнером блокується, поки дія не буде завершена, якщо процес контейнера виявляється несправним, тоді обробник переривається.

    • lifecycle.postStart (LifecycleHandler)

      PostStart викликається негайно після створення контейнера. Якщо обробник не вдалося виконати, контейнер буде завершено і перезапущено згідно зі своєю політикою перезапуску. Інше управління контейнером блокується, поки хук не завершиться. Докладніше: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

    • lifecycle.preStop (LifecycleHandler)

      PreStop викликається негайно перед тим, як контейнер буде завершено через запит API або подію управління, таку як невдача проби справності/запуску, випередження, скорочення ресурсів тощо. Обробник не викликається, якщо контейнер впаде або закінчить роботу. Період перебігу належного завершення підраховується до виконання хуку PreStop. Незалежно від результату обробника, контейнер в кінцевому підсумку завершиться протягом періоду належного завершення Pod (якщо він не буде затриманий завершенням залишкових операцій). Інше управління контейнером блокується, поки хук не завершиться або досягне періоду належного завершення. Докладніше: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

  • livenessProbe (Probe)

    Проби не дозволені для ефемерних контейнерів.

  • readinessProbe (Probe)

    Проби не дозволені для ефемерних контейнерів.

  • startupProbe (Probe)

    Проби не дозволені для ефемерних контейнерів.

Обробник життєвого циклу

Обробник життєвого циклу (LifecycleHandler) визначає конкретну дію, яку слід виконати в хуці життєвого циклу. Має бути вказане тільки одне з полів, за винятком TCPSocket.

  • exec (ExecAction)

    Exec визначає дію, яку слід виконати.

    ExecAction описує дію "виконати в контейнері".

    • exec.command ([]string)

      Atomic: буде замінено під час злиття

      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)

      Atomic: буде замінено під час злиття

      Власні заголовки для встановлення в запиті. HTTP дозволяє повторювані заголовки.

      HTTPHeader описує власний заголовок, який буде використовуватись в HTTP-пробах.

      • httpGet.httpHeaders.name (string), обовʼязково

        Назва поля заголовка. Воно буде канонізовано при виведенні, тому імена, що відрізняються регістром, будуть сприйматись як один і той самий заголовок.

      • httpGet.httpHeaders.value (string), обовʼязково

        Значення поля заголовка.

    • httpGet.path (string)

      Шлях для доступу до HTTP-сервера.

    • httpGet.scheme (string)

      Схема для підключення до хоста. Стандартне значення — HTTP.

  • sleep (SleepAction)

    Sleep представляє тривалість, протягом якої контейнер повинен бездіяти перед завершенням.

    SleepAction описує дію "sleep".

    • sleep.seconds (int64), обовʼязково

      Seconds — кількість секунд для sleep.

  • 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 — це група правил планування вузлів за спорідненістю.

  • preferredDuringSchedulingIgnoredDuringExecution ([]PreferredSchedulingTerm)

    Atomic: буде замінено під час злиття

    Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо вузол відповідає відповідним matchExpressions; вузол(и) з найвищою сумою є найпріоритетнішими.

    Порожній термін пріоритету планування відповідає всім об’єктам з неявною вагою 0 (тобто, він не діє). Нульовий термін пріоритету планування не відповідає жодному обʼєкту (тобто, також не діє).

    • preferredDuringSchedulingIgnoredDuringExecution.preference (NodeSelectorTerm), обов’язковий

      Термін селектора вузлів, пов’язаний з відповідною вагою.

      Нульовий або порожній термін селектора вузлів не відповідає жодному обʼєкту. Вимоги до них обʼєднані за допомогою операції AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      Atomic: буде замінено під час злиття

      Список вимог селектора вузлів за мітками вузлів.

      Atomic: буде замінено під час злиття

      Список вимог селектора вузлів за полями вузлів.

    • preferredDuringSchedulingIgnoredDuringExecution.weight (int32), обов’язковий

      Вага, пов’язана з відповідним nodeSelectorTerm, у діапазоні 1-100.

  • requiredDuringSchedulingIgnoredDuringExecution (NodeSelector)

    Якщо вимоги спорідненості, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги спорідненості, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення), система може або не може спробувати врешті-решт виселити Pod з його вузла.

    Селектор вузлів представляє обʼєднання результатів одного або кількох запитів за мітками до набору вузлів; тобто він представляє OR селекторів, представлених термінами селектора вузлів.

    • requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms ([]NodeSelectorTerm), обов’язковий

      Atomic: буде замінено під час злиття

      Обов’язковий. Список термінів селектора вузлів. Терміни обʼєднані за допомогою операції OR.

      Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      • requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог селектора вузлів за мітками вузлів.

      • requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог селектора вузлів за полями вузлів.

PodAffinity

Pod affinity — це група правил планування між Podʼами за спорідненістю.

  • preferredDuringSchedulingIgnoredDuringExecution ([]WeightedPodAffinityTerm)

    Atomic: буде замінено під час злиття

    Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька з цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо на вузлі є Podʼи, які відповідають відповідному podAffinityTerm; вузол(и) з найвищою сумою є найпріоритетнішими.

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

    • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm (PodAffinityTerm), обов’язковий

      Обов’язковий. Термін спорідненості Podʼа, пов’язаний з відповідною вагою.

      Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey (string), обов’язковий

        Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен, де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector (LabelSelector)

        Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Pod'ом.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.matchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.mismatchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaceSelector (LabelSelector)

        Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces ([]string)

        Atomic: буде замінено під час злиття

        Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

    • preferredDuringSchedulingIgnoredDuringExecution.weight (int32), обов’язковий

      Вага, пов’язана з відповідним podAffinityTerm, у діапазоні 1-100.

  • requiredDuringSchedulingIgnoredDuringExecution ([]PodAffinityTerm)

    Atomic: буде замінено під час злиття

    Якщо вимоги спорідненісті, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги спорідненісті, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення міток Podʼа), система може або не може спробувати врешті-решт виселити Pod з його вузла. Коли є кілька елементів, списки вузлів, що відповідають кожному podAffinityTerm, перетинаються, тобто всі терміни мають бути виконані.

    Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

    • requiredDuringSchedulingIgnoredDuringExecution.topologyKey (string), обов’язковий

      Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен, де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

    • requiredDuringSchedulingIgnoredDuringExecution.labelSelector (LabelSelector)

      Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Podʼом.

    • requiredDuringSchedulingIgnoredDuringExecution.matchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.mismatchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.namespaceSelector (LabelSelector)

      Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

    • requiredDuringSchedulingIgnoredDuringExecution.namespaces ([]string)

      Atomic: буде замінено під час злиття

      Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

PodAntiAffinity

Pod anti affinity — це група правил планування між Podʼами за анти-спорідненістю.

  • preferredDuringSchedulingIgnoredDuringExecution ([]WeightedPodAffinityTerm)

    Atomic: буде замінено під час злиття

    Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам анти-спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька з цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази анти-спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо на вузлі є Podʼи, які відповідають відповідному podAffinityTerm; вузол(и) з найвищою сумою є найпріоритетнішими.

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

    • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm (PodAffinityTerm), обов’язковий

      Обов’язковий. Термін спорідненості Podʼа, пов’язаний з відповідною вагою.

      Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey (string), обов’язковий

        Цей Pod повинен бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен. Розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector (LabelSelector)

        Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Podʼом.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.matchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.mismatchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaceSelector (LabelSelector)

        Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces ([]string)

        Atomic: буде замінено під час злиття

        Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

    • preferredDuringSchedulingIgnoredDuringExecution.weight (int32), обов’язковий

      Вага, пов’язана з відповідним podAffinityTerm, у діапазоні 1-100.

  • requiredDuringSchedulingIgnoredDuringExecution ([]PodAffinityTerm)

    Atomic: буде замінено під час злиття

    Якщо вимоги анти-спорідненості, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги анти-спорідненості, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення міток Podʼа), система може або не може спробувати врешті-решт виселити Pod з його вузла. Коли є кілька елементів, списки вузлів, що відповідають кожному podAffinityTerm, перетинаються, тобто всі терміни мають бути виконані.

    Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

    • requiredDuringSchedulingIgnoredDuringExecution.topologyKey (string), обов’язковий

      Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен. Розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

    • requiredDuringSchedulingIgnoredDuringExecution.labelSelector (LabelSelector)

      Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Podʼом.

    • requiredDuringSchedulingIgnoredDuringExecution.matchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.mismatchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.namespaceSelector (LabelSelector)

      Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

    • requiredDuringSchedulingIgnoredDuringExecution.namespaces ([]string)

      Atomic: буде замінено під час злиття

      Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

Проба

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

  • exec (ExecAction)

    Exec визначає дію, яку потрібно виконати.

    ExecAction описує дію "виконати в контейнері".

    • exec.command ([]string)

      Atomic: буде замінено під час злиття

      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)

      Atomic: буде замінено під час злиття

      Власні заголовки для встановлення в запиті. 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ʼа.

  • initialDelaySeconds (int32)

    Кількість секунд після запуску контейнера перед початком перевірки на життєздатність. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • terminationGracePeriodSeconds (int64)

    Необовʼязкова тривалість у секундах, необхідна для завершення роботи Podʼа після збою перевірки. Період належного завершення — це тривалість у секундах після того, як процесам у Podʼі надіслано сигнал про завершення і час до примусової зупинки процесів сигналом kill. Встановіть цю величину більше, ніж очікуваний час завершення вашого процесу. Якщо це значення є nil, буде використано terminationGracePeriodSeconds Podʼа. В іншому випадку, це значення перекриває значення, надане у специфікації Podʼа. Значення має бути невідʼємним числом. Значення нуль означає негайну зупинку через сигнал kill (без можливості завершення). Це поле є бета-функцією і вимагає увімкнення gate ProbeTerminationGracePeriod. Мінімальне значення — 1. Якщо не встановлено, використовується spec.terminationGracePeriodSeconds.

  • periodSeconds (int32)

    Як часто (у секундах) виконувати перевірку. Стандартне значення — 10 секунд. Мінімальне значення — 1.

  • timeoutSeconds (int32)

    Кількість секунд після якої перевірка завершується з тайм-аутом. Стандартне значення — 1 секунда. Мінімальне значення — 1. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • failureThreshold (int32)

    Мінімальна кількість послідовних збоїв, щоб перевірка вважалася невдалою після того, як вона вже пройшла успішно. Стандартне значення — 3. Мінімальне значення — 1.

  • successThreshold (int32)

    Мінімальна кількість послідовних успішних перевірок, щоб вважати перевірку успішною після того, як вона не вдалася. Стандартне значення — 1. Має бути 1 для liveness та startup. Мінімальне значення — 1.

  • grpc (GRPCAction)

    GRPC визначає дію, що включає GRPC-порт.

    **

    • grpc.port (int32), обовʼязково

      Номер порту GRPC сервісу. Номер має бути в діапазоні від 1 до 65535.

    • grpc.service (string)

      Service — це імʼя сервісу, яке потрібно вказати в GRPC HealthCheckRequest (див. https://github.com/grpc/grpc/blob/master/doc/health-checking.md).

      Якщо це не вказано, то стандартна поведінка визначається 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ʼа.

    Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-phase

  • message (string)

    Повідомлення, зрозуміле людині, що вказує на деталі, чому Pod знаходиться в цьому стані.

  • reason (string)

    Коротке повідомлення у форматі CamelCase, що вказує на деталі, чому Pod знаходиться в цьому стані, наприклад, ʼEvictedʼ.

  • podIP (string)

    podIP — IP-адреса, виділена Podʼа. Доступна для маршрутизації принаймні в межах кластера. Пусте, якщо ще не виділено.

  • podIPs ([]PodIP)

    Patch strategy: злиття за ключем ip

    Map: унікальні значення ключа ip будуть збережені під час злиття

    podIPs містить IP-адреси, виділені Podʼу. Якщо це поле задано, 0-й запис повинен відповідати полю podIP. Podʼам може бути виділено не більше одного значення для кожного з IPv4 та IPv6. Цей список пустий, якщо IP-адреси ще не виділено.

    PodIP представляє одну IP-адресу, виділену Podʼу.

    • podIPs.ip (string), обовʼязково

      IP — це IP-адреса, призначена Podʼу.

  • conditions ([]PodCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Поточний стан обслуговування Podʼа. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions

    PodCondition містить деталі поточного стану цього Podʼа.

    • conditions.status (string), обовʼязково

      Статус стану. Може бути True, False, Unknown. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions

    • conditions.type (string), обовʼязково

      Тип є типом стану. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions

    • conditions.lastProbeTime (Time)

      Останній час, коли ми перевіряли стан.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastTransitionTime (Time)

      Останній час, коли стан перейшов з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, що вказує на деталі останнього переходу.

    • conditions.reason (string)

      Унікальна, однослівна, у CamelCase причина останнього переходу умови.

  • qosClass (string)

    Класифікація якості обслуговування (QOS), присвоєна Podʼу на основі вимог до ресурсів. Дивіться тип PodQOSClass для доступних класів QOS. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#quality-of-service-classes

  • initContainerStatuses ([]ContainerStatus)

    Atomic: буде замінено під час злиття

    Список містить один запис на кожен контейнер ініціалізації в маніфесті. Найбільш успішний контейнер ініціалізації матиме ready = true, найбільш нещодавно запущений контейнер матиме startTime встановлений. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status

    ContainerStatus містить деталі поточного стану цього контейнера.

    • initContainerStatuses.allocatedResources (map[string]Quantity)

      AllocatedResources представляє обчислювальні ресурси, виділені для цього контейнера вузлом. Kubelet встановлює це значення у Container.Resources.Requests після успішного допуску podʼа та після успішного допуску бажаного масштабування podʼа.

    • initContainerStatuses.allocatedResourcesStatus ([]ResourceStatus)

      Patch strategy: злиття за ключем type

      Map: унікальні значення ключа type будуть збережені під час злиття

      AllocatedResourcesStatus представляє статус різних ресурсів, виділених для цього podʼа.

      **

      • initContainerStatuses.allocatedResourcesStatus.name (string), обовʼязково

        Назва ресурсу. Має бути унікальною в межах podʼа та відповідати одному з ресурсів зі специфікації podʼа.

      • initContainerStatuses.allocatedResourcesStatus.resources ([]ResourceHealth)

        Map: унікальні значення ключа resourceID будуть збережені під час злиття

        Список унікальних станів ресурсів. Кожен елемент списку містить унікальний ідентифікатор ресурсу та стан ресурсу. Мінімум, ResourceID має унікально ідентифікувати ресурс, виділений podʼу на вузлі протягом життя podʼа. Дивіться тип ResourceID для його визначення.

        ResourceHealth представляє стан справності ресурсу. Він містить останню інформацію про стан пристрою. Це частина KEP https://kep.k8s.io/4680, і планується додавання історичних змін стану справності в майбутніх ітераціях KEP.

        • initContainerStatuses.allocatedResourcesStatus.resources.resourceID (string), обовʼязково

          ResourceID є унікальним ідентифікатором ресурсу. Дивіться тип ResourceID для отримання додаткової інформації.

        • initContainerStatuses.allocatedResourcesStatus.resources.health (string)

          Health ресурсу. Може бути одним з:

          • Healthy: працює нормально
          • Unhealthy: повідомлено про несправний стан. Ми вважаємо це тимчасовою проблемою зі справністю, оскільки наразі у нас немає механізму для розрізнення тимчасових і постійних проблем.
          • Unknown: статус не можна визначити. Наприклад, втулок пристрою було відключено і він не був повторно зареєстрований з того часу.

          В майбутньому ми можемо ввести статус PermanentlyUnhealthy.

    • initContainerStatuses.containerID (string)

      ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'. Де type є ідентифікатором середовища виконання контейнера, що повертається з виклику Version API CRI (наприклад, "containerd").

    • initContainerStatuses.image (string), обовʼязково

      Image є назвою образу контейнера з якого запущений у контейнері. Образ контейнера може не збігатися з образом, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання. Докладніше: https://kubernetes.io/docs/concepts/containers/images

    • initContainerStatuses.imageID (string), обовʼязково

      ImageID є ідентифікатором образу контейнера. Ідентифікатор образу може не збігатися з ідентифікатором образу, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання.

    • initContainerStatuses.lastState (ContainerState)

      LastTerminationState містить останній стан завершення контейнера, щоб допомогти в налагодженні аварійних зупинок та перезапусків контейнера. Це поле не заповнюється, якщо контейнер все ще запущений і RestartCount дорівнює 0.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • initContainerStatuses.lastState.running (ContainerStateRunning)

        Відомості про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • initContainerStatuses.lastState.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • initContainerStatuses.lastState.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • initContainerStatuses.lastState.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • initContainerStatuses.lastState.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • initContainerStatuses.lastState.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.lastState.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.lastState.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • initContainerStatuses.lastState.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • initContainerStatuses.lastState.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • initContainerStatuses.lastState.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • initContainerStatuses.lastState.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • initContainerStatuses.lastState.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • initContainerStatuses.name (string), обовʼязково

      Name є DNS_LABEL, що представляє унікальну назву контейнера. Кожен контейнер в podʼі повинен мати унікальну назву серед усіх типів контейнерів. Не можна оновити.

    • initContainerStatuses.ready (boolean), обовʼязково

      Ready вказує, чи контейнер наразі проходить перевірку готовності. Значення змінюватиметься, оскільки перевірки готовності продовжують виконуватися. Якщо перевірки готовності не вказані, це поле стандартно буде true, як тільки контейнер буде повністю запущений (див. поле Started).

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

    • initContainerStatuses.resources (ResourceRequirements)

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

      ResourceRequirements описує вимоги до обчислювальних ресурсів.

      • initContainerStatuses.resources.claims ([]ResourceClaim)

        Map: унікальні значення ключа name будуть збережені під час злиття

        Claims перелік назв ресурсів, визначених у spec.resourceClaims, які використовуються цим контейнером.

        Це поле альфа-версії і потребує включення функціональної можливості DynamicResourceAllocation.

        Це поле незмінне. Воно може бути встановлено лише для контейнерів.

        ResourceClaim посилається на один запис у PodSpec.ResourceClaims.

        • initContainerStatuses.resources.claims.name (string), обовʼязково

          Name має відповідати назві одного запису в pod.spec.resourceClaims podʼа, де використовується це поле. Це робить ресурс доступним всередині контейнера.

        • initContainerStatuses.resources.claims.request (string)

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

      • initContainerStatuses.resources.limits (map[string]Quantity)

        Limits описує максимальну кількість дозволених обчислювальних ресурсів. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

      • initContainerStatuses.resources.requests (map[string]Quantity)

        Requests описує мінімальну кількість обчислювальних ресурсів, необхідних для контейнера. Якщо Requests не вказано для контейнера, воно стандартно дорівнює Limits, якщо вони явно вказані, інакше — значенню, визначеному реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • initContainerStatuses.restartCount (int32), обовʼязково

      RestartCount містить кількість разів, коли контейнер був перезапущений. Kubelet намагається завжди збільшувати це значення, але є випадки, коли стан може бути втрачено через перезавантаження вузла, і тоді значення може бути скинуто на 0. Значення ніколи не є відʼємним.

    • initContainerStatuses.started (boolean)

      Started вказує, чи контейнер завершив свій хук життєвого циклу postStart і пройшов перевірку запуску. Ініціалізується як false, стає true після того, як перевірка запуску вважається успішною. Скидається на false, коли контейнер перезапускається або якщо kubelet тимчасово втрачає стан. У обох випадках перевірки запуску будуть виконані знову. Завжди true, коли перевірка запуску не визначена і контейнер запущений та пройшов хук життєвого циклу postStart. Значення null слід трактувати так само, як false.

    • initContainerStatuses.state (ContainerState)

      State містить деталі про поточний стан контейнера.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • initContainerStatuses.state.running (ContainerStateRunning)

        Деталі про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • initContainerStatuses.state.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • initContainerStatuses.state.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • initContainerStatuses.state.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • initContainerStatuses.state.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • initContainerStatuses.state.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.state.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.state.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • initContainerStatuses.state.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • initContainerStatuses.state.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • initContainerStatuses.state.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • initContainerStatuses.state.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • initContainerStatuses.state.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • initContainerStatuses.user (ContainerUser)

      User представляє інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнера

      ContainerUser представляє інформацію про ідентифікацію користувача

      • initContainerStatuses.user.linux (LinuxContainerUser)

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

        LinuxContainerUser представляє інформацію про ідентифікацію користувача в контейнерах Linux

        • initContainerStatuses.user.linux.gid (int64), обовʼязково

          GID є основним gid, спочатку прикріпленим до першого процесу в контейнері

        • initContainerStatuses.user.linux.uid (int64), обовʼязково

          UID є основним uid, спочатку прикріпленим до першого процесу в контейнері

        • initContainerStatuses.user.linux.supplementalGroups ([]int64)

          Atomic: буде замінено під час злиття

          SupplementalGroups є додатковими групами, спочатку прикріпленими до першого процесу в контейнері

    • initContainerStatuses.volumeMounts ([]VolumeMountStatus)

      Patch strategy: злиття за ключем mountPath

      Map: унікальні значення ключа mountPath будуть збережені під час злиття

      Стан монтування томів.

      VolumeMountStatus показує стан монтування томів.

      • initContainerStatuses.volumeMounts.mountPath (string), обовʼязково

        MountPath відповідає оригінальному VolumeMount.

      • initContainerStatuses.volumeMounts.name (string), обовʼязково

        Name відповідає назві оригінального VolumeMount.

      • initContainerStatuses.volumeMounts.readOnly (boolean)

        ReadOnly відповідає оригінальному VolumeMount.

      • initContainerStatuses.volumeMounts.recursiveReadOnly (string)

        RecursiveReadOnly має бути встановлено на Disabled, Enabled або unspecified (для монтувань відмінних "тільки для читання"). Значення IfPossible в оригінальному VolumeMount повинно бути перетворено на Disabled або Enabled, залежно від результату монтування.

  • containerStatuses ([]ContainerStatus)

    Atomic: буде замінено під час злиття

    Список містить один запис на кожен контейнер в маніфесті. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status

    ContainerStatus містить деталі поточного стану цього контейнера.

    • containerStatuses.allocatedResources (map[string]Quantity)

      AllocatedResources представляє обчислювальні ресурси, виділені для цього контейнера вузлом. Kubelet встановлює це значення у Container.Resources.Requests після успішного допуску podʼа та після успішного допуску бажаного масштабування podʼа.

    • containerStatuses.allocatedResourcesStatus ([]ResourceStatus)

      Patch strategy: злиття за ключем name

      Map: унікальні значення ключа name будуть збережені під час злиття

      AllocatedResourcesStatus представляє статус різних ресурсів, виділених для цього podʼа.

      **

      • containerStatuses.allocatedResourcesStatus.name (string), обовʼязково

        Назва ресурсу. Має бути унікальною в межах podʼа та відповідати одному з ресурсів зі специфікації podʼа.

      • containerStatuses.allocatedResourcesStatus.resources ([]ResourceHealth)

        Map: унікальні значення ключа resourceID будуть збережені під час злиття

        Список унікальних станів ресурсів. Кожен елемент списку містить унікальний ідентифікатор ресурсу та стан ресурсу. Мінімум, ResourceID має унікально ідентифікувати ресурс, виділений podʼу на вузлі протягом життя podʼа. Дивіться тип ResourceID для його визначення.

        ResourceHealth представляє стан справності ресурсу. Він містить останню інформацію про стан пристрою. Це частина KEP https://kep.k8s.io/4680, і планується додавання історичних змін стану справності в майбутніх ітераціях KEP.

        • containerStatuses.allocatedResourcesStatus.resources.resourceID (string), обовʼязково

          ResourceID є унікальним ідентифікатором ресурсу. Дивіться тип ResourceID для отримання додаткової інформації.

        • containerStatuses.allocatedResourcesStatus.resources.health (string)

          Health ресурсу. Може бути одним з:

          • Healthy: працює нормально
          • Unhealthy: повідомлено про несправний стан. Ми вважаємо це тимчасовою проблемою зі справністю, оскільки наразі у нас немає механізму для розрізнення тимчасових і постійних проблем.
          • Unknown: статус не можна визначити. Наприклад, втулок пристрою було відключено і він не був повторно зареєстрований з того часу.

          В майбутньому ми можемо ввести статус PermanentlyUnhealthy.

    • containerStatuses.containerID (string)

      ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'. Де type є ідентифікатором середовища виконання контейнера, що повертається з виклику Version API CRI (наприклад, "containerd").

    • containerStatuses.image (string), обовʼязково

      Image є назвою образу контейнера з якого запущений у контейнері. Образ контейнера може не збігатися з образом, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання. Докладніше: https://kubernetes.io/docs/concepts/containers/images

    • containerStatuses.imageID (string), обовʼязково

      ImageID є ідентифікатором образу контейнера. Ідентифікатор образу може не збігатися з ідентифікатором образу, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання.

    • containerStatuses.lastState (ContainerState)

      LastTerminationState містить останній стан завершення контейнера, щоб допомогти в налагодженні аварійних зупинок та перезапусків контейнера. Це поле не заповнюється, якщо контейнер все ще запущений і RestartCount дорівнює 0.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • containerStatuses.lastState.running (ContainerStateRunning)

        Відомості про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • containerStatuses.lastState.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • containerStatuses.lastState.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • containerStatuses.lastState.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • containerStatuses.lastState.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • containerStatuses.lastState.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.lastState.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.lastState.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • containerStatuses.lastState.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • containerStatuses.lastState.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • containerStatuses.lastState.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • containerStatuses.lastState.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • containerStatuses.lastState.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • containerStatuses.name (string), обовʼязково

      Name є DNS_LABEL, що представляє унікальну назву контейнера. Кожен контейнер в podʼі повинен мати унікальну назву серед усіх типів контейнерів. Не можна оновити.

    • containerStatuses.ready (boolean), обовʼязково

      Ready вказує, чи контейнер наразі проходить перевірку готовності. Значення змінюватиметься, оскільки перевірки готовності продовжують виконуватися. Якщо перевірки готовності не вказані, це поле стандартно буде true, як тільки контейнер буде повністю запущений (див. поле Started).

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

    • containerStatuses.resources (ResourceRequirements)

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

      ResourceRequirements описує вимоги до обчислювальних ресурсів.

      • containerStatuses.resources.claims ([]ResourceClaim)

        Map: унікальні значення ключа name будуть збережені під час злиття

        Claims перелік назв ресурсів, визначених у spec.resourceClaims, які використовуються цим контейнером.

        Це поле альфа-версії і потребує включення функціональної можливості DynamicResourceAllocation.

        Це поле незмінне. Воно може бути встановлено лише для контейнерів.

        ResourceClaim посилається на один запис у PodSpec.ResourceClaims.

        • containerStatuses.resources.claims.name (string), обовʼязково

          Name має відповідати назві одного запису в pod.spec.resourceClaims podʼа, де використовується це поле. Це робить ресурс доступним всередині контейнера.

        • containerStatuses.resources.claims.request (string)

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

      • containerStatuses.resources.limits (map[string]Quantity)

        Limits описує максимальну кількість дозволених обчислювальних ресурсів. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

      • containerStatuses.resources.requests (map[string]Quantity)

        Requests описує мінімальну кількість обчислювальних ресурсів, необхідних для контейнера. Якщо Requests не вказано для контейнера, воно стандартно дорівнює Limits, якщо вони явно вказані, інакше — значенню, визначеному реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • containerStatuses.restartCount (int32), обовʼязково

      RestartCount містить кількість разів, коли контейнер був перезапущений. Kubelet намагається завжди збільшувати це значення, але є випадки, коли стан може бути втрачено через перезавантаження вузла, і тоді значення може бути скинуто на 0. Значення ніколи не є відʼємним.

    • containerStatuses.started (boolean)

      Started вказує, чи контейнер завершив свій хук життєвого циклу postStart і пройшов перевірку запуску. Ініціалізується як false, стає true після того, як перевірка запуску вважається успішною. Скидається на false, коли контейнер перезапускається або якщо kubelet тимчасово втрачає стан. У обох випадках перевірки запуску будуть виконані знову. Завжди true, коли перевірка запуску не визначена і контейнер запущений та пройшов хук життєвого циклу postStart. Значення null слід трактувати так само, як false.

    • containerStatuses.state (ContainerState)

      State містить деталі про поточний стан контейнера.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • containerStatuses.state.running (ContainerStateRunning)

        Деталі про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • containerStatuses.state.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • containerStatuses.state.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • containerStatuses.state.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • containerStatuses.state.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • containerStatuses.state.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.state.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.state.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • containerStatuses.state.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • containerStatuses.state.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • containerStatuses.state.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • containerStatuses.state.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • containerStatuses.state.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • containerStatuses.user (ContainerUser)

      User представляє інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнера

      ContainerUser представляє інформацію про ідентифікацію користувача

      • containerStatuses.user.linux (LinuxContainerUser)

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

        LinuxContainerUser представляє інформацію про ідентифікацію користувача в контейнерах Linux

        • containerStatuses.user.linux.gid (int64), обовʼязково

          GID є основним gid, спочатку прикріпленим до першого процесу в контейнері

        • containerStatuses.user.linux.uid (int64), обовʼязково

          UID є основним uid, спочатку прикріпленим до першого процесу в контейнері

        • containerStatuses.user.linux.supplementalGroups ([]int64)

          Atomic: буде замінено під час злиття

          SupplementalGroups є додатковими групами, спочатку прикріпленими до першого процесу в контейнері

    • containerStatuses.volumeMounts ([]VolumeMountStatus)

      Patch strategy: злиття за ключем mountPath

      Map: унікальні значення ключа mountPath будуть збережені під час злиття

      Стан монтування томів.

      VolumeMountStatus показує стан монтування томів.

      • containerStatuses.volumeMounts.mountPath (string), обовʼязково

        MountPath відповідає оригінальному VolumeMount.

      • containerStatuses.volumeMounts.name (string), обовʼязково

        Name відповідає назві оригінального VolumeMount.

      • containerStatuses.volumeMounts.readOnly (boolean)

        ReadOnly відповідає оригінальному VolumeMount.

      • containerStatuses.volumeMounts.recursiveReadOnly (string)

        RecursiveReadOnly має бути встановлено на Disabled, Enabled або unspecified (для монтувань відмінних "тільки для читання"). Значення IfPossible в оригінальному VolumeMount повинно бути перетворено на Disabled або Enabled, залежно від результату монтування.

  • ephemeralContainerStatuses ([]ContainerStatus)

    Atomic: буде замінено під час злиття

    Статус будь-яких ефемерних контейнерів, які працювали в цьому Podʼі.

    ContainerStatus містить деталі поточного стану цього контейнера.

    • ephemeralContainerStatuses.allocatedResources (map[string]Quantity)

      AllocatedResources представляє обчислювальні ресурси, виділені для цього контейнера вузлом. Kubelet встановлює це значення у Container.Resources.Requests після успішного допуску podʼа та після успішного допуску бажаного масштабування podʼа.

    • ephemeralContainerStatuses.allocatedResourcesStatus ([]ResourceStatus)

      Patch strategy: злиття за ключем name

      Map: унікальні значення ключа name будуть збережені під час злиття

      AllocatedResourcesStatus представляє статус різних ресурсів, виділених для цього podʼа.

      **

      • ephemeralContainerStatuses.allocatedResourcesStatus.name (string), обовʼязково

        Назва ресурсу. Має бути унікальною в межах podʼа та відповідати одному з ресурсів зі специфікації podʼа.

      • ephemeralContainerStatuses.allocatedResourcesStatus.resources ([]ResourceHealth)

        Map: унікальні значення ключа resourceID будуть збережені під час злиття

        Список унікальних станів ресурсів. Кожен елемент списку містить унікальний ідентифікатор ресурсу та стан ресурсу. Мінімум, ResourceID має унікально ідентифікувати ресурс, виділений podʼу на вузлі протягом життя podʼа. Дивіться тип ResourceID для його визначення.

        ResourceHealth представляє стан справності ресурсу. Він містить останню інформацію про стан пристрою. Це частина KEP https://kep.k8s.io/4680, і планується додавання історичних змін стану справності в майбутніх ітераціях KEP.

        • ephemeralContainerStatuses.allocatedResourcesStatus.resources.resourceID (string), обовʼязково

          ResourceID є унікальним ідентифікатором ресурсу. Дивіться тип ResourceID для отримання додаткової інформації.

        • ephemeralContainerStatuses.allocatedResourcesStatus.resources.health (string)

          Health ресурсу. Може бути одним з:

          • Healthy: працює нормально
          • Unhealthy: повідомлено про несправний стан. Ми вважаємо це тимчасовою проблемою зі справністю, оскільки наразі у нас немає механізму для розрізнення тимчасових і постійних проблем.
          • Unknown: статус не можна визначити. Наприклад, втулок пристрою було відключено і він не був повторно зареєстрований з того часу.

          В майбутньому ми можемо ввести статус PermanentlyUnhealthy.

    • ephemeralContainerStatuses.containerID (string)

      ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'. Де type є ідентифікатором середовища виконання контейнера, що повертається з виклику Version API CRI (наприклад, "containerd").

    • ephemeralContainerStatuses.image (string), обовʼязково

      Image є назвою образу контейнера з якого запущений у контейнері. Образ контейнера може не збігатися з образом, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання. Докладніше: https://kubernetes.io/docs/concepts/containers/images

    • ephemeralContainerStatuses.imageID (string), обовʼязково

      ImageID є ідентифікатором образу контейнера. Ідентифікатор образу може не збігатися з ідентифікатором образу, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання.

    • ephemeralContainerStatuses.lastState (ContainerState)

      LastTerminationState містить останній стан завершення контейнера, щоб допомогти в налагодженні аварійних зупинок та перезапусків контейнера. Це поле не заповнюється, якщо контейнер все ще запущений і RestartCount дорівнює 0.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • ephemeralContainerStatuses.lastState.running (ContainerStateRunning)

        Відомості про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • ephemeralContainerStatuses.lastState.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • ephemeralContainerStatuses.lastState.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • ephemeralContainerStatuses.lastState.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • ephemeralContainerStatuses.lastState.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • ephemeralContainerStatuses.lastState.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.lastState.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.lastState.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • ephemeralContainerStatuses.lastState.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • ephemeralContainerStatuses.lastState.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • ephemeralContainerStatuses.lastState.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • ephemeralContainerStatuses.lastState.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • ephemeralContainerStatuses.lastState.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • ephemeralContainerStatuses.name (string), обовʼязково

      Name є DNS_LABEL, що представляє унікальну назву контейнера. Кожен контейнер в podʼі повинен мати унікальну назву серед усіх типів контейнерів. Не можна оновити.

    • ephemeralContainerStatuses.ready (boolean), обовʼязково

      Ready вказує, чи контейнер наразі проходить перевірку готовності. Значення змінюватиметься, оскільки перевірки готовності продовжують виконуватися. Якщо перевірки готовності не вказані, це поле стандартно буде true, як тільки контейнер буде повністю запущений (див. поле Started).

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

    • ephemeralContainerStatuses.resources (ResourceRequirements)

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

      ResourceRequirements описує вимоги до обчислювальних ресурсів.

      • ephemeralContainerStatuses.resources.claims ([]ResourceClaim)

        Map: унікальні значення ключа name будуть збережені під час злиття

        Claims перелік назв ресурсів, визначених у spec.resourceClaims, які використовуються цим контейнером.

        Це поле альфа-версії і потребує включення функціональної можливості DynamicResourceAllocation.

        Це поле незмінне. Воно може бути встановлено лише для контейнерів.

        ResourceClaim посилається на один запис у PodSpec.ResourceClaims.

        • ephemeralContainerStatuses.resources.claims.name (string), обовʼязково

          Name має відповідати назві одного запису в pod.spec.resourceClaims podʼа, де використовується це поле. Це робить ресурс доступним всередині контейнера.

        • ephemeralContainerStatuses.resources.claims.request (string)

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

      • ephemeralContainerStatuses.resources.limits (map[string]Quantity)

        Limits описує максимальну кількість дозволених обчислювальних ресурсів. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

      • ephemeralContainerStatuses.resources.requests (map[string]Quantity)

        Requests описує мінімальну кількість обчислювальних ресурсів, необхідних для контейнера. Якщо Requests не вказано для контейнера, воно стандартно дорівнює Limits, якщо вони явно вказані, інакше — значенню, визначеному реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • ephemeralContainerStatuses.restartCount (int32), обовʼязково

      RestartCount містить кількість разів, коли контейнер був перезапущений. Kubelet намагається завжди збільшувати це значення, але є випадки, коли стан може бути втрачено через перезавантаження вузла, і тоді значення може бути скинуто на 0. Значення ніколи не є відʼємним.

    • ephemeralContainerStatuses.started (boolean)

      Started вказує, чи контейнер завершив свій хук життєвого циклу postStart і пройшов перевірку запуску. Ініціалізується як false, стає true після того, як перевірка запуску вважається успішною. Скидається на false, коли контейнер перезапускається або якщо kubelet тимчасово втрачає стан. У обох випадках перевірки запуску будуть виконані знову. Завжди true, коли перевірка запуску не визначена і контейнер запущений та пройшов хук життєвого циклу postStart. Значення null слід трактувати так само, як false.

    • ephemeralContainerStatuses.state (ContainerState)

      State містить деталі про поточний стан контейнера.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • ephemeralContainerStatuses.state.running (ContainerStateRunning)

        Деталі про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • ephemeralContainerStatuses.state.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • ephemeralContainerStatuses.state.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • ephemeralContainerStatuses.state.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • ephemeralContainerStatuses.state.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • ephemeralContainerStatuses.state.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.state.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.state.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • ephemeralContainerStatuses.state.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • ephemeralContainerStatuses.state.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • ephemeralContainerStatuses.state.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • ephemeralContainerStatuses.state.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • ephemeralContainerStatuses.state.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • ephemeralContainerStatuses.user (ContainerUser)

      User представляє інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнера

      ContainerUser представляє інформацію про ідентифікацію користувача

      • ephemeralContainerStatuses.user.linux (LinuxContainerUser)

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

        LinuxContainerUser представляє інформацію про ідентифікацію користувача в контейнерах Linux

        • ephemeralContainerStatuses.user.linux.gid (int64), обовʼязково

          GID є основним gid, спочатку прикріпленим до першого процесу в контейнері

        • ephemeralContainerStatuses.user.linux.uid (int64), обовʼязково

          UID є основним uid, спочатку прикріпленим до першого процесу в контейнері

        • ephemeralContainerStatuses.user.linux.supplementalGroups ([]int64)

          Atomic: буде замінено під час злиття

          SupplementalGroups є додатковими групами, спочатку прикріпленими до першого процесу в контейнері

    • ephemeralContainerStatuses.volumeMounts ([]VolumeMountStatus)

      Patch strategy: злиття за ключем mountPath

      Map: унікальні значення ключа mountPath будуть збережені під час злиття

      Стан монтування томів.

      VolumeMountStatus показує стан монтування томів.

      • ephemeralContainerStatuses.volumeMounts.mountPath (string), обовʼязково

        MountPath відповідає оригінальному VolumeMount.

      • ephemeralContainerStatuses.volumeMounts.name (string), обовʼязково

        Name відповідає назві оригінального VolumeMount.

      • ephemeralContainerStatuses.volumeMounts.readOnly (boolean)

        ReadOnly відповідає оригінальному VolumeMount.

      • ephemeralContainerStatuses.volumeMounts.recursiveReadOnly (string)

        RecursiveReadOnly має бути встановлено на Disabled, Enabled або unspecified (для монтувань відмінних "тільки для читання"). Значення IfPossible в оригінальному VolumeMount повинно бути перетворено на Disabled або Enabled, залежно від результату монтування.

  • 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ʼа в просторі імен podʼа. Якщо це поле не встановлено, то створення ResourceClaim не було необхідним. У цьому випадку запис pod.spec.resourceClaims можна ігнорувати.

  • resize (string)

    Статус бажаної зміни розміру ресурсів для контейнерів Podʼа. Він порожній, якщо немає очікуваної зміни розміру ресурсів. Будь-які зміни в ресурсах контейнера автоматично встановлять це на "Proposed".

PodList

PodList — це список Podʼів.

Операції

get отримати вказаний Pod

HTTP запит

GET /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

401: Unauthorized

get отримати ефемерні контейнери вказаного Podʼа

HTTP запит

GET /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

401: Unauthorized

get отримати лог вказаного Podʼа

HTTP запит

GET /api/v1/namespaces/{namespace}/pods/{name}/log

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • container (у запиті): string

    Контейнер, для якого потрібно виводити логи. Стандартно виводяться тільки логи контейнера, якщо в Podʼі є тільки один контейнер.

  • follow (у запиті): boolean

    Слідкувати за потоком логу Podʼа. Стандартне значення — false.

  • insecureSkipTLSVerifyBackend (у запиті): boolean

    insecureSkipTLSVerifyBackend вказує, що apiserver не повинен підтверджувати дійсність сертифікату обслуговуючого програмного забезпечення, з яким він зʼєднується. Це зробить HTTPS-зʼєднання між apiserver та обслуговуючим програмним забезпеченням ненадійним. Це означає, що apiserver не може підтвердити, що дані логу, які він отримує, отримано від реального kubelet. Якщо kubelet налаштований для підтвердження уповноваження TLS apiserver, це не означає, що зʼєднання з реальним kubelet вразливе до атаки посередника (наприклад, зловмисник не зможе перехопити фактичні дані логу, що надходять від реального kubelet).

  • limitBytes (у запиті): integer

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

  • pretty (у запиті): string

    pretty

  • previous (у запиті): boolean

    Повертати логи попередньо завершених контейнерів. Стандартне значення — 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

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Pod

HTTP запит

GET /api/v1/namespaces/{namespace}/pods

Параметри

Відповідь

200 (PodList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Pod

HTTP запит

GET /api/v1/pods

Параметри

Відповідь

200 (PodList): OK

401: Unauthorized

create створення Podʼа

HTTP запит

POST /api/v1/namespaces/{namespace}/pods

Параметри

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

202 (Pod): Accepted

401: Unauthorized

update заміна вказаного Podʼа

HTTP запит

PUT /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

update заміна ephemeralcontainers вказаного Podʼа

HTTP запит

PUT /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

update заміна статусу вказаного Podʼа

HTTP запит

PUT /api/v1/namespaces/{namespace}/pods/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

patch часткове оновлення вказаного Podʼа

HTTP запит

PATCH /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

patch часткове оновлення ephemeralcontainers вказаного Podʼа

HTTP запит

PATCH /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Podʼа

HTTP запит

PATCH /api/v1/namespaces/{namespace}/pods/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

delete видалення Pod

HTTP запит

DELETE /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (у запиті): string

    dryRun

  • gracePeriodSeconds (у запиті): integer

    gracePeriodSeconds

  • pretty (у запиті): string

    pretty

  • propagationPolicy (у запиті): string

    propagationPolicy

Відповідь

200 (Pod): OK

202 (Pod): Accepted

401: Unauthorized

deletecollection видалення колекції Podʼів

HTTP запит

DELETE /api/v1/namespaces/{namespace}/pods

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.2 - Binding

Звʼязування привʼязує один обʼєкт до іншого; наприклад, Pod привʼязується до вузла планувальником.

apiVersion: v1

import "k8s.io/api/core/v1"

Binding

Binding звʼязує один обʼєкт з іншим; наприклад, Pod звʼязується з вузлом за допомогою планувальника. Застаріло у версії 1.7, будь ласка, використовуйте субресурс bindings для Podʼів замість цього.

Операції

create створення Binding

HTTP запит

POST /api/v1/namespaces/{namespace}/bindings

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Binding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Binding): OK

201 (Binding): Created

202 (Binding): Accepted

401: Unauthorized

create створення звʼязування для Pod

HTTP запит

POST /api/v1/namespaces/{namespace}/pods/{name}/binding

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Binding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Binding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Binding): OK

201 (Binding): Created

202 (Binding): Accepted

401: Unauthorized

5.1.3 - PodTemplate

PodTemplate описує шаблон для створення копій наперед визначеного Podʼа.

apiVersion: v1

import "k8s.io/api/core/v1"

PodTemplate

PodTemplate описує шаблон для створення копій наперед визначеного Podʼа.

PodTemplateList

PodTemplateList — список PodTemplate.

Операції

get прочитати вказаний PodTemplate

HTTP-запит

GET /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodTemplate): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodTemplate

HTTP-запит

GET /api/v1/namespaces/{namespace}/podtemplates

Параметри

Відповідь

200 (PodTemplateList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodTemplate

HTTP-запит

GET /api/v1/podtemplates

Параметри

Відповідь

200 (PodTemplateList): OK

401: Unauthorized

create створення PodTemplate

HTTP-запит

POST /api/v1/namespaces/{namespace}/podtemplates

Параметри

Відповідь

200 (PodTemplate): OK

201 (PodTemplate): Created

202 (PodTemplate): Accepted

401: Unauthorized

update замінити вказаний PodTemplate

HTTP-запит

PUT /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodTemplate, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodTemplate): OK

201 (PodTemplate): Created

401: Unauthorized

patch частково оновити вказаний PodTemplate

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodTemplate): OK

201 (PodTemplate): Created

401: Unauthorized

delete видалити PodTemplate

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (PodTemplate): OK

202 (PodTemplate): Accepted

401: Unauthorized

deletecollection видалити колекцію PodTemplate

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/podtemplates

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.4 - ReplicationController

ReplicationController представляє конфігураці. контролера реплікації.

apiVersion: v1

import "k8s.io/api/core/v1"

ReplicationController

ReplicationController представляє конфігурацію контролера реплікації.

ReplicationControllerSpec

ReplicationControllerSpec — це специфікація контролера реплікації.

  • selector (map[string]string)

    Selector — це запит міток (label query) з Podʼів, які повинні відповідати кількості реплік. Якщо Selector порожній, стандартно встановлюються мітки, які присутні в шаблоні Pod. Ключі та значення міток, які повинні збігатись для контролю цим контролером реплікації, за відсутності стандартних значень встановлюються мітки з шаблону Pod. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec)

    Template — це обʼєкт, який описує Pod, який буде створений у разі виявлення недостатньої кількості реплік. Це має перевагу над TemplateRef. Єдине дозволене значення template.spec.restartPolicy — "Always". Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

  • replicas (int32)

    Replicas — це кількість бажаних реплік. Це вказівка для розрізнення між явним нульовим значенням та невказаною кількістю. Стандартне значення — 1. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)

ReplicationControllerStatus

ReplicationControllerStatus представляє поточний статус контролера реплікації.

  • replicas (int32), обовʼязково

    Replicas — це найновіша зафіксована кількість реплік. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller

  • availableReplicas (int32)

    Кількість доступних реплік (готових принаймні протягом minReadySeconds) для цього контролера реплікації.

  • readyReplicas (int32)

    Кількість готових реплік для цього контролера реплікації.

  • fullyLabeledReplicas (int32)

    Кількість Podʼів, які мають мітки, що відповідають міткам шаблону Pod контролера реплікації.

  • conditions ([]ReplicationControllerCondition)

    Patch strategy: обʼєднання за ключем type

    Map: унікальні значення ключа 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 — це колекція контролерів реплікації.

Операції

get читання вказаного ReplicationController

HTTP-запит

GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

401: Unauthorized

get читання статусу вказаного ReplicationController

HTTP-запит

GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

401: Unauthorized

list перелік або спостереження за обʼєктами типу ReplicationController

HTTP-запит

GET /api/v1/namespaces/{namespace}/replicationcontrollers

Параметри

Відповідь

200 (ReplicationControllerList): ОК

401: Unauthorized

list перелік або спостереження за обʼєктами типу ReplicationController

HTTP-запит

GET /api/v1/replicationcontrollers

Параметри

Відповідь

200 (ReplicationControllerList): ОК

401: Unauthorized

create створення ReplicationController

HTTP-запит

POST /api/v1/namespaces/{namespace}/replicationcontrollers

Параметри

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

202 (ReplicationController): Accepted

401: Unauthorized

update заміна вказаного ReplicationController

HTTP-запит

PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicationController, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

update заміна статусу вказаного ReplicationController

HTTP-запит

PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicationController, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

patch часткове оновлення вказаного ReplicationController

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ReplicationController

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

delete видалення ReplicationController

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ReplicationController

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/replicationcontrollers

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

5.1.5 - ReplicaSet

ReplicaSet забезпечує, що в будь-який момент часу задана кількість реплік Podʼів працює.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ReplicaSet

ReplicaSet забезпечує, що в будь-який момент часу задана кількість реплік Podʼів працює.

ReplicaSetSpec

ReplicaSetSpec — це специфікація ReplicaSet.

  • selector (LabelSelector), обовʼязково

    Селектор — це запит міток до Podʼів, які повинні відповідати кількості реплік. Ключі міток та їх значення, які повинні відповідати, щоб ними керував цей ReplicaSet. Вони повинні відповідати міткам шаблону Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec)

    Шаблон — це обʼєкт, що описує Pod, який буде створений, якщо виявлено недостатню кількість реплік. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

  • replicas (int32)

    Replicas — це бажана кількість реплік. Це вказівник для розрізнювання між явною нульовою та невизначеною кількістю. Стандартне значення — 1. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)

ReplicaSetStatus

ReplicaSetStatus відображає поточний стан ReplicaSet.

  • replicas (int32), обовʼязково

    Replicas — це остання зафіксована кількість реплік. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

  • availableReplicas (int32)

    Кількість доступних реплік (готових протягом принаймні minReadySeconds) для цього набору реплік.

  • readyReplicas (int32)

    readyReplicas — це кількість Podʼів в стані Ready, на які спрямовується цей ReplicaSet.

  • fullyLabeledReplicas (int32)

    Кількість Podʼів, які мають мітки, що відповідають міткам шаблону Podʼа набору реплік.

  • conditions ([]ReplicaSetCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа 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.

ReplicaSetList

ReplicaSetList — це колекція ReplicaSets.

Операції

get зчитування вказаного ReplicaSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

401: Unauthorized

get зчитування статусу вказаного ReplicaSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

401: Unauthorized

list список або перегляд обʼєктів типу ReplicaSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/replicasets

Параметри

Відповідь

200 (ReplicaSetList): OK

401: Unauthorized

list список або перегляд обʼєктів типу ReplicaSet

HTTP-запит

GET /apis/apps/v1/replicasets

Параметри

Відповідь

200 (ReplicaSetList): OK

401: Unauthorized

create створення ReplicaSet

HTTP-запит

POST /apis/apps/v1/namespaces/{namespace}/replicasets

Параметри

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

202 (ReplicaSet): Accepted

401: Unauthorized

update заміна вказаного ReplicaSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicaSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

update заміна статусу вказаного ReplicaSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicaSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

patch часткове оновлення вказаного ReplicaSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ReplicaSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

delete видалення ReplicaSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ReplicaSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/replicasets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.6 - Deployment

Deployment робить можливими декларативні оновлення для Podʼів та and ReplicaSet.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

Deployment

Deployment робить можливими декларативні оновлення для Podʼів та ReplicaSet.

DeploymentSpec

DeploymentSpec є специфікацією бажаної поведінки Deployment.

  • selector (LabelSelector), обовʼязково

    Селектор міток для Podʼів. Наявні ReplicaSets, чиї Podʼи вибрані за допомогою цього селектора, будуть ті, які будуть змінені цим Deployment. Він повинен відповідати міткам шаблону Podʼа.

  • template (PodTemplateSpec), обовʼязково

    Шаблон описує 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, яке може приймати імʼя або число.

      • strategy.rollingUpdate.maxUnavailable (IntOrString)

        Максимальна кількість 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

    Map: унікальні значення ключа 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.

DeploymentList

DeploymentList - це список обʼєктів Deployment.

  • apiVersion: apps/v1

  • kind: DeploymentList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]Deployment), обовʼязково

    Items — це список обʼєктів Deployment.

Операції

get отримати вказаний Deployment

HTTP Запит

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Deployment

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Deployment): ОК

401: Unauthorized

get отримати статус вказаного Deployment

HTTP Запит

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва Deployment

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Deployment): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Deployment

HTTP Запит

GET /apis/apps/v1/namespaces/{namespace}/deployments

Параметри

Відповідь

200 (DeploymentList): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Deployment

HTTP Запит

GET /apis/apps/v1/deployments

Параметри

Відповідь

200 (DeploymentList): ОК

401: Unauthorized

create створення Deployment

HTTP Запит

POST /apis/apps/v1/namespaces/{namespace}/deployments

Параметри

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

202 (Deployment): Accepted

401: Unauthorized

update заміна вказаного Deployment

HTTP Запит

PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Deployment, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

update заміна статусу вказаного Deployment

HTTP Запит

PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Deployment, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

patch часткове оновлення вказаного Deployment

HTTP Запит

PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Deployment

HTTP Запит

PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

delete видалення Deployment

HTTP Запит

DELETE /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (у запиті): string

    dryRun

  • gracePeriodSeconds (у запиті): integer

    gracePeriodSeconds

  • pretty (у запиті): string

    pretty

  • propagationPolicy (у запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Deployment

HTTP Запит

DELETE /apis/apps/v1/namespaces/{namespace}/deployments

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

5.1.7 - StatefulSet

StatefulSet представляє набір Podʼів з постійною ідентичністю.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

StatefulSet

StatefulSet представляє набір Podʼів з постійною ідентичністю. Ідентичність визначається як:

  • Мережа: єдине стабільне DNS та імʼя хосту.
  • Сховище: Стільки VolumeClaims, скільки потрібно.

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.

  • selector (LabelSelector), обовʼязково

    selector — це запит міток для Podʼів, які повинні відповідати кількості реплік. Він повинен відповідати міткам шаблону Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec), обовʼязково

    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.

    • updateStrategy.rollingUpdate (RollingUpdateStatefulSetStrategy)

      RollingUpdate використовується для передачі параметрів, коли Type є RollingUpdateStatefulSetStrategyType.

      RollingUpdateStatefulSetStrategy використовується для передачі параметрів для RollingUpdateStatefulSetStrategyType.

      • updateStrategy.rollingUpdate.maxUnavailable (IntOrString)

        Максимальна кількість 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 ([]PersistentVolumeClaim)

    Atomic: буде замінено під час злиття

    volumeClaimTemplates — це список запитів, до яких Podʼи можуть звертатися. Контролер StatefulSet відповідає за призначення мережевих ідентичностей запитам таким чином, щоб зберігати ідентичність Podʼа. Кожен запит у цьому списку повинен мати принаймні один відповідний (за імʼям) volumeMount в одному з контейнерів в шаблоні. Запит у цьому списку має пріоритет над будь-якими volumes у шаблоні з таким самим імʼям.

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)

  • persistentVolumeClaimRetentionPolicy (StatefulSetPersistentVolumeClaimRetentionPolicy)

    persistentVolumeClaimRetentionPolicy описує життєвий цикл запитів на постійні томи, створених з volumeClaimTemplates. Стандартно усі запити на постійні томи створюються за необхідності та зберігаються до ручного видалення. Ця політика дозволяє змінювати життєвий цикл, наприклад, видаляючи запити на постійні томи під час видалення їх StatefulSet або при масштабуванні вниз Podʼів. Для цього потрібно включити функцію StatefulSetAutoDeletePVC, яка є бета-рівнем.

    StatefulSetPersistentVolumeClaimRetentionPolicy описує політику, яка використовується для PVC, створених з VolumeClaimTemplates StatefulSet.

    • persistentVolumeClaimRetentionPolicy.whenDeleted (string)

      WhenDeleted визначає, що відбувається з PVC, створеними з VolumeClaimTemplates StatefulSet, коли StatefulSet видаляється. Стандартна політика Retain призводить до того, що на PVC не впливає видалення StatefulSet. Політика Delete призводить до видалення таких PVC.

    • persistentVolumeClaimRetentionPolicy.whenScaled (string)

      WhenScaled визначає, що відбувається з PVC, створеними з VolumeClaimTemplates StatefulSet, коли StatefulSet масштабується вниз. Стандартна політика Retain призводить до того, що на PVC не впливає масштабування вниз. Політика Delete призводить до видалення відповідних PVC для будь-яких зайвих Podʼів, що перевищують кількість реплік.

  • ordinals (StatefulSetOrdinals)

    ordinals контролює нумерацію індексів реплік у StatefulSet. Стандартна поведінка ordinals призначає індекс "0" першій репліці та збільшує індекс на одиницю для кожної додаткової запитаної репліки.

    StatefulSetOrdinals описує політику, яка використовується для призначення порядкових номерів реплік у цьому StatefulSet.

    • ordinals.start (int32)

      start — це число, що представляє індекс першої репліки. Його можна використовувати для нумерації реплік з альтернативного індексу (наприклад, з 1) замість стандартної індексації з 0, або для організації поступового переміщення реплік з одного StatefulSet до іншого. Якщо встановлено, індекси реплік будуть у діапазоні:

      • [.spec.ordinals.start, .spec.ordinals.start + .spec.replicas].

      Якщо не встановлено, стандартне значення — 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

    Map: унікальні значення ключа 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.

StatefulSetList

StatefulSetList — це колекція StatefulSet.

Операції

get отримати вказаний StatefulSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

401: Unauthorized

get отримати статус вказаного StatefulSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StatefulSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/statefulsets

Параметри

Відповідь

200 (StatefulSetList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StatefulSet

HTTP-запит

GET /apis/apps/v1/statefulsets

Параметри

Відповідь

200 (StatefulSetList): OK

401: Unauthorized

create створення StatefulSet

HTTP-запит

POST /apis/apps/v1/namespaces/{namespace}/statefulsets

Параметри

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

202 (StatefulSet): Accepted

401: Unauthorized

update заміна вказаного StatefulSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: StatefulSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

update заміна статусу вказаного StatefulSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: StatefulSet, обовʼязково

  • dryRun (в запиті): string

    [dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

patch часткове оновлення вказаного StatefulSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

patch часткове оновлення статусу вказакного StatefulSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status

Параметри

  • name (в запиті): string, обовʼязково

    назва StatefulSet

  • namespace (в запиті): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

delete видалення StatefulSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції StatefulSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.8 - ControllerRevision

ControllerRevision впроваджує незмінюваний знімок даних стану.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ControllerRevision

ControllerRevision впроваджує незмінюваний знімок даних стану. Клієнти відповідають за серіалізацію та десеріалізацію обʼєктів, які містять їх внутрішній стан. Після успішного створення ControllerRevision, його не можна оновити. API Server не пройде валідацію всіх запитів, які намагаються змінити поле Data. Однак ControllerRevision може бути видалено. Зверніть увагу, що через використання цього обʼєкта обома контролерами DaemonSet і StatefulSet для оновлення та відкату, він знаходиться на стадії бета-тестування. З усім тим, його назва та представлення можуть змінюватися в майбутніх версіях, і клієнти не повинні покладатися на його стабільність. Він призначений головним чином для внутрішнього використання контролерами.

  • apiVersion: apps/v1

  • kind: ControllerRevision

  • metadata (ObjectMeta)

    Стаціонарні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • revision (int64), обовʼязково

    поле 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 буде виглядати приблизно так:

    {
  "kind":"MyAPIObject",
  "apiVersion":"v1",
  "myPlugin": {
    "kind":"PluginA",
    "aOption":"foo",
  },
}

    Що ж відбувається? Спочатку декодування використовує json або yaml для перетворення серіалізованих даних у вашу зовнішню структуру MyAPIObject. Це призводить до збереження сирого JSON, але не до його розпакування. Наступним кроком є копіювання (використовуючи pkg/conversion) у внутрішню структуру. У пакеті runtime, функції перетворення, встановлені в DefaultScheme, розпакують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, якщо обʼєкт невідомого типу, буде створено обʼєкт runtime.Unknown і збережено.)

ControllerRevisionList

ControllerRevisionList — це ресурс, що містить список обʼєктів ControllerRevision.

Операції

get отримати вказаний ControllerRevision

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ControllerRevision

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ControllerRevision): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ControllerRevision

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/controllerrevisions

Параметри

Відповідь

200 (ControllerRevisionList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ControllerRevision

HTTP-запит

GET /apis/apps/v1/controllerrevisions

Параметри

Відповідь

200 (ControllerRevisionList): OK

401: Unauthorized

create створення ControllerRevision

HTTP-запит

POST /apis/apps/v1/namespaces/{namespace}/controllerrevisions

Параметри

Відповідь

200 (ControllerRevision): OK

201 (ControllerRevision): Created

202 (ControllerRevision): Accepted

401: Unauthorized

update зміна вказаного ControllerRevision

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ControllerRevision

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ControllerRevision, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ControllerRevision): OK

201 (ControllerRevision): Created

401: Unauthorized

patch часткове оновлення вказаного ControllerRevision

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ControllerRevision

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ControllerRevision): OK

201 (ControllerRevision): Created

401: Unauthorized

delete видалення ControllerRevision

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя ControllerRevision

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ControllerRevision

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/controllerrevisions

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.9 - DaemonSet

DaemonSet представляє налаштування набору фонових служб (демонів).

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

DaemonSet

DaemonSet представляє налаштування набору фонових служб (демонів).

DaemonSetSpec

DaemonSetSpec є специфікацією DaemonSet.

  • selector (LabelSelector), обовʼязково

    Запит міток для Podʼів, якими керує набір демонів. Має мати збіг з міткам шаблону Pod. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec), обовʼязково

    Обʼєкт, який описує 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.

    • updateStrategy.rollingUpdate (RollingUpdateDaemonSet)

      Налаштування параметрів постійного оновлення. Присутній тільки якщо type = "RollingUpdate".

      Spec для контролю небхідної поведінки постійного оновлення набору демонів.

      • updateStrategy.rollingUpdate.maxSurge (IntOrString)

        Максимальна кількість вузлів з навним доступним 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, яке може приймати імʼя або число.

      • updateStrategy.rollingUpdate.maxUnavailable (IntOrString)

        Максимальна кількість 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).

  • numberMisscheduled (int32), обовʼязково

    Кількість вузлів, на яких запущений Pod демона, але вони не повинні його виконувати. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

  • desiredNumberScheduled (int32), обовʼязково

    Загальна кількість вузлів, на яких має бути запущений Pod демона (включаючи вузли, на яких Pod демона вже правильно запущений). Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

  • currentNumberScheduled (int32), обовʼязково

    Кількість вузлів, на яких запущено принаймні один Pod демона і які повинні виконувати Pod демона. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

  • updatedNumberScheduled (int32)

    Загальна кількість вузлів, на яких запущено оновлений Pod демона.

  • collisionCount (int32)

    Кількість колізій хешів для DaemonSet. Контролер DaemonSet використовує це поле як механізм уникнення колізій при створенні імені для найновішого ControllerRevision.

  • conditions ([]DaemonSetCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа 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)

    Останнє покоління, яке спостерігається контролером набору демонів.

DaemonSetList

DaemonSetList є колекцією DaemonSet.

Операції

get отримати вказаний DaemonSet

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва DaemonSet.

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

401: Unauthorized

get отримати статус вказаного DaemonSet

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу DaemonSet

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/daemonsets

Параметри

Відповідь

200 (DaemonSetList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу DaemonSet

HTTP запит

GET /apis/apps/v1/daemonsets

Параметри

Відповідь

200 (DaemonSetList): OK

401: Unauthorized

create створення DaemonSet

HTTP запит

POST /apis/apps/v1/namespaces/{namespace}/daemonsets

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DaemonSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

202 (DaemonSet): Accepted

401: Unauthorized

update заміна вказаного DaemonSet

HTTP запит

PUT /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DaemonSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

update заміна статусу вказаного DaemonSet

HTTP запит

PUT /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DaemonSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

patch часткове оновлення вказаного DaemonSet

HTTP запит

PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

patch часткове оновлення статусу вказаного DaemonSet

HTTP запит

PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

delete видалення DaemonSet

HTTP запит

DELETE /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції DaemonSet

HTTP запит

DELETE /apis/apps/v1/namespaces/{namespace}/daemonsets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.10 - Job

Job представляє конфігурацію окремого завдання.

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

Job

Job представляє конфігурацію окремого завдання.

JobSpec

JobSpec описує, як виглядатиме виконання завдання.

Репліки

  • template (PodTemplateSpec), обовʼязково

    Описує pod, який буде створено під час виконання завдання. Єдині дозволені значення template.spec.restartPolicy — "Never" або "OnFailure". Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

  • parallelism (int32)

    Визначає максимальну бажану кількість 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.

Селектор

  • selector (LabelSelector)

    Запит до міток на Podʼах, які повинні відповідати кількості Podʼів. Зазвичай система встановлює це поле для вас. Детальніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • manualSelector (boolean)

    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.

    PodFailurePolicy описує, як невдалі Podʼи впливають на backoffLimit.

    • podFailurePolicy.rules ([]PodFailurePolicyRule), обовʼязково

      Atomic: буде замінено під час обʼєднання

      Список правил політики невдач Podʼів. Правила оцінюються послідовно. Як тільки правило відповідає невдачі Podʼа, решта правил ігнорується. Якщо жодне правило не відповідає невдачі Podʼа, застосовується стандартна обробка — лічильник невдач Podʼів збільшується і перевіряється з backoffLimit. Максимально дозволено 20 елементів.

      PodFailurePolicyRule описує, як обробляється невдача Podʼа, коли виконуються вимоги. Одне з onExitCodes і onPodConditions, але не обидва, можуть бути використані в кожному правилі.

      • podFailurePolicy.rules.action (string), обовʼязково

        Визначає дію, яка виконується при невдачі Podʼа, коли виконуються вимоги. Можливі значення:

        • FailJob: означає, що завдання Podʼа позначається як Failed і всі запущені Podʼи завершуються.
        • FailIndex: означає, що індекс Podʼа позначається як Failed і не буде перезапущений. Це значення рівня бета. Воно може бути використане, коли ввімкнено прапорець JobBackoffLimitPerIndex (стандартно увімкнено).
        • Ignore: означає, що лічильник по відношенню до .backoffLimit не збільшується і створюється Pod заміна.
        • Count: означає, що Pod обробляється стандартним способом — лічильник .backoffLimit збільшується.

        Додаткові значення можуть бути додані в майбутньому. Клієнти повинні реагувати на невідому дію, пропускаючи правило.

      • podFailurePolicy.rules.onExitCodes (PodFailurePolicyOnExitCodesRequirement)

        Представляє вимогу до кодів завершення контейнера.

        PodFailurePolicyOnExitCodesRequirement описує вимогу для обробки невдалого Podʼа на основі кодів завершення його контейнера. Зокрема, перевіряється .state.terminated.exitCode для кожного контейнера застосунку та init-контейнера, представленого полями .status.containerStatuses і .status.initContainerStatuses у статусі Podʼа відповідно. Контейнери, завершені успішно (код завершення 0), виключаються з перевірки вимоги.

        • podFailurePolicy.rules.onExitCodes.operator (string), обовʼязково

          Представляє стосунок між кодом(ами) завершення контейнера та зазначеними значеннями. Контейнери, завершені успішно (код завершення 0), виключаються з перевірки вимоги. Можливі значення:

          • In: вимога задовольняється, якщо хоча б один код завершення контейнера (може бути кілька, якщо є кілька контейнерів, не обмежених полем 'containerName') входить до набору зазначених значень.
          • NotIn: вимога задовольняється, якщо хоча б один код завершення контейнера (може бути кілька, якщо є кілька контейнерів, не обмежених полем 'containerName') не входить до набору зазначених значень.

          Додаткові значення можуть бути додані в майбутньому. Клієнти повинні реагувати на невідомий оператор, вважаючи, що вимога не задоволена.

        • podFailurePolicy.rules.onExitCodes.values ([]int32), обовʼязково

          Set: унікальні значення зберігатимуться під час обʼєднання

          Визначає набір значень. Кожен повернутий код завершення контейнера (може бути кілька у випадку кількох контейнерів) перевіряється щодо цього набору значень з урахуванням оператора. Список значень має бути впорядкованим і не містити дублікатів. Значення '0' не може бути використано для оператора In. Потрібен принаймні один елемент. Максимально дозволено 255 елементів.

        • podFailurePolicy.rules.onExitCodes.containerName (string)

          Обмежує перевірку кодів завершення контейнера контейнером з зазначеним імʼям. Коли null, правило застосовується до всіх контейнерів. Коли зазначено, воно має відповідати одному з імен контейнерів або init-контейнерів у шаблоні Podʼа.

      • podFailurePolicy.rules.onPodConditions ([]PodFailurePolicyOnPodConditionsPattern), обовʼязково

        Atomic: буде замінено під час обʼєднання

        Представляє вимогу до стану Podʼа. Вимога представлена як список шаблонів стан Podʼа. Вимога задовольняється, якщо хоча б один шаблон відповідає фактичному стану Podʼа. Максимально дозволено 20 елементів.

        PodFailurePolicyOnPodConditionsPattern описує шаблон для відповідності фактичний стан Podʼа.

        • podFailurePolicy.rules.onPodConditions.status (string), обовʼязково

          Визначає необхідний статус стану Podʼа. Для відповідності стану Podʼа потрібно, щоб зазначений статус відповідав статусу стану Podʼа. Стандартне значення — True.

        • podFailurePolicy.rules.onPodConditions.type (string), обовʼязково

          Визначає необхідний тип стану Podʼа. Для відповідності стану Podʼа потрібно, щоб зазначений тип відповідав типу стану Podʼа.

  • successPolicy (SuccessPolicy)

    successPolicy вказує політику, коли Job може бути оголошено успішним. Якщо це поле порожнє, застосовується стандартна поведінка — Job вважається успішним лише тоді, коли кількість успішно виконаних podʼів дорівнює значенню completions. Якщо поле вказане, воно має бути незмінним і працює тільки для Indexed Jobs. Після того, як Job відповідає SuccessPolicy, невикористані podʼи завершуються.

    Це поле має рівень beta. Для використання цього поля потрібно увімкнути функцію JobSuccessPolicy (стандартно увімкнена).

    SuccessPolicy описує, коли Job може бути оголошено успішним на основі успішності деяких показників.

    • successPolicy.rules ([]SuccessPolicyRule), required

      Atomic: буде замінено під час злиття

      rules представляє список альтернативних правил для оголошення Jobs успішними до того, як .status.succeeded >= .spec.completions. Як тільки будь-яке з правил виконується, додається умова "SucceededCriteriaMet", і невикористані podʼи видаляються. Кінцевий стан для такого Job матиме стан "Complete". Ці правила оцінюються по порядку; як тільки Job відповідає одному з правил, інші ігноруються. Дозволено не більше 20 елементів.

      SuccessPolicyRule описує правило для оголошення Job успішним. Кожне правило повинно мати вказаний принаймні один із параметрів: "succeededIndexes" або "succeededCount".

      • successPolicy.rules.succeededCount (int32)

        succeededCount вказує мінімальний необхідний розмір фактичного набору успішно завершених індексів для Job. Коли succeededCount використовується разом із succeededIndexes, перевірка обмежується лише індексами, зазначеними в succeededIndexes. Наприклад, якщо succeededIndexes встановлено як "1-4", succeededCount дорівнює "3", а індекси, що були завершені — "1", "3" і "5", Job не оголошується успішним, оскільки враховуються лише індекси "1" і "3" згідно з цими правилами. Якщо це поле є null, воно не має стандартного значення і ніколи не оцінюється. Якщо вказано, воно повинно бути додатним цілим числом.

      • successPolicy.rules.succeededIndexes (string)

        succeededIndexes вказує набір індексів, які повинні бути у фактичному наборі успішно завершених індексів для Job. Список індексів має бути в межах від 0 до ".spec.completions-1" і не повинен містити дублікатів. Потрібен щонайменше один елемент. Індекси представлені у вигляді інтервалів, розділених комами. Інтервали можуть бути десятковими числами або парою десяткових чисел, розділених дефісом. Числа представляються як перший і останній елемент серії, розділені дефісом. Наприклад, якщо індекси, які були завершені — 1, 3, 4, 5 і 7, вони представлені як "1,3-5,7". Якщо це поле є null, воно не має стандартного значення і ніколи не оцінюється.

Альфа-рівень

  • backoffLimitPerIndex (int32)

    Визначає ліміт кількості повторних спроб в межах індексу перед тим, як позначити цей індекс як невдалий. Коли цей параметр увімкнений, кількість невдач по індексу зберігається в анотації Podʼа batch.kubernetes.io/job-index-failure-count. Це поле можна встановити лише при completionMode=Indexed для завдання, і політика перезапуску Podʼа повинна бути Never. Поле незмінне. Це поле на рівні бета. Воно може бути використане, коли ввімкнено прапорець JobBackoffLimitPerIndex (стандартно увімкнено).

  • managedBy (string)

    Поле ManagedBy вказує контролер, який керує Job. Контролер Job у Kubernetes синхронізує jobʼи, які не мають цього поля взагалі або якщо значення поля — зарезервований рядок kubernetes.io/job-controller, але пропускає синхронізацію Job із власними значенням у цьому полі. Значення має бути дійсним шляхом із префіксом домену (наприклад, acme.io/foo) — усі символи перед першим "/" мають бути дійсним піддоменом відповідно до RFC 1123. Усі символи після першого "/" мають бути дійсними символами HTTP-шляху згідно з RFC 3986. Значення не може перевищувати 63 символів. Це поле є незмінним.

    Це поле має рівень alpha. Контролер job приймає встановлення цього поля, коли ввімкнено функцію JobManagedBy (стандартно вимкнено).

  • 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. Час завершення встановлюється, коли завдання успішно завершується, і тільки тоді. Значення не можна оновити або видалити. Значення вказує на той самий або пізніший момент часу, що і поле startTime.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • active (int32)

    Кількість Podʼів в стані очікування та працюючих Podʼів, які не завершуються (без мітки видалення). Значення дорівнює нулю для завершених завдань.

  • failed (int32)

    Кількість Podʼів, які досягли фази Failed. Значення зростає монотонно.

  • succeeded (int32)

    Кількість Podʼів, які досягли фази Succeeded. Значення монотонно зростає для даної специфікації. Однак воно може зменшуватись у відповідь на скорочення кількості job, що еластично індексуються.

  • 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.

    Завдання вважається завершеним, коли воно перебуває в термінальному стані "Complete" або "Failed". Завдання не може мати одночасно стан "Complete" і "Failed". Крім того, воно не може перебувати в станах "Complete" і "FailureTarget". Умови "Complete", "Failed" і "FailureTarget" не можуть бути відключені.

    Додаткова інформація: 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 завершується (успішно або з помилкою), контролер виконує три кроки для врахування його у статусі завдання:

    1. Додає UID Podʼа до масивів у цьому полі.
    2. Видаляє завершувач Podʼа.
    3. Видаляє UID Podʼа з масивів, збільшуючи відповідний лічильник.

    Старі завдання можуть не відстежуватися з використанням цього поля, у такому випадку поле залишається порожнім. Структура порожня для завершених завдань .

    UncountedTerminatedPods містить UID Podʼів, які завершили роботу, але ще не враховані в лічильниках статусу завдання.

    • uncountedTerminatedPods.failed ([]string)

      Set: унікальні значення зберігатимуться під час обʼєднання

      failed містить UID Podʼів, що завершилися з помилкою.

    • uncountedTerminatedPods.succeeded ([]string)

      Set: унікальні значення зберігатимуться під час обʼєднання

      succeeded містить UID Podʼів, що завершилися успішно.

Бета-рівень

  • ready (int32)

    Кількість активних Podʼів, які мають стан Ready та не завшуються (без deletionTimestamp)

Альфа-рівень

  • failedIndexes (string)

    FailedIndexes зберігає невдалі індекси, коли spec.backoffLimitPerIndex є набором. Індекси представлені у текстовому форматі, аналогічному до поля completedIndexes, тобто вони зберігаються як десяткові цілі числа, розділені комами. Числа подані в порядку зростання. Три або більше послідовних числа стискаються і представлені першим та останнім елементом серії, розділеними дефісом. Наприклад, якщо невдалі індекси: 1, 3, 4, 5 і 7, вони представлені як "1,3-5,7". Набір невдалих індексів не може перетинатися з набором завершених індексів.

    Це поле знаходиться на бета-рівні. Його можна використовувати, коли ввімкнено функцію JobBackoffLimitPerIndex (стандартно увімкнено).

  • terminating (int32)

    Кількість Podʼів, які завершуються (у фазі Pending або Running та мають deletionTimestamp).

    Це поле знаходиться на бета-рівні. Контролер завдань заповнює це поле, коли ввімкнено функцію JobPodReplacementPolicy (стандартно увімкнено).

JobList

JobList представляє собою колекцію завдань.

Операції

get отримати вказане завдання

HTTP запит

GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

401: Unauthorized

get отримати статус вказаного завдання

HTTP запит

GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Job

HTTP запит

GET /apis/batch/v1/namespaces/{namespace}/jobs

Параметри

Відповідь

200 (JobList): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Job

HTTP запит

GET /apis/batch/v1/jobs

Параметри

Відповідь

200 (JobList): ОК

401: Unauthorized

create створення Job

HTTP запит

POST /apis/batch/v1/namespaces/{namespace}/jobs

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Job, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

202 (Job): Accepted

401: Unauthorized

update заміна вказаного Job

HTTP запит

PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Job, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

update заміна статусу вказаного Job

HTTP запит

PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Job, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

patch часткове оновлення вказаного Job

HTTP запит

PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Job

HTTP запит

PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

delete видалення Job

HTTP запит

DELETE /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Job

HTTP запит

DELETE /apis/batch/v1/namespaces/{namespace}/jobs

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

5.1.11 - CronJob

CronJob являє собою конфігурацію одного завдання cron.

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

CronJob

CronJob являє собою конфігурацію одного завдання cron.

CronJobSpec

CronJobSpec описує, як виглядатиме виконання завдання та коли воно буде запущено.

  • jobTemplate (JobTemplateSpec), обовʼязково

    Вказує на шаблон задачі, яка буде створена під час виконання CronJob.

    JobTemplateSpec описує дані, які повинні бути у задачі при створенні з шаблону

  • schedule (string), обовʼязково

    Розклад у форматі Cron, див. https://uk.wikipedia.org/wiki/Cron.

  • timeZone (string)

    Назва часового поясу для вказаного розкладу, див. 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.

CronJobStatus

CronJobStatus представляє поточний стан cron job.

  • active ([]ObjectReference)

    Atomic: буде замінено під час злиття

    Список посилань на запущені зараз задачі.

  • lastScheduleTime (Time)

    Інформація про час останнього успішного запуску задачі.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • lastSuccessfulTime (Time)

    Інформація про час останнього успішного завершення задачі.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

CronJobList

CronJobList — це колекція cron job.

Операції

get отримати вказаний CronJob

HTTP-запит

GET /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

401: Unauthorized

get отримати статус вказаного CronJob

HTTP-запит

GET /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CronJob

HTTP-запит

GET /apis/batch/v1/namespaces/{namespace}/cronjobs

Параметри

Відповідь

200 (CronJobList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CronJob

HTTP-запит

GET /apis/batch/v1/cronjobs

Параметри

Відповідь

200 (CronJobList): OK

401: Unauthorized

create створення CronJob

HTTP-запит

POST /apis/batch/v1/namespaces/{namespace}/cronjobs

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CronJob, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

202 (CronJob): Accepted

401: Unauthorized

update заміна вказаного CronJob

HTTP-запит

PUT /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CronJob, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

update заміна статусу вказаного CronJob

HTTP-запит

PUT /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CronJob, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

patch часткове оновлення вказаного CronJob

HTTP-запит

PATCH /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

patch часткове оновлення статусу вказаного CronJob

HTTP-запит

PATCH /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

delete видалення CronJob

HTTP-запит

DELETE /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CronJob

HTTP-запит

DELETE /apis/batch/v1/namespaces/{namespace}/cronjobs

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.12 - HorizontalPodAutoscaler

Конфігурація горизонтального автомасштабування Podʼів.

apiVersion: autoscaling/v1

import "k8s.io/api/autoscaling/v1"

HorizontalPodAutoscaler

Конфігурація горизонтального автомасштабування Podʼів.

HorizontalPodAutoscalerSpec

Специфікація горизонтального автомасштабування Podʼів.

  • maxReplicas (int32), обовʼязково

    maxReplicas — верхня межа для кількості Podʼів, яку може встановити автомасштабувальник; не може бути менше, ніж MinReplicas.

  • scaleTargetRef (CrossVersionObjectReference), обовʼязково

    посилання на масштабований ресурс; горизонтальний автомасштабувальник Podʼів буде вивчати поточне використання ресурсу і встановлювати бажану кількість Podʼів за допомогою його субресурсу Scale (масштаб).

    CrossVersionObjectReference містить достатньо інформації для ідентифікації зазначеного ресурсу.

  • minReplicas (int32)

    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ʼів.

  • apiVersion: autoscaling/v1

  • kind: HorizontalPodAutoscalerList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]HorizontalPodAutoscaler), обовʼязкове поле

    items — список обʼєктів горизонтального автомасштабування Podʼів.

Операції

get отримати вказаний HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

get отримати статус вказаного HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

list список або перегляд за обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): OK

401: Unauthorized

list список або перегляд обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): ОК

401: Unauthorized

create створення HorizontalPodAutoscaler

HTTP запит

POST /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

202 (HorizontalPodAutoscaler): Accepted

401: Unauthorized

update заміна вказаного HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

update заміна статусу вказаного HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення статусу вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

delete видалення HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

5.1.13 - HorizontalPodAutoscaler

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

apiVersion: autoscaling/v2

import "k8s.io/api/autoscaling/v2"

HorizontalPodAutoscaler

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

Зрозуміло, ось переклад без формату YAML:

HorizontalPodAutoscalerSpec

HorizontalPodAutoscalerSpec описує бажану функціональність HorizontalPodAutoscaler.

  • maxReplicas (int32), обовʼязково

    maxReplicas — верхня межа кількості реплік, до якої може масштабуватись автомасштабувальник. Не може бути менше minReplicas.

  • scaleTargetRef (CrossVersionObjectReference), обовʼязково

    scaleTargetRef вказує на цільовий ресурс для масштабування і використовується для збору метрик для Podʼів, а також для зміни кількості реплік.

    CrossVersionObjectReference містить достатньо інформації для ідентифікації вказаного ресурсу.

  • minReplicas (int32)

    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 — це одна політика, яка повинна виконуватися для вказаного інтервалу в минулому.

        • behavior.scaleDown.policies.type (string), обовʼязково

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

        • behavior.scaleDown.policies.value (int32), обовʼязково

          value — містить кількість зміни, що дозволяється політикою. Вона повинна бути більше нуля.

        • behavior.scaleDown.policies.periodSeconds (int32), обовʼязково

          periodSeconds — визначає вікно часу, протягом якого політика повинна бути true. PeriodSeconds повинен бути більше нуля і менше або рівний 1800 (30 хвилин).

      • behavior.scaleDown.selectPolicy (string)

        selectPolicy — використовується для зазначення того, яка політика повинна бути використана. Якщо не встановлено, використовується типове значення Max.

      • behavior.scaleDown.stabilizationWindowSeconds (int32)

        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 протягом заданого інтервалу в минулому.

      • behavior.scaleUp.policies.type (string), обовʼязково

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

      • behavior.scaleUp.policies.value (int32), обовʼязково

        value — містить кількість змін, дозволених політикою. Значення має бути більше нуля.

      • behavior.scaleUp.policies.periodSeconds (int32), обовʼязково

        periodSeconds визначає вікно часу, протягом якого політика має бути true. PeriodSeconds має бути більше нуля та менше або дорівнювати 1800 (30 хвилин).

    • behavior.scaleUp.selectPolicy (string)

      selectPolicy використовується для вказівки, яка політика має бути використана. Якщо не встановлено, використовується стандартне значення Max.

    • behavior.scaleUp.stabilizationWindowSeconds (int32)

      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.

    • metrics.containerResource (ContainerResourceMetricSource)

      containerResource стосується метрики ресурсу (наприклад, ті, що вказані в запитах і лімітах), відомої Kubernetes, яка описує один контейнер у кожному Podʼі поточного цільового масштабу (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен Pod за допомогою джерела "pods". Це альфа-функція і може бути увімкнена прапорцем функції HPAContainerMetrics.

      ContainerResourceMetricSource вказує, як масштабуватися на основі метрики ресурсу, відомої Kubernetes, як вказано в запитах і лімітах, описуючи кожен Pod у поточному цільовому масштабі (наприклад, CPU або памʼять). Значення будуть усереднені перед порівнянням з цільовим значенням. Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен Pod за допомогою джерела "pods". Має бути встановлений лише один тип "target".

      • metrics.containerResource.container (string), обовʼязково

        container — це назва контейнера в Podʼах цільового масштабу.

      • metrics.containerResource.name (string), обовʼязково

        name — це назва відповідного ресурсу.

      • metrics.containerResource.target (MetricTarget), обовʼязково

        target — визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.containerResource.target.type (string), обовʼязково

          type — представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.containerResource.target.averageUtilization (int32)

          averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.containerResource.target.averageValue (Quantity)

          averageValue – це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.containerResource.target.value (Quantity)

          value — це цільове значення метрики (як кількість).

    • metrics.external (ExternalMetricSource)

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

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

      • metrics.external.metric (MetricIdentifier), обовʼязково

        metric — визначає цільову метрику за назвою та селектором.

        MetricIdentifier визначає назву та, за потреби, селектор для метрики.

        • metrics.external.metric.name (string), обовʼязково

          name — це назва даної метрики.

        • metrics.external.metric.selector (LabelSelector)

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

      • metrics.external.target (MetricTarget), обовʼязково

        target — визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.external.target.type (string), обовʼязково

          type — представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.external.target.averageUtilization (int32)

          averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.external.target.averageValue (Quantity)

          averageValue — це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.external.target.value (Quantity)

          value – це цільове значення метрики (як кількість).

    • metrics.object (ObjectMetricSource)

      object — стосується метрики, що описує один обʼєкт Kubernetes (наприклад, кількість запитів на секунду на обʼєкті Ingress).

      ObjectMetricSource вказує, як масштабуватися на основі метрики, що описує обʼєкт Kubernetes (наприклад, кількість запитів на секунду на обʼєкті Ingress).

      • metrics.object.describedObject (CrossVersionObjectReference), обовʼязково

        describedObject визначає опис обʼєкта, такого як тип, імʼя та версія API.

        CrossVersionObjectReference містить достатньо інформації для ідентифікації відповідного ресурсу.

      • metrics.object.metric (MetricIdentifier), обовʼязково

        metric — визначає цільову метрику за назвою та селектором.

        MetricIdentifier визначає назву та, за потреби, селектор для метрики.

        • metrics.object.metric.name (string), обовʼязково

          name — це назва даної метрики.

        • metrics.object.metric.selector (LabelSelector)

          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.

        • metrics.object.target.averageValue (Quantity)

          averageValue — цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.object.target.value (Quantity)

          value — цільове значення метрики (як кількість).

    • metrics.pods (PodsMetricSource)

      pods — стосується метрики, що описує кожен Pod у поточному цільовому масштабі (наприклад, кількість транзакцій на секунду). Значення будуть усереднені перед порівнянням з цільовим значенням.

      PodsMetricSource вказує, як масштабуватися на основі метрики, що описує кожен Pod у поточному цільовому масштабі (наприклад, кількість транзакцій на секунду). Значення будуть усереднені перед порівнянням з цільовим значенням.

      • metrics.pods.metric (MetricIdentifier), обовʼязково

        metric — визначає цільову метрику за назвою та селектором.

        MetricIdentifier визначає назву та, за потреби, селектор для метрики.

        • metrics.pods.metric.name (string), обовʼязково

          name — це назва даної метрики.

        • metrics.pods.metric.selector (LabelSelector)

          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.

        • metrics.pods.target.averageValue (Quantity)

          averageValue — це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.pods.target.value (Quantity)

          value — це цільове значення метрики (як кількість).

    • metrics.resource (ResourceMetricSource)

      resource — стосується метрики ресурсу (наприклад, ті, що вказані в запитах і лімітах), відомої Kubernetes, яка описує кожен у поточному цільовому масштабі (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен за допомогою джерела "pods".

      ResourceMetricSource вказує, як масштабуватися на основі метрики ресурсу, відомої Kubernetes, як вказано в запитах і лімітах, описуючи кожен у поточному цільовому масштабі (наприклад, CPU або памʼять). Значення будуть усереднені перед порівнянням з цільовим значенням. Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен под за допомогою джерела "pods". Повинен бути встановлений лише один тип "target".

      • metrics.resource.name (string), обовʼязково

        name — це назва ресурсу.

      • metrics.resource.target (MetricTarget), обовʼязково

        target — визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.resource.target.type (string), обовʼязково

          type представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.resource.target.averageUtilization (int32)

          averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.resource.target.averageValue (Quantity)

          averageValue — це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.resource.target.value (Quantity)

          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.

    • currentMetrics.containerResource (ContainerResourceMetricStatus)

      container resource стосується метрики ресурсу (такої як зазначено в запитах та обмеженнях), відомої Kubernetes, що описує окремий контейнер у кожному Podʼі в поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      ContainerResourceMetricStatus вказує поточне значення метрики ресурсу, відомої Kubernetes, як зазначено в запитах та обмеженнях, що описує окремий контейнер у кожному Podʼі в поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      • currentMetrics.containerResource.container (string), обовʼязково

        container — це імʼя контейнера в Podʼах цільового масштабування

      • currentMetrics.containerResource.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.containerResource.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.containerResource.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.containerResource.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.containerResource.name (string), обовʼязково

        name — це імʼя ресурсу, про який йдеться.

    • currentMetrics.external (ExternalMetricStatus)

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

      ExternalMetricStatus вказує поточне значення глобальної метрики, не повʼязаної з жодним обʼєктом Kubernetes.

      • currentMetrics.external.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.external.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.external.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.external.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.external.metric (MetricIdentifier), обовʼязково

        metric — ідентифікує цільову метрику за імʼям і селектором

        MetricIdentifier визначає імʼя та, за потреби, селектор для метрики

        • currentMetrics.external.metric.name (string), обовʼязково

          name — це імʼя даної метрики

        • currentMetrics.external.metric.selector (LabelSelector)

          selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.

    • currentMetrics.object (ObjectMetricStatus)

      object стосується метрики, що описує окремий обʼєкт Kubernetes (наприклад, кількість запитів на секунду для обʼєкта Ingress).

      ObjectMetricStatus вказує поточне значення метрики, що описує обʼєкт Kubernetes (наприклад, кількість запитів на секунду для обʼєкта Ingress).

      • currentMetrics.object.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.object.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.object.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.object.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.object.describedObject (CrossVersionObjectReference), обовʼязково

        DescribedObject вказує описи обʼєкта, такі як kind, name, apiVersion

        CrossVersionObjectReference містить достатньо інформації, щоб ідентифікувати вказаний ресурс.

      • currentMetrics.object.metric (MetricIdentifier), обовʼязково

        metric — ідентифікує цільову метрику за імʼям і селектором

        MetricIdentifier визначає імʼя та, за потреби, селектор для метрики

        • currentMetrics.object.metric.name (string), обовʼязково

          name — це імʼя даної метрики

        • currentMetrics.object.metric.selector (LabelSelector)

          selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.

    • currentMetrics.pods (PodsMetricStatus)

      pods — стосується метрики, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, кількість оброблених транзакцій на секунду). Значення буде усереднено перед порівнянням з цільовим значенням.

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

      • currentMetrics.pods.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.pods.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.pods.current.averageValue (Quantity)

          averageValue — це поточне значення середньої метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.pods.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.pods.metric (MetricIdentifier), обовʼязково

        metric — ідентифікує цільову метрику за імʼям і селектором

        MetricIdentifier визначає імʼя та, за потреби, селектор для метрики

        • currentMetrics.pods.metric.name (string), обовʼязково

          name — це імʼя даної метрики

        • currentMetrics.pods.metric.selector (LabelSelector)

          selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.

    • currentMetrics.resource (ResourceMetricStatus)

      resource — стосується метрики ресурсу (такої як зазначено в запитах та обмеженнях), відомої Kubernetes, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      ResourceMetricStatus вказує поточне значення метрики ресурсу, відомої Kubernetes, як зазначено в запитах та обмеженнях, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      • currentMetrics.resource.current (MetricValueStatus), обовʼязково

        current містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.resource.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.resource.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.resource.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.resource.name (string), обовʼязково

        name — це імʼя ресурсу, про який йдеться.

  • currentReplicas (int32)

    currentReplicas — це поточна кількість реплік Podʼів, якими керує цей автомасштабувальник, як це було останній раз спостережено автомасштабувальником.

  • lastScaleTime (Time)

    lastScaleTime — це останній час, коли HorizontalPodAutoscaler масштабував кількість Podʼів, використовується автомасштабувальником для контролю частоти зміни кількості Podʼів.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • observedGeneration (int64)

    observedGeneration — це останнє покоління, яке спостерігав цей автомасштабувальник.

HorizontalPodAutoscalerList

HorizontalPodAutoscalerList — це список обʼєктів горизонтального автомасштабувальника Podʼів.

  • apiVersion: autoscaling/v2

  • kind: HorizontalPodAutoscalerList

  • metadata (ListMeta)

    metadata — це стандартні метадані списку.

  • items ([]HorizontalPodAutoscaler), обовʼязково

    items — це список обʼєктів горизонтального автомасштабувальника Podʼів.

Операції

get отримати вказаний HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

get отримати статус вказаного HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): OK

401: Unauthorized

list перелік або перегляд за обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): OK

401: Unauthorized

create створення HorizontalPodAutoscaler

HTTP запит

POST /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

202 (HorizontalPodAutoscaler): Accepted

401: Unauthorized

update заміна вказаний HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

update заміна статусу вказаного HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення статусу вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

delete видалення HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: deleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (HorizontalPodAutoscaler): OK

202 (HorizontalPodAutoscaler): Accepted

401: Unauthorized

deletecollection видалення колекції HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.14 - PriorityClass

PriorityClass визначає зіставлення імені класу пріоритету з цілим значенням пріоритету.

apiVersion: scheduling.k8s.io/v1

import "k8s.io/api/scheduling/v1"

PriorityClass

PriorityClass визначає зіставлення імені класу пріоритету з цілим значенням пріоритету.

  • apiVersion: scheduling.k8s.io/v1

  • kind: PriorityClass

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • value (int32), обовʼязково

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

  • description (string)

    Опис є довільним рядком, який зазвичай надає вказівки про те, коли слід використовувати цей клас пріоритету.

  • globalDefault (boolean)

    Визначає, чи слід вважати цей PriorityClass за стандартний пріоритет для Podʼів, які не мають жодного класу пріоритету. Може бути встановлено лише один PriorityClass як globalDefault. Однак, якщо існує більше одного PriorityClass з полем globalDefault, встановленим на true, то за стандартний пріоритет буде використовувати найменше значення серед таких глобальних пріоритетних класів.

  • preemptionPolicy (string)

    Політика для випередження Podʼів з нижчим пріоритетом. Один із варіантів: Never, PreemptLowerPriority. Стандартно використовується PreemptLowerPriority, якщо не встановлено жодного значення.

PriorityClassList

Операції

get отримати вказаний PriorityClass

HTTP запит

GET /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PriorityClass

HTTP запит

GET /apis/scheduling.k8s.io/v1/priorityclasses

Параметри

Відповідь

200 (PriorityClassList): OK

401: Unauthorized

create створення PriorityClass

HTTP запит

POST /apis/scheduling.k8s.io/v1/priorityclasses

Параметри

Відповідь

200 (PriorityClass): OK

201 (PriorityClass): Created

202 (PriorityClass): Accepted

401: Unauthorized

update заміна вказаного PriorityClass

HTTP запит

PUT /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityClass

  • body: PriorityClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityClass): OK

201 (PriorityClass): Created

401: Unauthorized

patch часткове оновлення вказаного PriorityClass

HTTP запит

PATCH /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityClass): OK

201 (PriorityClass): Created

401: Unauthorized

delete видалення PriorityClass

HTTP запит

DELETE /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції PriorityClass

HTTP запит

DELETE /apis/scheduling.k8s.io/v1/priorityclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.15 - PodSchedulingContext v1alpha3

Обʼєкти PodSchedulingContext містять інформацію, необхідну для планування Pod з ResourceClaims, що використовують режим виділення "WaitForFirstConsumer".

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

PodSchedulingContext

Обʼєкти PodSchedulingContext містять інформацію, необхідну для планування Pod з ResourceClaims, що використовують режим виділення "WaitForFirstConsumer".

Це тип альфа-версії та потребує включення функціональних можливостей DRAControlPlaneController.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: PodSchedulingContext

  • metadata (ObjectMeta)

    Метадані стандартного обʼєкта

  • spec (PodSchedulingContextSpec), обовʼязково

    Специфікація описує, де потрібні ресурси для Pod.

  • status (PodSchedulingContextStatus)

    Статус описує, де можуть бути виділені ресурси для Pod.

PodSchedulingContextSpec

PodSchedulingContextSpec описує, де потрібні ресурси для Pod.

  • potentialNodes ([]string)

    Atomic: буде замінено під час злиття

    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)

      Atomic: буде замінено під час злиття

      UnsuitableNodes перелічує вузли, для яких ResourceClaim не може бути виділено.

      Розмір цього поля обмежений 128, так само як і для PodSchedulingSpec.PotentialNodes. Це обмеження може бути збільшено в майбутньому, але не зменшено.

PodSchedulingContextList

PodSchedulingContextList є колекцією обʼєктів планування Pod.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: PodSchedulingContextList

  • metadata (ListMeta)

    Стандартні метадані списку

  • items ([]PodSchedulingContext), обовʼязково

    Items — це список обʼєктів PodSchedulingContext.

Операції

get отримати вказаний PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

401: Unauthorized

get отримати статус вказаного PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts

Параметри

Відповідь

200 (PodSchedulingContextList): OK

401: Unauthorized

list список або перегляд обʼєктів типу PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/podschedulingcontexts

Параметри

Відповідь

200 (PodSchedulingContextList): OK

401: Unauthorized

create створення PodSchedulingContext

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts

Параметри

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

202 (PodSchedulingContext): Accepted

401: Unauthorized

update заміна вказаного PodSchedulingContext

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodSchedulingContext, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

401: Unauthorized

update заміна статусус вказаного PodSchedulingContext

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва the PodSchedulingContext

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodSchedulingContext, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

401: Unauthorized

patch часткове оновлення вказаного PodSchedulingContext

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodSchedulingContext, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

401: Unauthorized

patch часткове оновлення статусу вказаного PodSchedulingContext

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва the PodSchedulingContext

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

401: Unauthorized

delete видалення PodSchedulingContext

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodSchedulingContext

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (PodSchedulingContext): OK

202 (PodSchedulingContext): Accepted

401: Unauthorized

deletecollection видалення колекції PodSchedulingContext

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.16 - ResourceClaim v1alpha3

ResourceClaim описує запит на доступ до ресурсів у кластері для використання робочими навантаженнями.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

ResourceClaim

ResourceClaim описує запит на доступ до ресурсів у кластері, для використання робочими навантаженнями. Наприклад, якщо робоче навантаження потребує пристрою-акселератора з конкретними властивостями, ось як виражається цей запит. Розділ статусу відстежує, чи було задоволено цей запит і які саме ресурси були виділені.

Це альфа-тип і потребує увімкнення функціональної можливості DynamicResourceAllocation.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaim

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта

  • spec (ResourceClaimSpec), обовʼязково

    Spec описує, що запитується і як це налаштувати. Специфікація є незмінною.

  • status (ResourceClaimStatus)

    Status описує, чи заявка готова до використання і що було виділено.

ResourceClaimSpec

ResourceClaimSpec визначає, що запитується в ResourceClaim і як це налаштувати.

  • controller (string)

    Controller — це імʼя драйвера DRA, який призначений для обробки розподілу цієї заявки. Якщо поле порожнє, розподіл обробляється планувальником під час планування podʼа.

    Має бути піддоменом DNS і закінчуватися доменом DNS, що належить постачальнику драйвера.

    Це альфа-поле і вимагає активації функціональної можливості DRAControlPlaneController.

  • devices (DeviceClaim)

    Devices визначає як запитувати пристрої.

    DeviceClaim визначає, як запитувати пристрої за допомогою ResourceClaim.

    • devices.config ([]DeviceClaimConfiguration)

      Atomic: буде замінено під час злиття

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

      DeviceClaimConfiguration використовується для параметрів конфігурації у DeviceClaim.

      • devices.config.opaque (OpaqueDeviceConfiguration)

        Opaque надає специфічні для драйвера параметри конфігурації.

        OpaqueDeviceConfiguration містить параметри конфігурації драйвера у форматі, визначеному постачальником драйвера.

        • devices.config.opaque.driver (string), обовʼязково

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

          Політика допуску, надана розробником драйвера, може використовувати цей параметр, щоб вирішити, чи потрібно їх перевіряти.

          Має бути субдоменом DNS і закінчуватися на DNS-домені, що належить постачальнику драйвера.

        • devices.config.opaque.parameters (RawExtension), обовʼязково

          Параметри можуть містити довільні дані. Відповідальність за перевірку та керування версіями покладається на розробника драйверів. Зазвичай це включає самоідентифікацію та версію ("kind" + "apiVersion" для типів Kubernetes), а також конвертацію між різними версіями.

          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 буде виглядати приблизно так:

          {
  "kind":"MyAPIObject",
  "apiVersion":"v1",
  "myPlugin": {
    "kind":"PluginA",
    "aOption":"foo",
  },
}

          Що відбувається? Спочатку декодування використовує json або yaml для десеріалізації даних у ваш зовнішній MyAPIObject. Це призводить до зберігання необробленого JSON, але без розпакування. Наступний крок — копіювання (за допомогою pkg/conversion) у внутрішню структуру. Функції перетворення, встановлені в DefaultScheme пакета runtime, розпаковують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, коли обʼєкт має невідомий тип, буде створено і збережено обʼєкт runtime.Unknown.)

      • devices.config.requests ([]string)

        Atomic: буде замінено під час злиття

        Requests перераховує назви запитів, до яких застосовується конфігурація. Якщо поле порожнє, конфігурація застосовується до всіх запитів.

    • devices.constraints ([]DeviceConstraint)

      Atomic: буде замінено під час злиття

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

      DeviceConstraint повинен мати рівно одне поле, крім Requests.

      • devices.constraints.matchAttribute (string)

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

        Наприклад, якщо ви вказали "dra.example.com/numa" (гіпотетичний приклад!), то будуть обрані лише пристрої в одному й тому самому NUMA-вузлі. Пристрій, який не має цього атрибуту, не буде обраний. Усі пристрої повинні використовувати значення одного типу для цього атрибуту, оскільки це є частиною його специфікації, але якщо якийсь пристрій цього не робить, він також не буде обраний.

        Має включати доменний кваліфікатор.

      • devices.constraints.requests ([]string)

        Atomic: буде замінено під час злиття

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

    • devices.requests ([]DeviceRequest)

      Atomic: буде замінено під час злиття

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

      DeviceRequest — це запит на пристрої, необхідні для заявки. Зазвичай це запит на один ресурс, такий як пристрій, але також може включати запит на кілька однакових пристроїв.

      Поле DeviceClassName наразі є обов’язковим. Клієнти повинні перевірити, чи воно дійсно встановлене. Його відсутність свідчить про зміни, які ще не підтримуються клієнтом, і в такому випадку клієнт повинен відмовитися від обробки запиту.

      • devices.requests.deviceClassName (string), обовʼязково

        DeviceClassName посилається на конкретний DeviceClass, який може визначати додаткові налаштування та селектори, що будуть успадковані цим запитом.

        Клас є обов’язковим. Доступність класів залежить від кластера.

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

      • devices.requests.name (string), обовʼязково

        Name може бути використане для посилання на цей запит у записі pod.spec.containers[].resources.claims та в умові заявки.

        Має бути міткою DNS.

      • devices.requests.adminAccess (boolean)

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

      • devices.requests.allocationMode (string)

        AllocationMode та пов’язані з ним поля визначають, як пристрої виділяються для виконання цього запиту. Підтримувані значення:

        • ExactCount: Цей запит на конкретну кількість пристроїв. Це значення використовується стандартно. Точна кількість вказується в полі count.

        • All: Цей запит на всі пристрої, що відповідають умовам, у пулі. Виділення не вдасться, якщо деякі пристрої вже виділені, за винятком випадків, коли запитується adminAccess.

        Якщо AllocationMode не вказано, стандатний режим — ExactCount. Якщо режим — ExactCount і кількість не вказана, стандартна кількість один. Будь-які інші запити повинні вказати це поле.

        Можуть бути додані нові режими в майбутньому. Клієнти повинні відмовитися від обробки запитів із невідомими режимами.

      • devices.requests.count (int64)

        Поле Count використовується лише тоді, коли режим підрахунку — "ExactCount". Має бути більше нуля. Якщо AllocationMode встановлено як ExactCount і це поле не вказано, стандартне значення — один.

      • devices.requests.selectors ([]DeviceSelector)

        Atomic: буде замінено під час злиття

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

        DeviceSelector повинен мати рівно одне встановлене поле.

        • devices.requests.selectors.cel (CELDeviceSelector)

          CEL містить вираз CEL для вибору пристрою.

          CELDeviceSelector містить CEL-вираз для вибору пристрою.

          • devices.requests.selectors.cel.expression (string), обовʼязково

            Вираз є виразом CEL, який оцінює один пристрій. Він має оцінюватися як true, коли пристрій відповідає бажаним критеріям, і як false, коли не відповідає. Будь-який інший результат є помилкою і призводить до зупинки надання пристроїв.

            Вхідні дані виразу — це обʼєкт з назвою "device", який має наступні властивості:

            • driver (рядок): імʼя драйвера, який визначає цей пристрій.
            • attributes (map[string]object): атрибути пристрою, згруповані за префіксом (наприклад, device.attributes["dra.example.com"] оцінюється як обʼєкт з усіма атрибутами, які були префіксовані "dra.example.com").
            • capacity (map[string]object): обсяги пристрою, згруповані за префіксом.

            Приклад: Розглянемо пристрій з driver="dra.example.com", який надає два атрибути з назвою "model" та "ext.example.com/family" і один обсяг з назвою "modules". Вхідні дані для цього виразу будуть мати такі поля:

            device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

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

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

            Якщо невідомий префікс використовується для запиту в device.attributes або device.capacity, буде повернено порожній map. Будь-яке посилання на невідоме поле спричинить помилку оцінки і зупинку виділення.

            Робочий вираз має перевіряти наявність атрибутів перед їх використанням.

            Для зручності використання доступна функція cel.bind(), яка може бути використана для спрощення виразів, що звертаються до кількох атрибутів з одного домену. Наприклад:

            cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

ResourceClaimStatus

ResourceClaimStatus відстежує, чи було виділено ресурс і яким був результат.

  • allocation (AllocationResult)

    Allocation встановлюється після успішного розподілу заявки.

    AllocationResult містить атрибути виділеного ресурсу.

    • allocation.controller (string)

      controller — це імʼя драйвера DRA, який обробив виділення. Цей драйвер також відповідає за деалокацію заявки. Воно порожнє, коли заявку можна деалокувати без залучення драйвера.

      Драйвер може виділяти пристрої, надані іншими драйверами, тому імʼя цього драйвера може відрізнятися від імен драйверів, зазначених у результатах.

      Це альфа-поле і вимагає активації функціональної можливості DRAControlPlaneController.

    • allocation.devices (DeviceAllocationResult)

      Devices є результатом виділення пристроїів.

      DeviceAllocationResult — результат виділення пристроїв.

      • allocation.devices.config ([]DeviceAllocationConfiguration)

        Atomic: буде замінено під час злиття

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

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

        DeviceAllocationConfiguration gets embedded in an AllocationResult.

        • allocation.devices.config.source (string), обовʼязково

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

        • allocation.devices.config.opaque (OpaqueDeviceConfiguration)

          Opaque надає специфічні для драйвера параметри конфігурації.

          OpaqueDeviceConfiguration містить параметри конфігурації драйвера у форматі, визначеному постачальником драйвера.

          • allocation.devices.config.opaque.driver (string), обовʼязково

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

            Політика допуску, надана розробником драйвера, може використовувати цей параметр, щоб вирішити, чи потрібно їх перевіряти.

            Має бути субдоменом DNS і закінчуватися на DNS-домені, що належить постачальнику драйвера.

          • allocation.devices.config.opaque.parameters (RawExtension), обовʼязково

            Параметри можуть містити довільні дані. Відповідальність за перевірку та керування версіями покладається на розробника драйверів. Зазвичай це включає самоідентифікацію та версію ("kind" + "apiVersion" для типів Kubernetes), а також конвертацію між різними версіями.

            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 буде виглядати приблизно так:

            {
  "kind":"MyAPIObject",
  "apiVersion":"v1",
  "myPlugin": {
    "kind":"PluginA",
    "aOption":"foo",
  },
}

            Що відбувається? Спочатку декодування використовує json або yaml для десеріалізації даних у ваш зовнішній MyAPIObject. Це призводить до зберігання необробленого JSON, але без розпакування. Наступний крок — копіювання (за допомогою pkg/conversion) у внутрішню структуру. Функції перетворення, встановлені в DefaultScheme пакета runtime, розпаковують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, коли обʼєкт має невідомий тип, буде створено і збережено обʼєкт runtime.Unknown.)

        • allocation.devices.config.requests ([]string)

          Atomic: буде замінено під час злиття

          Requests перераховує назви запитів, до яких застосовується конфігурація. Якщо поле порожнє, конфігурація застосовується до всіх запитів.

      • allocation.devices.results ([]DeviceRequestAllocationResult)

        Atomic: буде замінено під час злиття

        Results — перелік віділених пристроїв.

        DeviceRequestAllocationResult містить результат розподілу для одного запиту.

        • allocation.devices.results.device (string), обовʼязково

          Device посилається на один екземпляр пристрою за його імʼям в ресурсному пулі драйвера. Має бути міткою DNS.

        • allocation.devices.results.driver (string), обовʼязково

          Driver вказує імʼя драйвера DRA, чий втулок kubelet слід викликати для обробки виділення, коли заявка потрібна на вузлі.

          Має бути піддоменом DNS і закінчуватися доменом DNS, що належить постачальнику драйвера.

        • allocation.devices.results.pool (string), обовʼязково

          Це імʼя разом з імʼям драйвера та полем імені пристрою ідентифікує, який пристрій був виділений (\<імʼя драйвера>/\<імʼя пулу>/\<імʼя пристрою>).

          Не повинно перевищувати 253 символи і може містити один або більше піддоменів DNS, розділених косими рисками.

        • allocation.devices.results.request (string), обовʼязково

          Request — це імʼя запиту в заявці, який спричинив виділення цього пристрою. Для одного запиту може бути виділено кілька пристроїв.

    • allocation.nodeSelector (NodeSelector)

      NodeSelector визначає, де доступні виділені ресурси. Якщо не встановлено, ресурси доступні скрізь.

      Селектор вузлів представляє об'єднання результатів одного або кількох запитів міток над набором вузлів; тобто, він представляє логічне OR селекторів, які представлені термінами селектора вузлів.

      • allocation.nodeSelector.nodeSelectorTerms ([]NodeSelectorTerm), обовʼязково

        Atomic: буде замінено під час злиття

        Обов’язкове поле. Список термінів селектора вузлів. Термінів застосовується логічне OR.

        Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

        • allocation.nodeSelector.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за мітками вузлів.

        • allocation.nodeSelector.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за полями вузлів.

  • deallocationRequested (boolean)

    Вказує на те, що заявку потрібно деалокувати. Поки це поле встановлене, нові споживачі не можуть бути додані до ReservedFor.

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

    Це альфа-поле і вимагає активації функціональної можливості DRAControlPlaneController.

  • reservedFor ([]ResourceClaimConsumerReference)

    Patch strategy: злиття за ключем uid

    Map: унікальні значення ключа uid будуть збережені під час злиття

    ReservedFor вказує, які сутності в даний момент можуть використовувати заявку. Pod, який посилається на ResourceClaim, що не зарезервована для цього Podʼа, не буде запущений. Заявка, яка використовується або може бути використана, оскільки вона зарезервована, не повинна бути деалокована.

    У кластері з кількома екземплярами планувальника два podʼи можуть бути заплановані одночасно різними планувальниками. Коли вони посилаються на один і той же ResourceClaim, який вже досяг максимального числа споживачів, лише один pod може бути запланований.

    Обидва планувальники намагаються додати свій pod до поля claim.status.reservedFor, але лише оновлення, яке досягає API-сервера першим, зберігається. Інше оновлення зазнає помилки, і планувальник, який його надіслав, знає, що потрібно повернути pod у чергу, чекаючи, поки ResourceClaim знову стане доступним.

    Може бути не більше 32 таких резервувань. Це число може бути збільшено в майбутньому, але не зменшено.

    ResourceClaimConsumerReference містить достатньо інформації, щоб знайти споживача ResourceClaim. Користувач має бути ресурсом в тому ж просторі імен, що і ResourceClaim.

    • reservedFor.name (string), обовʼязково

      Name — це імʼя ресурсу, на який посилаються.

    • reservedFor.resource (string), обовʼязково

      Resource — це тип ресурсу, на який посилаються, наприклад, "pods".

    • reservedFor.uid (string), обовʼязково

      UID ідентифікує саме одну інкарнацію ресурсу.

    • reservedFor.apiGroup (string)

      APIGroup — це група для ресурсу, на який посилаються. Вона порожня для основного API. Це відповідає групі в APIVersion, яка використовується при створенні ресурсів.

ResourceClaimList

ResourceClaimList — це колекція заявок.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaimList

  • metadata (ListMeta)

    Стандартні метадані списку

  • items ([]ResourceClaim), обовʼязково

    Items — це список вимог на ресурси.

Операції

get отримати вказаний ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

401: Unauthorized

get отримати статус вказаного ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims

Параметри

Відповідь

200 (ResourceClaimList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceclaims

Параметри

Відповідь

200 (ResourceClaimList): OK

401: Unauthorized

create створення ResourceClaim

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims

Параметри

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

202 (ResourceClaim): Accepted

401: Unauthorized

update заміна вказаного ResourceClaim

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceClaim, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

update заміна статусу вказаного ResourceClaim

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceClaim, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

patch часткове оновлення вказаного ResourceClaim

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ResourceClaim

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

delete видалення ResourceClaim

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ResourceClaim): OK

202 (ResourceClaim): Accepted

401: Unauthorized

deletecollection видалення of ResourceClaim

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.17 - ResourceClaimTemplate v1alpha3

ResourceClaimTemplate використовується для створення обʼєктів ResourceClaim.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

ResourceClaimTemplate

ResourceClaimTemplate використовується для створення обʼєктів ResourceClaim.

Це альфа-тип і вимагає увімкнення функціональної можливості DynamicResourceAllocation.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaimTemplate

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • spec (ResourceClaimTemplateSpec), обовʼязково

    Описує ResourceClaim, який буде створений.

ResourceClaimTemplateSpec

ResourceClaimTemplateSpec містить метадані та поля для ResourceClaim.

  • spec (ResourceClaimSpec), обовʼязково

    Специфікація для ResourceClaim. Весь вміст копіюється без змін в ResourceClaim, який створюється з цього шаблону. Ті ж самі поля, що й в ResourceClaim, є дійсними тут.

  • metadata (ObjectMeta)

    ObjectMeta може містити мітки та анотації, які будуть скопійовані до PVC при створенні його. Інші поля не дозволені і будуть відхилені під час перевірки на валідність.

ResourceClaimTemplateList

ResourceClaimTemplateList є колекцією шаблонів заявок.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaimTemplateList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]ResourceClaimTemplate), обовʼязково

    Список шаблонів заявок на ресурси.

Операції

get отримати вказаний ResourceClaimTemplate

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaimTemplate): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaimTemplate

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates

Параметри

Відповідь

200 (ResourceClaimTemplateList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaimTemplate

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceclaimtemplates

Параметри

Відповідь

200 (ResourceClaimTemplateList): OK

401: Unauthorized

create створення ResourceClaimTemplate

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates

Параметри

Відповідь

200 (ResourceClaimTemplate): OK

201 (ResourceClaimTemplate): Created

202 (ResourceClaimTemplate): Accepted

401: Unauthorized

update заміна вказаного ResourceClaimTemplate

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceClaimTemplate, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaimTemplate): OK

201 (ResourceClaimTemplate): Created

401: Unauthorized

patch часткове оновлення вказаного ResourceClaimTemplate

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaimTemplate): OK

201 (ResourceClaimTemplate): Created

401: Unauthorized

delete видалення ResourceClaimTemplate

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ResourceClaimTemplate): OK

202 (ResourceClaimTemplate): Accepted

401: Unauthorized

deletecollection видалення колекції ResourceClaimTemplate

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.1.18 - ResourceSlice v1alpha3

ResourceSlice представляє один або декілька ресурсів у пулі подібних ресурсів, керованих спільним драйвером.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

ResourceSlice

ResourceSlice представляє один або кілька ресурсів у пулі подібних ресурсів, що управляються спільним драйвером. Пул може охоплювати більше ніж один ResourceSlice, і точна кількість ResourceSlices, що складають пул, визначається драйвером.

Наразі підтримуються лише пристрої з атрибутами та ємностями (capacities). Кожен пристрій у певному пулі, незалежно від кількості ResourceSlices, повинен мати унікальне імʼя. ResourceSlice, в якому пристрій публікується, може змінюватися з часом. Унікальний ідентифікатор для пристрою — це кортеж <імʼя драйвера>, <імʼя пулу>, <імʼя пристрою>.

Щоразу, коли драйверу потрібно оновити пул, він інкрементує номер pool.Spec.Pool.Generation і оновлює всі ResourceSlices з новим номером і новими визначеннями ресурсів. Споживач повинен використовувати лише ResourceSlices з найвищим номером покоління та ігнорувати всі інші.

При виділенні всіх ресурсів в пулі, що відповідають певним критеріям, або при пошуку найкращого рішення серед кількох різних альтернатив, споживач повинен перевірити кількість ResourceSlices у пулі (включену в кожен ResourceSlice), щоб визначити, чи є його погляд на пул повним, і, якщо ні, чекати, поки драйвер завершить оновлення пулу.

Для ресурсів, які не є локальними для вузла, імʼя вузла не встановлюється. Замість цього драйвер може використовувати селектор вузлів для вказівки, де пристрої доступні.

Це альфа-тип і вимагає активації функціональної можливості DynamicResourceAllocation.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceSlice

  • metadata (ObjectMeta)

    Стандартні мета дані обʼєкта

  • spec (ResourceSliceSpec), обовʼязково

    Містить інформацію, опубліковану драйвером.

    Зміна специфікації автоматично інкрементує номер metadata.generation.

ResourceSliceSpec

ResourceSliceSpec містить інформацію, опубліковану драйвером в одному ResourceSlice.

  • driver (string), обовʼязково

    Driver ідентифікує драйвер DRA, який надає інформацію про ємність. Можна використовувати селектор полів для переліку лише об'єктів ResourceSlice з певним імʼям драйвера.

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

  • pool (ResourcePool), обовʼязково

    Pool описує пул, до якого належить цей ResourceSlice.

    ResourcePool описує пул, до якого належать ResourceSlices.

    • pool.generation (int64), обовʼязково

      Generation відстежує зміни в пулі з часом. Щоразу, коли драйвер змінює щось в одному або кількох ресурсах у пулі, він повинен змінити покоління у всіх ResourceSlices, які є частиною цього пулу. Споживачі ResourceSlices повинні враховувати лише ресурси з пулу з найвищим номером покоління. Покоління може бути скинуто драйверами, що має бути прийнятно для споживачів, за умови, що всі ResourceSlices у пулі оновлені, щоб відповідати новому поколінню або видалені.

      Поєднаний з ResourceSliceCount, цей механізм дозволяє споживачам виявляти пули, які складаються з кількох ResourceSlices і знаходяться в неповному стані.

    • pool.name (string), обовʼязково

      Name використовується для ідентифікації пулу. Для локальних на вузлі пристроїв це часто є імʼя вузла, але це не є обовʼязковим.

      Не повинно перевищувати 253 символи і повинно складатися з одного або кількох піддоменів DNS, розділених косими рисками. Це поле є незмінним.

    • pool.resourceSliceCount (int64), обовʼязково

      ResourceSliceCount — це загальна кількість ResourceSlices у пулі на цьому номері покоління. Має бути більше нуля.

      Споживачі можуть використовувати це для перевірки, чи вони бачили всі ResourceSlices, що належать одному й тому ж пулу.

  • allNodes (boolean)

    AllNodes вказує на те, що всі вузли мають доступ до ресурсів у пулі.

    Має бути встановлено точно одне з полів NodeName, NodeSelector або AllNodes.

  • devices ([]Device)

    Atomic: буде замінено під час злиття

    Devices перераховує деякі або всі пристрої в цьому пулі.

    Не повинно бути більше ніж 128 записів.

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

    • devices.name (string), обовʼязково

      Name є унікальним ідентифікатором серед усіх пристроїв, які управляються драйвером у пулі. Має бути піддоменом DNS.

    • devices.basic (BasicDevice)

      Basic визначає один екземпляр пристрою.

      BasicDevice визначає один екземпляр пристрою.

      • devices.basic.attributes (map[string]DeviceAttribute)

        Attributes визначає набір атрибутів для цього пристрою. Імʼя кожного атрибута повинно бути унікальним у цьому наборі.

        Максимальна кількість атрибутів та ємностей разом — 32.

        DeviceAttribute має бути встановлено точно одне поле.

        • devices.basic.attributes.bool (boolean)

          BoolValue є значенням true/false.

        • devices.basic.attributes.int (int64)

          IntValue є числом.

        • devices.basic.attributes.string (string)

          StringValue є рядком. Не повинно бути довше 64 символів.

        • devices.basic.attributes.version (string)

          VersionValue є семантичною версією відповідно до специфікації semver.org 2.0.0. Не повинна перевищувати 64 символи в довжину.

      • devices.basic.capacity (map[string]Quantity)

        Capacity визначає набір ємностей для цього пристрою. Імʼя кожної ємності повинно бути унікальним у цьому наборі.

        Максимальна кількість атрибутів та ємностей разом — 32.

  • nodeName (string)

    NodeName ідентифікує вузол, який надає ресурси в цьому пулі. Селектор полів можна використовувати для переліку лише обʼєктів ResourceSlice, що належать певному вузлу.

    Це поле може використовуватися для обмеження доступу з вузлів до ResourceSlices з тим же іменем вузла. Воно також вказує автомасштабувальникам, що додавання нових вузлів того ж типу, що й старий вузол, може також зробити нові ресурси доступними.

    Має бути встановлено точно одне з полів NodeName, NodeSelector або AllNodes. Це поле є незмінним.

  • nodeSelector (NodeSelector)

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

    Має бути використано точно один термін.

    Має бути встановлено точно одне з полів NodeName, NodeSelector або AllNodes.

    Селектор вузлів представляє обʼєднання результатів одного або кількох запитів міток по набору вузлів; тобто, він представляє логічну операцію OR селекторів, представлених термінами селектора вузлів.

    • nodeSelector.nodeSelectorTerms ([]NodeSelectorTerm), обовʼязково

      Atomic: буде замінено під час злиття

      Обовʼязково. Список термінів селектора вузлів. Терміни обʼєднуються операцією OR.

      Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      • nodeSelector.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузлів за мітками вузлів.

      • nodeSelector.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузла за полями вузла.

ResourceSliceList

ResourceSliceList — колекція класів ResourceSlices.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceSliceList

  • items ([]ResourceSlice), обовʼязково

    Items is the list of resource ResourceSlices.

  • metadata (ListMeta)

    Стандартні метадані списку

Операції

get отримати вказаний ResourceSlice

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceSlice

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceSlice): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceSlice

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceslices

Параметри

Відповідь

200 (ResourceSliceList): OK

401: Unauthorized

create створення ResourceSlice

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/resourceslices

Параметри

Відповідь

200 (ResourceSlice): OK

201 (ResourceSlice): Created

202 (ResourceSlice): Accepted

401: Unauthorized

update заміна вказаного ResourceSlice

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceSlice

  • body: ResourceSlice, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceSlice): OK

201 (ResourceSlice): Created

401: Unauthorized

patch часткове оновлення вказаного ResourceSlice

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceSlice

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceSlice): OK

201 (ResourceSlice): Created

401: Unauthorized

delete видалення ResourceSlice

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

Відповідь

200 (ResourceSlice): OK

202 (ResourceSlice): Accepted

401: Unauthorized

deletecollection видалення колекції ResourceSlice

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/resourceslices

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.2 - Ресурси Service

5.2.1 - Service

Service — це іменована абстракція служб програмного забезпечення (наприклад, mysql), що складається з локального порту (наприклад, 3306), який прослуховує проксі, і селектора, який визначає, які Podʼи будуть відповідати на запити, надіслані через проксі.

apiVersion: v1

import "k8s.io/api/core/v1"

Service

Service — це іменована абстракція служб програмного забезпечення (наприклад, mysql), що складається з локального порту (наприклад, 3306), який прослуховує проксі, і селектора, який визначає, які Podʼи будуть відповідати на запити, надіслані через проксі.

ServiceSpec

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 зберігатимуться під час злиття

    Список портів, які відкриває Service. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

    ServicePort містить інформацію про порт Service.

    • ports.port (int32), обовʼязково

      Порт, який буде відкритий цим Service.

    • ports.targetPort (IntOrString)

      Номер або імʼя порту для доступу до 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. Допустимі значення - або:

  • 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 мають однакове значення.

    Це поле може містити максимум два записи (IP-адреси подвійного стека в будь-якому порядку). Ці IP-адреси повинні відповідати значенням поля ipFamilies. Поля clusterIPs та ipFamilies керуються полем ipFamilyPolicy. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

  • externalIPs ([]string)

    Atomic: буде замінено під час злиття

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

  • sessionAffinity (string)

    Підтримує "ClientIP" і "None". Використовується для підтримки спорідненості сеансів. Вмикає спорідненість сеансів на основі IP-адреси клієнта. Значення повинно бути ClientIP або None. Стандартне значення — None. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

  • loadBalancerIP (string)

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

  • loadBalancerSourceRanges ([]string)

    Atomic: буде замінено під час злиття

    Якщо вказано і підтримується платформою, це обмежить трафік через балансувальник навантаження постачальника хмари до вказаних IP-адрес клієнтів. Це поле буде ігноруватися, якщо постачальник хмари не підтримує цю функцію. Більше інформації: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

  • loadBalancerClass (string)

    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 клієнта.

      • sessionAffinityConfig.clientIP.timeoutSeconds (int32)

        timeoutSeconds задає час залипання сесії типу ClientIP у секундах. Значення повинно бути >0 && <=86400 (для 1 дня), якщо ServiceAffinity == "ClientIP". Стандартне значення — 10800 (3 години).

  • allocateLoadBalancerNodePorts (boolean)

    allocateLoadBalancerNodePorts визначає, чи будуть автоматично виділені NodePorts для Service з типом LoadBalancer. Стандартне значення — "true". Його можна встановити у "false", якщо балансувальник навантаження кластера не покладається на NodePorts. Якщо абонент запитує конкретні NodePorts (вказуючи значення), ці запити будуть виконані, незалежно від цього поля. Це поле можна встановити лише для Service з типом LoadBalancer і воно буде очищено, якщо тип буде змінено на будь-який інший тип.

  • trafficDistribution (string)

    TrafficDistribution надає спосіб виразити вподобання щодо того, як розподіляти трафік до точок доступу сервісу. Реалізації можуть використовувати це поле як підказку, але не зобовʼязані суворо дотримуватися вказівок. Якщо поле не встановлене, реалізація застосує свою стандартну стратегію маршрутизації. Якщо встановлено значення "PreferClose", реалізації повинні надавати пріоритет точкам доступу, які топологічно близькі (наприклад, у тій самій зоні). Це бета-поле і потребує ввімкнення функції ServiceTrafficDistribution.

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)

      Atomic: буде замінено під час злиття

      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, повинен мати запис у цьому списку.

        **

        • loadBalancer.ingress.ports.port (int32), обовʼязково

          Port — це номер порту Service, стан якого записаний тут.

        • loadBalancer.ingress.ports.protocol (string), обовʼязково

          Protocol — це протокол порту Service, стан якого записаний тут. Підтримувані значення: "TCP", "UDP", "SCTP".

        • loadBalancer.ingress.ports.error (string)

          Error — це запис проблеми з портом Service. Формат помилки має відповідати наступним правилам:

          • значення вбудованих помилок повинні бути визначені у цьому файлі та повинні використовувати CamelCase імена;
          • значення помилок, специфічних для хмарних провайдерів, повинні мати імена, які відповідають формату foo.example.com/CamelCase.

ServiceList

ServiceList містить список Serviceʼів.

Операції

get отримати вказаний Service

HTTP запит

GET /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

401: Unauthorized

get отримати статус вказаного Service

HTTP запит

GET /api/v1/namespaces/{namespace}/services/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Service

HTTP запит

GET /api/v1/namespaces/{namespace}/services

Параметри

Відповідь

200 (ServiceList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Service

HTTP запит

GET /api/v1/services

Параметри

Відповідь

200 (ServiceList): OK

401: Unauthorized

create створення Service

HTTP запит

POST /api/v1/namespaces/{namespace}/services

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Service, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

202 (Service): Accepted

401: Unauthorized

update заміна вказаного Service

HTTP запит

PUT /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Service, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

update заміна статусу вказаного Service

HTTP запит

PUT /api/v1/namespaces/{namespace}/services/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Service, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

patch часткове оновлення вказаного Service

HTTP запит

PATCH /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Service

HTTP запит

PATCH /api/v1/namespaces/{namespace}/services/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

delete видалення Service

HTTP запит

DELETE /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Service): OK

202 (Service): Accepted

401: Unauthorized

deletecollection видалити колекцію Service

HTTP запит

DELETE /api/v1/namespaces/{namespace}/services

Параметри

Відповідь

200 (ServiceList): OK

401: Unauthorized

5.2.2 - Endpoints

Endpoints — є колекцією точок доступу, що фактично утворюють Service.

apiVersion: v1

import "k8s.io/api/core/v1"

Endpoints

Endpoints — є колекцією точок доступу, що фактично утворюють Service.

Name: "mysvc",
Subsets: [
  {
    Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}],
    Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}]
  },
  {
    Addresses: [{"ip": "10.10.3.3"}],
    Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}]
  },
]

  • apiVersion: v1

  • kind: Endpoints

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • subsets ([]EndpointSubset)

    Atomic: буде замінено під час злиття

    Набір всіх точок доступу є обʼєднанням (union) всіх субнаборів. Адреси розміщуються в субнабори відповідно до IP-адрес, які вони поділяють. Одна адреса з кількома портами, деякі з яких готові, а деякі ні (тому що вони належать різним контейнерам), буде відображатися в різних субнаборах для різних портів. Жодна адреса не зʼявиться одночасно в Addresses і NotReadyAddresses в одному субнаборі. Набори адрес і портів, які складають Service.

    EndpointSubset – це група адрес з одним набором портів. Розширений набір точок доступу є декартовим добутком Addresses x Ports. Наприклад, задано:

    {
  Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}],
  Ports:     [{"name": "a", "port": 8675}, {"name": "b", "port": 309}]
}

    Отриманий набір кінцевих точок може виглядати як:

    a: [ 10.10.1.1:8675, 10.10.2.2:8675 ],
b: [ 10.10.1.1:309, 10.10.2.2:309 ]

    • subsets.addresses ([]EndpointAddress)

      Atomic: буде замінено під час злиття

      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)

        Необовʼязково: Вузол, на якому знаходиться ця точка доступу. Це може бути використано для визначення точок доступу що є локальними для вузла.

      • subsets.addresses.targetRef (ObjectReference)

        Посилання на обʼєкт, що надає точку доступу.

    • subsets.notReadyAddresses ([]EndpointAddress)

      Atomic: буде замінено під час злиття

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

      EndpointAddress — це кортеж, що описує одну IP-адресу.

      • subsets.notReadyAddresses.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.notReadyAddresses.hostname (string)

        Імʼя хоста цієї точки доступу

      • subsets.notReadyAddresses.nodeName (string)

        Необовʼязково: Вузол, на якому знаходиться ця точка доступу. Це може бути використано для визначення точок доступу що є локальними для вузла.

      • subsets.notReadyAddresses.targetRef (ObjectReference)

        Посилання на обʼєкт, що надає точку доступу.

    • subsets.ports ([]EndpointPort)

      Atomic: буде замінено під час злиття

      Номери портів, доступні на відповідних 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. Дійсні значення:

EndpointsList

EndpointsList – це список точок доступу.

Операції

get отримати вказані Endpoints

HTTP запит

GET /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Endpoints

HTTP запит

GET /api/v1/namespaces/{namespace}/endpoints

Параметри

Відповідь

200 (EndpointsList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Endpoints

HTTP запит

GET /api/v1/endpoints

Параметри

Відповідь

200 (EndpointsList): OK

401: Unauthorized

create створення Endpoints

HTTP запит

POST /api/v1/namespaces/{namespace}/endpoints

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Endpoints, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

201 (Endpoints): Created

202 (Endpoints): Accepted

401: Unauthorized

update заміна Endpoints

HTTP запит

PUT /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Endpoints, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

201 (Endpoints): Created

401: Unauthorized

patch часткове оновлення Endpoints

HTTP запит

PATCH /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

201 (Endpoints): Created

401: Unauthorized

delete видалення Endpoints

HTTP запит

DELETE /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалити колекцію Endpoints

HTTP запит

DELETE /api/v1/namespaces/{namespace}/endpoints

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.2.3 - EndpointSlice

EndpointSlice представляє підмножину точок доступу, які реалізують сервіс.

apiVersion: discovery.k8s.io/v1

import "k8s.io/api/discovery/v1"

EndpointSlice

EndpointSlice представляє підмножину точок доступу, які реалізують сервіс. Для даного сервісу може існувати декілька обʼєктів EndpointSlice, виділених мітками, які необхідно обʼєднати для отримання повного набору кінцевих точок.

  • apiVersion: discovery.k8s.io/v1

  • kind: EndpointSlice

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • addressType (string), обовʼязково

    addressType вказує тип адреси, яку містить цей EndpointSlice. Усі адреси в цьому сегменті повинні бути одного типу. Це поле є незмінним після створення. Наразі підтримуються такі типи адрес:

    • IPv4: Представляє адресу IPv4.
    • IPv6: Представляє адресу IPv6.
    • FQDN: Представляє повне доменне імʼя (Fully Qualified Domain Name).

  • endpoints ([]Endpoint), обовʼязково

    Atomic: буде замінено під час злиття

    endpoints — список унікальних точок доступу у цьому зрізі. Кожен зріз може містити максимум 1000 точок доступу.

    Точка доступу являє собою окремий логічний “бекенд", що реалізує сервіс.

    • endpoints.addresses ([]string), обовʼязково

      Set: унікальні значення будуть збережені під час злиття

      адреси цієї точки доступу. Вміст цього поля інтерпретується згідно з відповідним полем EndpointSlice addressType. Споживачі повинні обробляти різні типи адрес у контексті власних можливостей. Це поле має містити принаймні одну адресу, але не більше 100. Вважається, що всі вони є взаємозамінними, і клієнти можуть використовувати лише перший елемент. Зверніться до: https://issue.k8s.io/106267

    • endpoints.conditions (EndpointConditions)

      conditions містить інформацію про поточний стан точки доступу.

      EndpointConditions представляє поточний стано точки доступу.

      • endpoints.conditions.ready (boolean)

        ready вказує на те, що ця точка доступу готова приймати трафік, відповідно до системи, яка керує цією точкою доступу. Нульове значення вказує на невідомий стан. У більшості випадків споживачі повинні інтерпретувати цей невідомий стан як готовий. З міркувань сумісності значення ready ніколи не повинно бути "true" для точок доступу, що завершують роботу, за винятком випадків, коли звичайна поведінка готовності явно перевизначена, наприклад, коли пов'язана служба встановила прапорець publishNotReadyAddresses.

      • endpoints.conditions.serving (boolean)

        serving ідентичний ready, за винятком того, що він встановлюється незалежно від завершального стану точок доступу. Ця умова має бути встановлена в true для точки доступу що має стан ready, яка завершує роботу. Якщо вона дорівнює нулю, споживачі повинні відкладати обслуговування до стану готовності.

      • endpoints.conditions.terminating (boolean)

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

    • endpoints.deprecatedTopology (map[string]string)

      deprecatedTopology містить інформацію про топологію, яка є частиною v1beta1 API. Це поле є застарілим і буде вилучено, коли буде вилучено API v1beta1 (не раніше kubernetes v1.24). Хоча це поле може містити значення, воно не може бути записане через v1 API, і будь-які спроби запису до нього будуть проігноровані. Замість цього інформацію про топологію можна знайти у полях zone та nodeName.

    • endpoints.hints (EndpointHints)

      hints містить інформацію, повʼязану з тим, як слід використовувати точку доступу.

      EndpointHints надає підказки, що описують, як слід використовувати точку доступу.

      • endpoints.hints.forZones ([]ForZone)

        Atomic: буде замінено під час злиття

        forZones вказує на зону(и), до якої(их) повинна потрапити ця точка доступу, щоб увімкнути топологічно орієнтовану маршрутизацію.

        ForZone надає інформацію про те, які зони повинні використовувати цю точку доступу.

        • endpoints.hints.forZones.name (string), обовʼязково

          name — назва зони.

    • endpoints.hostname (string)

      ім'я хосту цієї точки доступу. Це поле може використовуватися споживачами точок доступу, щоб відрізняти їх одна від одної (наприклад, в іменах DNS). Кілька точок доступу, які використовують одне й те саме ім'я хосту, слід вважати взаємозамінними (наприклад, кілька значень A в DNS). Повинні бути малими літерами і проходити перевірку DNS-мітки (RFC 1123).

    • endpoints.nodeName (string)

      nodeName — імʼя вузла, на якому розміщено цю точку доступу. Це може бути використано для визначення локальних для вузла точок доступу.

    • endpoints.targetRef (ObjectReference)

      targetRef — посилання на обʼєкт Kubernetes, який представляє цю точку доступу.

    • endpoints.zone (string)

      зона — назва зони, в якій існує ця точка доступу.

  • ports ([]EndpointPort)

    Atomic: буде замінено під час злиття

    ports визначає список мережевих портів, доступних для кожної точки доступу у цьому зрізі. Кожен порт повинен мати унікальну назву. Якщо параметр ports порожній, це означає, що немає визначених портів. Якщо порт визначено зі значенням nil port, це означає "all ports" (всі порти). Кожен зріз може містити максимум 100 портів.

    EndpointPort представляє Port, який використовується EndpointSlice

    • ports.port (int32)

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

    • ports.protocol (string)

      протокол представляє IP-протокол для цього порту. Має бути UDP, TCP або SCTP. Стандартно використовується TCP.

    • ports.name (string)

      name - імʼя цього порту. Усі порти у фрагменті EndpointSlice повинні мати унікальне імʼя. Якщо EndpointSlice є похідним від сервісу Kubernetes, це імʼя відповідає Service.ports[].name. Імʼя має бути або порожнім рядком, або пройти перевірку DNS_LABEL:

      • повинно мати довжину не більше 63 символів.
      • має складатися з малих літер та цифр або символу '-'.
      • повинно починатися і закінчуватися буквено-цифровим символом. Стандартно - порожній рядок.

    • ports.appProtocol (string)

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

EndpointSliceList

EndpointSliceList представляє список зрізів точок доступу

  • apiVersion: discovery.k8s.io/v1

  • kind: EndpointSliceList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]EndpointSlice), обовʼязково

    items — список зрізів точок доступу

Операції

get отримати вказанний EndpointSlice

HTTP запит

GET /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (EndpointSlice): OK

401: Unauthorized

list перелік або перегляд обʼєктів EndpointSlice

HTTP запит

GET /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices

Параметри

Відповідь

200 (EndpointSliceList): OK

401: Unauthorized

list перелік або перегляд обʼєктів EndpointSlice

HTTP запит

GET /apis/discovery.k8s.io/v1/endpointslices

Параметри

Відповідь

200 (EndpointSliceList): OK

401: Unauthorized

create створення EndpointSlice

HTTP запит

POST /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices

Параметри

Відповідь

200 (EndpointSlice): OK

201 (EndpointSlice): Created

202 (EndpointSlice): Accepted

401: Unauthorized

update заміна вказаного EndpointSlice

HTTP запит

PUT /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: EndpointSlice, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (EndpointSlice): OK

201 (EndpointSlice): Created

401: Unauthorized

patch часткове оновлення вказаного EndpointSlice

HTTP запит

PATCH /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (EndpointSlice): OK

201 (EndpointSlice): Created

401: Unauthorized

delete видалення EndpointSlice

HTTP запит

DELETE /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції EndpointSlice

HTTP запит

DELETE /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.2.4 - Ingress

Ingress — це набір правил, які дозволяють вхідним зʼєднанням досягати точок доступу, визначених бекендом.

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

Ingress

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

IngressSpec

IngressSpec описує Ingress, який користувач хоче, щоб існував.

  • defaultBackend (IngressBackend)

    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:

      1. IP-адреси не допускаються. Зараз IngressRuleValue може застосовуватися лише до IP-адреси в Spec батьківського Ingress.
      2. Двокрапка (:) як роздільник не використовується, оскільки порти не допускаються. Зараз порт Ingress неявно визначений як :80 для http і :443 для https.

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

      host може бути "точним" (precise), доменним імʼям без завершальної крапки мережевого хосту (наприклад, "foo.bar.com"), або "wildcard" (маска), що є доменним імʼям з префіксом у вигляді одного символу маски (наприклад, "*.foo.com"). Символ маски '*' повинен зʼявлятися сам по собі як перша мітка DNS і відповідає лише одній мітці. Ви не можете мати мітку маски саму по собі (наприклад, Host == "*"). Запити будуть зіставлятися з полем Host наступним чином:

      1. Якщо host є точним, запит відповідає цьому правилу, якщо заголовок http host дорівнює Host.
      2. Якщо host є маскою, то запит відповідає цьому правилу, якщо заголовок http host дорівнює суфіксу (видаляючи першу мітку) правила маски.

    • rules.http (HTTPIngressRuleValue)

      HTTPIngressRuleValue — це список http-селекторів, що вказують на бекенди. У прикладі: http://<host>/<path>?<searchpart> -> backend, де частини url відповідають RFC 3986, цей ресурс буде використовуватися для зіставлення з усім після останнього '/' і перед першим '?' або '#'.

      • rules.http.paths ([]HTTPIngressPath), обовʼязкове

        Atomic: буде замінено під час злиття

        paths — це набір шляхів, що зіставляють запити з бекендами.

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

        • rules.http.paths.backend (IngressBackend), обовʼязкове

          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 (TypedLocalObjectReference)

    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 представляє статус балансувальника навантаження.

    • loadBalancer.ingress ([]IngressLoadBalancerIngress)

      Atomic: буде замінено під час злиття

      ingress — це список точок входу для балансувальника навантаження.

      IngressLoadBalancerIngress представляє статус точки входу балансувальника навантаження.

      • loadBalancer.ingress.hostname (string)

        hostname встановлюється для точок входу балансувальника навантаження, які базуються на DNS.

      • loadBalancer.ingress.ip (string)

        ip встановлюється для точок входу балансувальника навантаження, які базуються на IP.

      • loadBalancer.ingress.ports ([]IngressPortStatus)

        Atomic: буде замінено під час злиття

        ports надає інформацію про порти, які відкриті цим балансувальником навантаження.

        IngressPortStatus представляє стан помилки порту сервісу.

        • loadBalancer.ingress.ports.port (int32), обовʼязкове

          port — це номер порту точки входу.

        • loadBalancer.ingress.ports.protocol (string), обовʼязкове

          protocol — це протокол порту точки входу. Підтримувані значення: "TCP", "UDP", "SCTP".

        • loadBalancer.ingress.ports.error (string)

          error використовується для запису проблеми з портом сервісу. Формат помилки має відповідати наступним правилам:

          • вбудовані значення помилок повинні бути зазначені в цьому файлі та повинні використовувати CamelCase імена;
          • значення помилок, специфічні для хмарного провайдера, повинні мати імена, які відповідають формату foo.example.com/CamelCase.

IngressList

IngressList — це колекція Ingress.

Операції

get отримати вказаний Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

401: Unauthorized

get отримати статус вказаного Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses

Параметри

Відповідь

200 (IngressList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/ingresses

Параметри

Відповідь

200 (IngressList): OK

401: Unauthorized

create створення Ingress

HTTP запит

POST /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses

Параметри

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

202 (Ingress): Accepted

401: Unauthorized

update заміна вказаного Ingress

HTTP запит

PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

update заміна статусу вказаного Ingress

HTTP запит

PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

patch часткове оновлення вказаного Ingress

HTTP запит

PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Ingress

HTTP запит

PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

delete видалення Ingress

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Ingress

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.2.5 - IngressClass

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

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".

IngressClassList

IngressClassList є колекцією IngressClasses.

  • apiVersion: networking.k8s.io/v1

  • kind: IngressClassList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]IngressClass), обовʼязково

    items це список IngressClasses.

Операції

get отримати вказаний IngressClass

HTTP запит

GET /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IngressClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (IngressClass): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу IngressClass

HTTP запит

GET /apis/networking.k8s.io/v1/ingressclasses

Параметри

Відповідь

200 (IngressClassList): ОК

401: Unauthorized

create створення IngressClass

HTTP запит

POST /apis/networking.k8s.io/v1/ingressclasses

Параметри

Відповідь

200 (IngressClass): ОК

201 (IngressClass): Created

202 (IngressClass): Accepted

401: Unauthorized

update заміна вказаного IngressClass

HTTP запит

PUT /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IngressClass

  • body: IngressClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (IngressClass): ОК

201 (IngressClass): Created

401: Unauthorized

patch часткове оновлення вказаного IngressClass

HTTP запит

PATCH /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IngressClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (IngressClass): ОК

201 (IngressClass): Created

401: Unauthorized

delete видалення IngressClass

HTTP запит

DELETE /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції IngressClass

HTTP запит

DELETE /apis/networking.k8s.io/v1/ingressclasses

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

5.3 - Ресурси конфігурації та зберігання

5.3.1 - ConfigMap

ConfigMap містить конфігураційні дані, які використовуються Podʼами.

apiVersion: v1

import "k8s.io/api/core/v1"

ConfigMap

ConfigMap містить конфігураційні дані, які використовуються Podʼами.

  • apiVersion: v1

  • kind: ConfigMap

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • binaryData (map[string][]byte)

    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.

Операції

get отримати вказаний ConfigMap

HTTP запит

GET /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ConfigMap

HTTP запит

GET /api/v1/namespaces/{namespace}/configmaps

Параметри

Відповідь

200 (ConfigMapList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ConfigMap

HTTP запит

GET /api/v1/configmaps

Параметри

Відповідь

200 (ConfigMapList): OK

401: Unauthorized

create створення ConfigMap

HTTP запит

POST /api/v1/namespaces/{namespace}/configmaps

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ConfigMap, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

201 (ConfigMap): Created

202 (ConfigMap): Accepted

401: Unauthorized

update заміна вказаного ConfigMap

HTTP запит

PUT /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ConfigMap, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

201 (ConfigMap): Created

401: Unauthorized

patch часткове оновлення вказаного ConfigMap

HTTP запит

PATCH /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

201 (ConfigMap): Created

401: Unauthorized

delete видалення ConfigMap

HTTP запит

DELETE /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ConfigMap

HTTP запит

DELETE /api/v1/namespaces/{namespace}/configmaps

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.2 - Secret

Secret зберігає секретні дані певного типу.

apiVersion: v1

import "k8s.io/api/core/v1"

Secret

Secret зберігає секретні дані певного типу. Загальна кількість байт значень у полі Data має бути меншою за MaxSecretSize.

  • apiVersion: v1

  • kind: Secret

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • data (map[string][]byte)

    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.

  • type (string)

    Використовується для полегшення програмної обробки секретних даних. Більше інформації: https://kubernetes.io/docs/concepts/configuration/secret/#secret-types.

SecretList

SecretList — це список обʼєктів Secret.

Операції

get отримати вказаний Secret

HTTP запит

GET /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Secret

HTTP запит

GET /api/v1/namespaces/{namespace}/secrets

Параметри

Response

200 (SecretList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Secret

HTTP запит

GET /api/v1/secrets

Параметри

Response

200 (SecretList): OK

401: Unauthorized

create створення Secret

HTTP запит

POST /api/v1/namespaces/{namespace}/secrets

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Secret, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

201 (Secret): Created

202 (Secret): Accepted

401: Unauthorized

update заміна вказаного Secret

HTTP запит

PUT /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Secret, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

201 (Secret): Created

401: Unauthorized

patch часткове оновлення вказаного Secret

HTTP запит

PATCH /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

201 (Secret): Created

401: Unauthorized

delete видалення Secret

HTTP запит

DELETE /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Response

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Secret

HTTP запит

DELETE /api/v1/namespaces/{namespace}/secrets

Параметри

Response

200 (Status): OK

401: Unauthorized

5.3.3 - CSIDriver

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 не має простору імен.

  • apiVersion: storage.k8s.io/v1

  • kind: CSIDriver

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. metadata.Name вказує назву драйвера CSI, до якого відноситься цей обʼєкт; вона МАЄ бути такою ж, як імʼя, яке повертає виклик CSI GetPluginName() для цього драйвера. Назва драйвера повинна бути не більше 63 символів, починатися і закінчуватися алфавітно-цифровим символом ([a-z0-9A-Z]), з тире (-), крапками (.) та алфавітно-цифровими символами між ними. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (CSIDriverSpec), обовʼязково

    spec представляє специфікацію драйвера CSI.

CSIDriverSpec

CSIDriverSpec — це специфікація CSIDriver.

  • attachобовʼязково (boolean)

    attachобовʼязково вказує, що цей драйвер томів CSI вимагає операцію приєднання (оскільки він реалізує метод CSI ControllerPublishVolume()), і що контролер приєднання та відʼєднання Kubernetes повинен викликати інтерфейс приєднання томів, який перевіряє статус VolumeAttachment і чекає, поки том буде приєднано, перед тим як перейти до монтування. Зовнішній attacher CSI координується з драйвером томів CSI та оновлює статус VolumeAttachment після завершення операції приєднання. Якщо увімкнено функцію CSIDriverRegistry і значення встановлено на false, операція приєднання буде пропущена. В іншому випадку операція приєднання буде викликана.

    Це поле незмінне.

  • fsGroupPolicy (string)

    fsGroupPolicy визначає, чи підтримує базовий том зміну власності та дозволів на том перед монтуванням. Додаткову інформацію дивіться у конкретних значеннях FSGroupPolicy.

    Це поле було незмінним в Kubernetes < 1.29, тепер воно є змінним.

    Стандартне значення 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 визначає, який режим це буде, наприклад, через параметр командного рядка драйвера.

    Це поле було незмінним в Kubernetes < 1.29, тепер воно є змінним.

  • 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:

    "csi.storage.k8s.io/serviceAccount.tokens": {
  "<audience>": {
    "token": <token>,
    "expirationTimestamp": <expiration timestamp in RFC3339>,
  },
  ...
}

    Примітка: Аудиторія в кожному запиті токена повинна бути різною, і не більше одного токена має бути пустим рядком. Для отримання нового токена після закінчення терміну дії можна використовувати 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 для такого тому.

    Для отримання додаткової інформації про реалізацію цього режиму див. https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html. Драйвер може підтримувати один або кілька цих режимів, і в майбутньому можуть бути додані інші режими.

    Це поле знаходиться у стадії бета. Це поле незмінне.

CSIDriverList

CSIDriverList — це колекція обʼєктів CSIDriver.

Операції

get отримати вказаний CSIDriver

HTTP запит

GET /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIDriver

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIDriver): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CSIDriver

HTTP запит

GET /apis/storage.k8s.io/v1/csidrivers

Параметри

Відповідь

200 (CSIDriverList): OK

401: Unauthorized

create створення CSIDriver

HTTP запит

POST /apis/storage.k8s.io/v1/csidrivers

Параметри

Відповідь

200 (CSIDriver): OK

201 (CSIDriver): Created

202 (CSIDriver): Accepted

401: Unauthorized

update заміна вказаного CSIDriver

HTTP запит

PUT /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIDriver

  • body: CSIDriver, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIDriver): OK

201 (CSIDriver): Created

401: Unauthorized

patch часткове оновлення вказаного CSIDriver

HTTP запит

PATCH /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIDriver

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIDriver): OK

201 (CSIDriver): Created

401: Unauthorized

delete видалення CSIDriver

HTTP запит

DELETE /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

Відповідь

200 (CSIDriver): OK

202 (CSIDriver): Accepted

401: Unauthorized

deletecollection видалення колекції CSIDriver

HTTP запит

DELETE /apis/storage.k8s.io/v1/csidrivers

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.4 - CSINode

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, яке вказує на відповідний обʼєкт вузла.

  • apiVersion: storage.k8s.io/v1

  • kind: CSINode

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. metadata.name має бути назвою вузла Kubernetes.

  • spec (CSINodeSpec)

    spec — це специфікація CSINode

CSINodeSpec

CSINodeSpec містить інформацію про специфікації всіх драйверів CSI, встановлених на вузлі.

  • drivers ([]CSINodeDriver), обовʼязково

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа 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)

      Atomic: буде замінено під час злиття

      topologyKeys — це список ключів, підтримуваних драйвером. Коли драйвер ініціалізується в кластері, він надає набір ключів топології, які він розуміє (наприклад, "company.com/zone", "company.com/region"). Коли драйвер ініціалізується на вузлі, він надає ті самі ключі топології разом зі значеннями. Kubelet відображатиме ці ключі топології як мітки на своєму власному обʼєкті вузла. Коли Kubernetes виконує планування з урахуванням топології, він може використовувати цей список для визначення, які мітки він повинен отримати з обʼєкта вузла та передати назад драйверу. Для різних вузлів можуть використовуватися різні ключі топології. Це поле може бути порожнім, якщо драйвер не підтримує топологію.

CSINodeList

CSINodeList — це колекція обʼєктів CSINode.

Операції

get отримати вказаний CSINode

HTTP запит

GET /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CSINode

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSINode): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CSINode

HTTP запит

GET /apis/storage.k8s.io/v1/csinodes

Параметри

Відповідь

200 (CSINodeList): OK

401: Unauthorized

create створення CSINode

HTTP запит

POST /apis/storage.k8s.io/v1/csinodes

Параметри

Відповідь

200 (CSINode): OK

201 (CSINode): Created

202 (CSINode): Accepted

401: Unauthorized

update заміна вказаного CSINode

HTTP запит

PUT /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CSINode

  • body: CSINode, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSINode): OK

201 (CSINode): Created

401: Unauthorized

patch часткове оновлення вказаного CSINode

HTTP запит

PATCH /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CSINode

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSINode): OK

201 (CSINode): Created

401: Unauthorized

delete видалення CSINode

HTTP запит

DELETE /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

Відповідь

200 (CSINode): OK

202 (CSINode): Accepted

401: Unauthorized

deletecollection видалення колекції CSINode

HTTP запит

DELETE /apis/storage.k8s.io/v1/csinodes

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.5 - CSIStorageCapacity

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. Якщо і це не задано, планувальник припускає, що місткість недостатня, і пробує інший вузол.

  • apiVersion: storage.k8s.io/v1

  • kind: CSIStorageCapacity

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Імʼя не має особливого значення. Воно повинно бути піддоменом DNS (допускаються точки, 253 символи). Щоб уникнути конфліктів з іншими драйверами CSI у кластері, рекомендується використовувати csisc-<uuid>, згенероване імʼя або імʼя у зворотному порядку домену, яке закінчується унікальним імʼям драйвера CSI.

    Обʼєкти знаходяться в межах простору імен.

    Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • storageClassName (string), обовʼязково

    storageClassName представляє імʼя StorageClass, до якого відноситься звітна місткість. Воно повинно відповідати тим самим вимогам, що й імʼя обʼєкта StorageClass (не порожнє, піддомен DNS). Якщо цей обʼєкт більше не існує, обʼєкт CSIStorageCapacity застарів і повинен бути видалений його творцем. Це поле незмінне.

  • capacity (Quantity)

    capacity — це значення, яке повідомляє драйвер CSI у своєму GetCapacityResponse для GetCapacityRequest з топологією і параметрами, що відповідають попереднім полям.

    Семантика наразі (CSI spec 1.2) визначена як: доступна місткість у байтах сховища, яка може бути використана для створення томів. Якщо не задано, ця інформація наразі недоступна.

  • maximumVolumeSize (Quantity)

    maximumVolumeSize — це значення, яке повідомляє драйвер CSI у своєму GetCapacityResponse для GetCapacityRequest з топологією і параметрами, що відповідають попереднім полям.

    Це визначено починаючи з CSI spec 1.4.0 як найбільший розмір, який може бути використаний у полі CreateVolumeRequest.capacity_range.required_bytes для створення тому з тими самими параметрами, що й у GetCapacityRequest. Відповідне значення в API Kubernetes — це ResourceRequirements.Requests у запиті на том.

  • nodeTopology (LabelSelector)

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

CSIStorageCapacityList

CSIStorageCapacityList — це колекція обʼєктів CSIStorageCapacity.

Операції

get отримати вказаний CSIStorageCapacity

HTTP запит

GET /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIStorageCapacity): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CSIStorageCapacity

HTTP запит

GET /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities

Параметри

Відповідь

200 (CSIStorageCapacityList): OK

401: Unauthorized

list перелік або перегляд обʼєктів CSIStorageCapacity

HTTP запит

GET /apis/storage.k8s.io/v1/csistoragecapacities

Параметри

Відповідь

200 (CSIStorageCapacityList): OK

401: Unauthorized

create створення CSIStorageCapacity

HTTP запит

POST /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities

Параметри

Відповідь

200 (CSIStorageCapacity): OK

201 (CSIStorageCapacity): Created

202 (CSIStorageCapacity): Accepted

401: Unauthorized

update заміна вказаного CSIStorageCapacity

HTTP запит

PUT /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CSIStorageCapacity, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIStorageCapacity): OK

201 (CSIStorageCapacity): Created

401: Unauthorized

patch часткове оновлення вказаного CSIStorageCapacity

HTTP запит

PATCH /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIStorageCapacity): OK

201 (CSIStorageCapacity): Created

401: Unauthorized

delete видалення CSIStorageCapacity

HTTP запит

DELETE /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CSIStorageCapacity

HTTP запит

DELETE /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.6 - PersistentVolumeClaim

PersistentVolumeClaim — це запит користувача на постійний том і заявка на нього.

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolumeClaim

PersistentVolumeClaim представляє запит користувача на отримання та право на постійний том.

PersistentVolumeClaimSpec

PersistentVolumeClaimSpec описує загальні атрибути пристроїв зберігання та дозволяє вказувати джерело для атрибутів, специфічних для постачальника.

  • accessModes ([]string)

    Atomic: буде замінено під час злиття

    accessModes містить бажані режими доступу, якими повинен користуватися том. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1

  • selector (LabelSelector)

    selector — це запит мітки для томів, які слід враховувати при звʼязуванні.

  • resources (VolumeResourceRequirements)

    resources представляє мінімальні ресурси, якими повинен володіти том. Якщо включено можливість RecoverVolumeExpansionFailure, користувачам дозволяється вказувати вимоги до ресурсів, які нижчі за попереднє значення, але все ще мають бути вищими, ніж місткість, вказана в полі статусу вимоги. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources

    VolumeResourceRequirements описує вимоги до ресурсів збереження для томів.

    • resources.limits (map[string]Quantity)

      Limits описує максимальну кількість дозволених обчислювальних ресурсів. Додаткова інформація: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • resources.requests (map[string]Quantity)

      Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється як Limits, якщо це явно вказано, інакше — як значення, визначене реалізацією. Запити не можуть перевищувати Limits. Додаткова інформація: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

  • volumeName (string)

    volumeName — це посилання на звʼязування з постійним томом, що підтримує цей запит.

  • storageClassName (string)

    storageClassName — це назва StorageClass, необхідного для вимоги. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#class-1

  • volumeMode (string)

    volumeMode визначає тип тому, необхідного для вимоги. Значення Filesystem підтверджується, коли воно не включене у специфікацію вимоги.

Бета-рівень

  • dataSource (TypedLocalObjectReference)

    Поле dataSource може використовуватися для вказівки на:

    • Наявний обʼєкт VolumeSnapshot (snapshot.storage.k8s.io/VolumeSnapshot)
    • Наявний PVC (PersistentVolumeClaim)

    Якщо провайдер або зовнішній контролер може підтримувати вказане джерело даних, він створить новий том на основі вмісту вказаного джерела даних. Коли вмикається функціональна властивість 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.

  • volumeAttributesClassName (string)

    Поле volumeAttributesClassName може бути використане для встановлення VolumeAttributesClass, який буде використано заявкою. Якщо вказано, драйвер CSI створить або оновить том із атрибутами, визначеними у відповідному VolumeAttributesClass. Це поле має інше призначення, ніж storageClassName, і може бути змінене після створення заявки. Порожнє значення означає, що жоден VolumeAttributesClass не буде застосований до заявки, однак не можна скинути це поле на порожне значпння після його встановлення. Якщо не вказано і PersistentVolumeClaim не привʼязано до конкретного PersistentVolume, то контролер томів встановить стандартний VolumeAttributesClass, якщо він існує. Якщо ресурс, на який посилається volumeAttributesClass, не існує, PersistentVolumeClaim отримає стан Pending ("Очікування"), що буде відображено в полі modifyVolumeStatus, доки такий ресурс не зʼявиться. Докладніше: https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/. (Beta) Використання цього поля вимагає ввімкнення функціональної можливості VolumeAttributesClass (стандартно вимкнено).

PersistentVolumeClaimStatus

PersistentVolumeClaimStatus — це поточний статус запиту на постійний том.

  • accessModes ([]string)

    Atomic: буде замінено під час злиття

    accessModes містить фактичні режими доступу, якими володіє том, що підтримує PVC. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1

  • allocatedResourceStatuses (map[string]string)

    allocatedResourceStatuses зберігає статус ресурсу, який змінюється для даного PVC. Імена ключів відповідають стандартному синтаксису міток Kubernetes. Допустимі значення:

    • Ключі без префіксу:
      • storage — місткість тому.
    • Власні ресурси повинні використовувати визначені реалізацією префіксовані імена, наприклад, "example.com/my-custom-resource".

    Крім вищезазначених значень — ключі без префіксу або з префіксом kubernetes.io вважаються зарезервованими й, отже, не можуть використовуватися.

    ClaimResourceStatus може бути в одному з наступних станів:

    • ControllerResizeInProgress: Стан встановлюється, коли контролер зміни розміру починає змінювати розмір тому в панелі управління.
    • ControllerResizeFailed: Стан встановлюється, коли зміна розміру не вдалася у контролері зміни розміру з термінальною помилкою.
    • NodeResizePending: Стан встановлюється, коли контролер зміни розміру завершив зміну розміру тому, але подальша зміна розміру тому необхідна на вузлі.
    • NodeResizeInProgress: Стан встановлюється, коли kubelet починає змінювати розмір тому.
    • NodeResizeFailed: Стан встановлюється, коли зміна розміру не вдалася у kubelet з термінальною помилкою. Тимчасові помилки не встановлюють NodeResizeFailed.

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

    • pvc.status.allocatedResourceStatus['storage'] = "ControllerResizeInProgress"
    • pvc.status.allocatedResourceStatus['storage'] = "ControllerResizeFailed"
    • pvc.status.allocatedResourceStatus['storage'] = "NodeResizePending"
    • pvc.status.allocatedResourceStatus['storage'] = "NodeResizeInProgress"
    • pvc.status.allocatedResourceStatus['storage'] = "NodeResizeFailed"

    Якщо це поле не встановлено, це означає, що операція зміни розміру для даного PVC не виконується.

    Контролер, що отримує оновлення PVC з невідомим раніше resourceName або ClaimResourceStatus, повинен ігнорувати оновлення з метою, для якої він був створений. Наприклад, контролер, який відповідає лише за зміну розміру місткості тому, повинен ігнорувати оновлення PVC, які змінюють інші дійсні ресурси, повʼязані з PVC.

    Це поле альфа-версії та вимагає ввімкнення властивості RecoverVolumeExpansionFailure.

  • allocatedResources (map[string]Quantity)

    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 (map[string]Quantity)

    capacity представляє фактичні ресурси базового тому.

  • conditions ([]PersistentVolumeClaimCondition)

    Patch strategy: злиття за ключем type

    conditions — це поточний стан запиту на постійний том. Якщо базовий постійний том змінюється в розмірі, стан буде встановлено на 'Resizing'.

    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 — це унікальний, короткий, зрозумілий для машини рядок, який вказує причину останнього переходу стану. Якщо він повідомляє "Resizing", це означає, що базовий постійний том змінюється в розмірі.

  • currentVolumeAttributesClassName (string)

    currentVolumeAttributesClassName — це поточна назва VolumeAttributesClass, яку використовує PVC. Якщо не встановлено, то до цього PersistentVolumeClaim не застосовано жодного VolumeAttributeClass. Це бета-поле і вимагає ввімкнення функції VolumeAttributesClass (стандартно вимкнена).

  • modifyVolumeStatus (ModifyVolumeStatus)

    ModifyVolumeStatus представляє обʼєкт статусу операції ControllerModifyVolume. Якщо не встановлено, спроба виконання операції ModifyVolume не відбувається. Це бета-поле і вимагає ввімкнення функції VolumeAttributesClass (стандартно вимкнена).

    ModifyVolumeStatus представляє обʼєкт стану операції ControllerModifyVolume.

    • modifyVolumeStatus.status (string), required

      status — це статус операції ControllerModifyVolume. Він може перебувати в одному з наступних станів:

      • Pending
        Pending вказує на те, що PersistentVolumeClaim не може бути змінений через невиконані вимоги, такі як відсутність вказаного VolumeAttributesClass.
      • InProgress
        InProgress вказує на те, що том наразі модифікується.
      • Infeasible
        Infeasible вказує на те, що запит було відхилено як недійсний драйвером CSI. Щоб усунути помилку, потрібно вказати дійсний VolumeAttributesClass.

      Примітка: Нові статуси можуть бути додані в майбутньому. Споживачі повинні перевіряти наявність невідомих статусів і відповідно обробляти помилки.

    • modifyVolumeStatus.targetVolumeAttributesClassName (string)

      targetVolumeAttributesClassName — імʼя класу VolumeAttributesClass, який зараз узгоджується з PVC

  • phase (string)

    phase представляє поточну фазу запиту на постійний том.

PersistentVolumeClaimList

PersistentVolumeClaimList — це список елементів PersistentVolumeClaim.

Операції

get отримати вказаний PersistentVolumeClaim

HTTP-запит

GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

401: Unauthorized

get отримати статус вказаного PersistentVolumeClaim

HTTP-запит

GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

401: Unauthorized

list перелік або спостереження за обʼєктами типу PersistentVolumeClaim

HTTP-запит

GET /api/v1/namespaces/{namespace}/persistentvolumeclaims

Параметри

Відповідь

200 (PersistentVolumeClaimList): OK

401: Unauthorized

list перелік або спостереження за обʼєктами типу PersistentVolumeClaim

HTTP-запит

GET /api/v1/persistentvolumeclaims

Параметри

Відповідь

200 (PersistentVolumeClaimList): OK

401: Unauthorized

create створити PersistentVolumeClaim

HTTP-запит

POST /api/v1/namespaces/{namespace}/persistentvolumeclaims

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

202 (PersistentVolumeClaim): Accepted

401: Unauthorized

update замінити вказаний PersistentVolumeClaim

HTTP-запит

PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

update замінити статус вказаного PersistentVolumeClaim

HTTP-запит

PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

patch частково оновити вказаний PersistentVolumeClaim

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • body: Patch, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

patch частково оновити статус вказаного PersistentVolumeClaim

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • body: Patch, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

delete видалити PersistentVolumeClaim

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

202 (PersistentVolumeClaim): Accepted

401: Unauthorized

deletecollection видалити колекцію PersistentVolumeClaim

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.7 - PersistentVolume

PersistentVolume (PV) — це ресурс зберігання, який впроваджується адміністратором.

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolume

PersistentVolume (PV) — це ресурс зберігання, який впроваджується адміністратором. Він є аналогом ресурсу Node. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes.

PersistentVolumeSpec

PersistentVolumeSpec — це специфікація постійного тому.

  • accessModes ([]string)

    Atomic: буде замінено під час злиття

    accessModes містить всі способи, якими том може бути змонтований. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes

  • capacity (map[string]Quantity)

    capacity — це опис ресурсів та місткості постійного тому. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#capacity

  • claimRef (ObjectReference)

    claimRef є частиною двостороннього звʼязування між PersistentVolume та PersistentVolumeClaim. Очікується, що він буде ненульовим при звʼязуванні. claim.VolumeName є офіційним звʼязуванням між PV та PVC. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#binding

  • mountOptions ([]string)

    Atomic: буде замінено під час злиття

    mountOptions — це список опцій монтування, наприклад ["ro", "soft"]. Не перевіряється — монтування просто завершиться з помилкою, якщо одна з опцій недійсна. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options

  • nodeAffinity (VolumeNodeAffinity)

    nodeAffinity визначає обмеження, які обмежують доступ до цього тому з певних вузлів. Це поле впливає на планування Podʼів, які використовують цей том.

    VolumeNodeAffinity визначає обмеження, які обмежують доступ до цього тому з певних вузлів.

    • nodeAffinity.required (NodeSelector)

      обовʼязково визначає жорсткі обмеження на вузли, які повинні бути виконані.

      Селектор вузлів представляє обʼєднання результатів одного або кількох запитів по мітках у наборі вузлів; тобто, він представляє операцію АБО для селекторів, представлених термінами селектора вузлів.

      • nodeAffinity.required.nodeSelectorTerms ([]NodeSelectorTerm), обовʼязково

        Atomic: буде замінено під час злиття

        Обовʼязково. Список термінів селектора вузлів. Терміни обʼєднуються операцією OR.

        Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

        • nodeAffinity.required.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за мітками вузлів.

        • nodeAffinity.required.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за полями вузлів.

  • persistentVolumeReclaimPolicy (string)

    persistentVolumeReclaimPolicy визначає, що відбувається з постійним томом після його звільнення від заявки. Валідні варіанти: Retain (стандартно для створених вручну PersistentVolumes), Delete (стандартно для динамічно наданих PersistentVolumes) та Recycle (застаріле). Recycle повинен підтримуватися втулком тому, що забезпечує роботу цього PersistentVolume. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#reclaiming

  • storageClassName (string)

    storageClassName — це назва StorageClass, до якого належить цей постійний том. Порожнє значення означає, що цей том не належить жодному StorageClass.

  • volumeAttributesClassName (string)

    Імʼя VolumeAttributesClass, до якого належить цей постійний том. Порожнє значення не допускається. Якщо це поле не встановлено, це означає, що цей том не належить до жодного VolumeAttributesClass. Це поле змінюване і може бути змінене драйвером CSI після успішного оновлення тому до нового класу. Для непривʼязаного PersistentVolume значення volumeAttributesClassName буде зіставлено з непривʼязаними PersistentVolumeClaim під час процесу привʼязування. Це бета-поле і вимагає ввімкнення функції VolumeAttributesClass (стандартно вимкнена).

  • volumeMode (string)

    volumeMode визначає, чи призначений том для використання з форматованою файловою системою або залишатиметься в необробленому блочному стані. Значення Filesystem мається на увазі, якщо не включено в специфікацію.

Local

  • hostPath (HostPathVolumeSource)

    hostPath представляє теку на хості. Надається розробником або тестувальником. Це корисно лише для одновузлової розробки та тестування! Зберігання на хості жодним чином не підтримується та НЕ ПРАЦЮВАТИМЕ у багатовузловому кластері. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#hostpath

    Представляє шлях на хості, зіставлений зі шляхом у Podʼі. Шляхи томів хосту не підтримують управління власністю або перепризначення міток SELinux.

  • local (LocalVolumeSource)

    local — це безпосередньо приєднане сховище зі спорідненістю до вузла

    Local представляє безпосередньо приєднане сховище зі спорідненістю до вузла (бета-функція)

    • local.path (string), обовʼязкове

      повний шлях до тому на вузлі. Це може бути або тека, або блоковий пристрій (диск, розділ і т.д.).

    • local.fsType (string)

      fsType — це тип файлової системи для монтування. Застосовується лише тоді, коли Path є блоковим пристроєм. Повинен бути тип файлової системи, підтримуваний операційною системою хосту. Наприклад, "ext4", "xfs", "ntfs". Стандартне значення — автоматичний вибір файлової системи, якщо не вказано.

Постійні томи

  • awsElasticBlockStore (AWSElasticBlockStoreVolumeSource)

    awsElasticBlockStore представляє ресурс AWS Disk, який приєднано до машини хосту kubelet і пізніше надано доступ поду. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    Представляє постійний диск AWS.

    • awsElasticBlockStore.volumeID (string), обовʼязково

      volumeID — це унікальний ідентифікатор ресурсу постійного диска в AWS (Amazon EBS volume). Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.fsType (string)

      fsType — це тип файлової системи тому, який ви хочете монтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.partition (int32)

      partition — це розділ у томі, який ви хочете монтувати. Якщо відсутній, то стандартно монтується за назвою тому. Приклади: Для тому /dev/sda1, ви вказуєте розділ як "1". Аналогічно, розділ тому /dev/sda є "0" (або ви можете залишити властивість пустою).

    • awsElasticBlockStore.readOnly (boolean)

      readOnly значення true змусить використовувати параметр readOnly в VolumeMounts. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

  • azureDisk (AzureDiskVolumeSource)

    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.

    • cephfs.monitors ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      monitors — це колекція моніторів Ceph. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.path (string)

      path — необовʼязково: використовується як коренева тека для монтування, стандартно — "/"

    • cephfs.readOnly (boolean)

      readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, встановлюється параметр readOnly в VolumeMounts. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretFile (string)

      secretFile — необовʼязково: secretFile — це шлях до секретів для користувача, стандартне значення — /etc/ceph/user.secret. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretRef (SecretReference)

      secretRef — необовʼязково: secretRef — посилання на Secret для автентифікації користувача. Стандартне значення порожнє. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • cephfs.secretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • cephfs.secretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

    • cephfs.user (string)

      user — необовʼязково: user — імʼя користувача rados, стандартне значення — admin. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

  • cinder (CinderPersistentVolumeSource)

    cinder представляє монтування та підключення тому Cinder на машині хосту kubelet. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md

    Представляє ресурс тому Cinder в OpenStack. Том Cinder повинен існувати перед монтуванням у контейнер. Том також повинен знаходитися в тому ж регіоні, що й kubelet. Томи Cinder підтримують управління власниками та перепризначення міток SELinux.

    • cinder.volumeID (string), обовʼязково

      volumeID — використовується для ідентифікації тому в Cinder. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.fsType (string)

      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)

      Atomic: буде замінено під час злиття

      targetWWNs — необовʼязково: FC вказує всесвітні імена (worldwide names, WWN).

    • fc.wwids ([]string)

      Atomic: буде замінено під час злиття

      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.

  • gcePersistentDisk (GCEPersistentDiskVolumeSource)

    gcePersistentDisk представляє ресурс GCE Disk, який приєднується до хост-машини kubelet і потім експонується для використання в Podʼі. Впроваджується адміністратором. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    Представляє постійний диск в 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 (GlusterfsPersistentVolumeSource)

    glusterfs представляє том Glusterfs, який приєднується до хосту і експонується для використання в Podʼі. Впроваджується адміністратором. Докладніше: https://examples.k8s.io/volumes/glusterfs/README.md

    Представляє монтування Glusterfs, яке існує протягом життєвого циклу Podʼа. Томи Glusterfs не підтримують управління власниками або перепризначенн міток SELinux.

  • iscsi (ISCSIPersistentVolumeSource)

    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)

      Atomic: буде замінено під час злиття

      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 має бути унікальним.

  • nfs (NFSVolumeSource)

    nfs представляє монтування NFS на хості. Впроваджується адміністратором. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#nfs

    Представляє монтування NFS, яке існує протягом життєвого циклу Podʼа. NFS томи не підтримують управління власниками або перевизначення міток SELinux.

  • photonPersistentDisk (PhotonPersistentDiskVolumeSource)

    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.

  • rbd (RBDPersistentVolumeSource)

    rbd представляє монтування Rados Block Device на хості, яке існує протягом життєвого циклу Podʼа. Детальніше: https://examples.k8s.io/volumes/rbd/README.md

    Представляє монтування Rados Block Device, яке існує протягом життєвого циклу Podʼа. RBD томи підтримують управління власниками та перевизначення міток SELinux.

    • rbd.image (string), обовʼязково

      image — імʼя образу rados. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.monitors ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      monitors — колекція моніторів Ceph. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.fsType (string)

      fsType — тип файлової системи тому, який ви хочете змонтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Детальніше: https://kubernetes.io/docs/concepts/storage/volumes#rbd

    • rbd.keyring (string)

      keyring — шлях до ключів для RBDUser. Стандартне значення — /etc/ceph/keyring. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.pool (string)

      pool — імʼя rados pool. Стандартне значення — rbd. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.readOnly (boolean)

      readOnly — встановлює, що монтування RBD тому буде тільки для читання. Стандартне значення — false. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.secretRef (SecretReference)

      secretRef - імʼя Secret автентифікації для RBDUser. Якщо вказано, перевизначає keyring. Стандартне значення — nil. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

      SecretReference представляє посилання на Secret. Воно містить достатньо інформації для отримання Secret в будь-якому просторі імен

      • rbd.secretRef.name (string)

        name — унікальне імʼя ресурсу Secret в просторі імен.

      • rbd.secretRef.namespace (string)

        namespace — визначає простір імен, в якому імʼя Secret повинно бути унікальним.

    • rbd.user (string)

      user — імʼя користувача rados. Стандартне значення — admin. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

  • scaleIO (ScaleIOPersistentVolumeSource)

    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, повʼязаного з цим джерелом тому.

  • storageos (StorageOSPersistentVolumeSource)

    storageOS представляє том StorageOS, який приєднаний до вузла kubelet і змонтований у Pod. Детальніше: https://examples.k8s.io/volumes/storageos/README.md

    Представляє постійний том ресурсу StorageOS.

    • storageos.fsType (string)

      fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.

    • storageos.readOnly (boolean)

      readOnly — стандартне значення — false (читання/запис). Якщо встановлено в true, то монтування тому буде тільки для читання.

    • storageos.secretRef (ObjectReference)

      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 — це час, коли фаза переходила з однієї у іншу, і автоматично скидається до поточного часу кожного разу при переході фази тома.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • message (string)

    message — повідомлення, зрозуміле людині, яке вказує деталі щодо причини, чому том знаходиться у цьому стані.

  • phase (string)

    phase — вказує, чи доступний том, звʼязаний із заявкою або звільнений від заявки. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#phase

  • reason (string)

    reason — короткий рядок у CamelCase, який описує будь-яку помилку і призначений для машинного аналізу і зручного відображення у CLI.

PersistentVolumeList

PersistentVolumeList — це список елементів PersistentVolume.

Операції

get отримати вказаний PersistentVolume

HTTP запит

GET /api/v1/persistentvolumes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

401: Unauthorized

get отримати статус вказаного PersistentVolume

HTTP запит

GET /api/v1/persistentvolumes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

401: Unauthorized

list перелік або перегляд обʼєктів PersistentVolume

HTTP запит

GET /api/v1/persistentvolumes

Параметри

Відповідь

200 (PersistentVolumeList): OK

401: Unauthorized

create створення PersistentVolume

HTTP запит

POST /api/v1/persistentvolumes

Параметри

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

202 (PersistentVolume): Accepted

401: Unauthorized

update заміна вказаного PersistentVolume

HTTP запит

PUT /api/v1/persistentvolumes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: PersistentVolume, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

update заміна статусу вказаного PersistentVolume

HTTP запит

PUT /api/v1/persistentvolumes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: PersistentVolume, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

patch часткове оновлення вказаного PersistentVolume

HTTP запит

PATCH /api/v1/persistentvolumes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

patch часткове оновлення статусу вказаного PersistentVolume

HTTP запит

PATCH /api/v1/persistentvolumes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

delete видалення PersistentVolume

HTTP запит

DELETE /api/v1/persistentvolumes/{name}

Параметри

Відповідь

200 (PersistentVolume): OK

202 (PersistentVolume): Accepted

401: Unauthorized

deletecollection видалення колекції PersistentVolume

HTTP запит

DELETE /api/v1/persistentvolumes

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.8 - StorageClass

StorageClass описує параметри класу сховища, для якого PersistentVolumes можна динамічно виділяти.

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

StorageClass

StorageClass описує параметри класу сховища, для якого PersistentVolumes можна динамічно виділяти.

Класи сховищ не мають простору імен; імʼя класу сховища згідно з etcd знаходиться в ObjectMeta.Name.

  • apiVersion: storage.k8s.io/v1

  • kind: StorageClass

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • provisioner (string), обовʼязково

    provisioner вказує на тип провізора.

  • allowVolumeExpansion (boolean)

    allowVolumeExpansion показує, чи дозволяє клас зберігання розширення тому.

  • allowedTopologies ([]TopologySelectorTerm)

    Atomic: буде замінено під час обʼєднання

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

    Термін селектора топології представляє результат запитів до міток. Нульовий або порожній термін селектора топології не відповідає жодному обʼєкту. Вимоги до них обʼєднуються за принципом AND. Він надає підмножину функціональності як NodeSelectorTerm. Це альфа-версія функції та в майбутньому вона може змінитися.

    • allowedTopologies.matchLabelExpressions ([]TopologySelectorLabelRequirement)

      Atomic: буде замінено під час злиття

      Список вимог до вибору топології за мітками.

      Вимога вибору топології — це селектор, що відповідає заданій мітці. Це альфа-функція і може змінитися в майбутньому.

      • allowedTopologies.matchLabelExpressions.key (string), обовʼязково

        Ключ мітки, до якого застосовується селектор.

      • allowedTopologies.matchLabelExpressions.values ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        Масив рядкових значень. Одне значення повинно відповідати мітці для вибору. Кожен запис у Values поєднується оператором OR.

  • mountOptions ([]string)

    Atomic: буде замінено під час злиття

    mountOptions контролює параметри монтування для динамічно виділених PersistentVolumes цього класу зберігання. Наприклад, ["ro", "soft"]. Не перевіряється — монтування PVs просто не вдасться, якщо один з них недійсний.

  • parameters (map[string]string)

    parameters містить параметри для провайдера, який повинен створити томи цього класу зберігання.

  • reclaimPolicy (string)

    reclaimPolicy контролює політику відновлення для динамічно виділених PersistentVolumes цього класу зберігання. Стандартне значення — Delete.

  • volumeBindingMode (string)

    volumeBindingMode вказує, як PersistentVolumeClaims повинні виділятися та звʼязуватися. Якщо не встановлено, використовується VolumeBindingImmediate. Це поле враховується лише серверами, які включають функцію VolumeScheduling.

StorageClassList

StorageClassList — це колекція класів зберігання.

Операції

get отримати вказаний StorageClass

HTTP запит

GET /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StorageClass

HTTP запит

GET /apis/storage.k8s.io/v1/storageclasses

Параметри

Відповідь

200 (StorageClassList): OK

401: Unauthorized

create створення StorageClass

HTTP запит

POST /apis/storage.k8s.io/v1/storageclasses

Параметри

Відповідь

200 (StorageClass): OK

201 (StorageClass): Created

202 (StorageClass): Accepted

401: Unauthorized

update заміна вказаного StorageClass

HTTP запит

PUT /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageClass

  • body: StorageClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageClass): OK

201 (StorageClass): Created

401: Unauthorized

patch часткове оновлення вказаного StorageClass

HTTP запит

PATCH /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageClass): OK

201 (StorageClass): Created

401: Unauthorized

delete видалення StorageClass

HTTP запит

DELETE /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

Відповідь

200 (StorageClass): OK

202 (StorageClass): Accepted

401: Unauthorized

deletecollection видалення колекції StorageClass

HTTP запит

DELETE /apis/storage.k8s.io/v1/storageclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.9 - StorageVersionMigration v1alpha1

StorageVersionMigration представляє міграцію збережених даних до останньої версії сховища.

apiVersion: storagemigration.k8s.io/v1alpha1

import "k8s.io/api/storagemigration/v1alpha1"

StorageVersionMigration

StorageVersionMigration представляє міграцію збережених даних до останньої версії сховища.

StorageVersionMigrationSpec

Специфіка міграції версії сховища.

  • continueToken (string)

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

  • resource (GroupVersionResource), обовʼязково

    Ресурс, який мігрує. Мігратор надсилає запити до точки доступу, що обслуговує ресурс. Незмінний.

    Імена групи, версії та ресурсу.

    • resource.group (string)

      Імʼя групи.

    • resource.resource (string)

      Імʼя ресурсу.

    • resource.version (string)

      Імʼя версії.

StorageVersionMigrationStatus

Статус міграції версії сховища.

  • conditions ([]MigrationCondition)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Останні доступні спостереження за поточним станом міграції.

    Описує стан міграції на певний момент.

    • conditions.status (string), обовʼязково

      Статус стану, одни з: True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану.

    • conditions.lastUpdateTime (Time)

      Час, коли булі остання зміна стану.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message містить зрозуміле для людини повідомлення з деталями про стан зміни.

    • conditions.reason (string)

      reason умови останньої зміни.

  • resourceVersion (string)

    ResourceVersion для порівняння з кешем GC для виконання міграції. Це поточна версія ресурсу для даної групи, версії та ресурсу, коли kube-controller-manager вперше спостерігає цей ресурс StorageVersionMigration.

StorageVersionMigrationList

StorageVersionMigrationList — колекція міграцій версій сховища.

Операції

get отримати вказаний StorageVersionMigration

HTTP запит

GET /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

401: Unauthorized

get отримати статус вказаного StorageVersionMigration

HTTP запит

GET /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StorageVersionMigration

HTTP запит

GET /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations

Параметри

Відповідь

200 (StorageVersionMigrationList): OK

401: Unauthorized

create створення StorageVersionMigration

HTTP запит

POST /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations

Параметри

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

202 (StorageVersionMigration): Accepted

401: Unauthorized

update заміна вказаного StorageVersionMigration

HTTP запит

PUT /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: StorageVersionMigration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

update заміна статусу вказаного StorageVersionMigration

HTTP запит

PUT /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: StorageVersionMigration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

patch часткове оновлення вказаного StorageVersionMigration

HTTP запит

PATCH /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

patch частковеоновлення статусу вказаного StorageVersionMigration

HTTP запит

PATCH /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

delete видалення StorageVersionMigration

HTTP запит

DELETE /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції StorageVersionMigration

HTTP запит

DELETE /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.10 - Volume

Volume представляє собою іменований том у Pod, до якого може мати доступ будь-який контейнер у Podʼі.

import "k8s.io/api/core/v1"

Volume

Volume становить собою іменований том у Pod, до якого може мати доступ будь-який контейнер у Podʼі.

Відкриті постійні томи

  • persistentVolumeClaim (PersistentVolumeClaimVolumeSource)

    persistentVolumeClaimVolumeSource — це посилання на PersistentVolumeClaim у тому ж просторі імен. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

    PersistentVolumeClaimVolumeSource посилається на PVC користувача в тому ж просторі імен. Цей том знаходить привʼязаний PV та монтує цей том для Podʼа. PersistentVolumeClaimVolumeSource, фактично, є обгорткою навколо іншого типу тому, який належить комусь іншому (системі).

    • persistentVolumeClaim.claimName (string), обовʼязково

      claimName — це назва PersistentVolumeClaim у тому ж просторі імен, що й у Podʼа, який використовує цей том. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

    • persistentVolumeClaim.readOnly (boolean)

      readOnly — Встановлює значення ReadOnly у VolumeMounts. Стандартне значення — false.

Проєкції

  • configMap (ConfigMapVolumeSource)

    configMap — представляє configMap, який повинен заповнити цей том.

    *Адаптує ConfigMap до тому.

    Вміст поля Data цільового ConfigMap буде представлений у томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів, якщо елемент items заповнений конкретними зіставленнями ключів зі шляхами. Томи ConfigMap підтримують керування власністю та перепризначення міток SELinux.

    • configMap.name (string)

      Name — назва обʼєкта ConfigMap, повʼязаного з томом. Це поле є обов\язковим для заповнення, але для забезпечення зворотної сумісності дозволяється залишати його порожнім. Екземпляри цього типу з порожнім значенням тут майже напевно є помилковими. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

    • configMap.optional (boolean)

      optional — вказує, чи ConfigMap або його ключі мають бути визначені.

    • configMap.defaultMode (int32)

      defaultMode є необовʼязковим параметром: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.

    • configMap.items ([]KeyToPath)

      Atomic: буде замінено під час злиття

      Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного ConfigMap буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у ConfigMap, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.

    • secret (SecretVolumeSource)

      secret — представляє secret, який повинен заповнити цей том. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#secret

      *Адаптує Secret до тому.

      Вміст поля Data цільового Secret буде представлений у томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів. Томи Secret підтримують керування власністю та перепризначення міток SELinux.*

    • secret.secretName (string)

      secretName — назва обʼєкта Secret в просторі імен Podʼа, що буде використовуватись. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#secret

    • secret.optional (boolean)

      optional — вказує, чи Secret або його ключі мають бути визначені.

    • secret.defaultMode (int32)

      defaultMode є необовʼязковим параметром: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.

    • secret.items ([]KeyToPath)

      Atomic: буде замінено під час злиття

      Якщо не вказано 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, і результат може бути встановлення інших бітів режимів.

    • downwardAPI.items ([]DownwardAPIVolumeFile)

      Atomic: буде замінено під час злиття

      Items – список файлів тому downward API

  • projected (ProjectedVolumeSource)

    projected — елементи для ресурсів all-in-one Secret, ConfigMap, downward API

    Представляє джерело projected тому

    • projected.defaultMode (int32)

      defaultMode є бітами режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.

    • projected.sources ([]VolumeProjection)

      Atomic: буде замінено під час злиття

      sources — список джерел, які мають бути спроєцьовані. Кожен запис у цьому списку працює з одним джерелом.

      Проєкція, яка може бути спроєцьована разом з іншими підтримуваними типами томів. Тільки одне з цих полів повинно бути встановлене.

      • projected.sources.clusterTrustBundle (ClusterTrustBundleProjection)

        ClusterTrustBundle дозволяє podʼу отримати доступ до поля .spec.trustBundle обʼєктів ClusterTrustBundle через файл з автоматичним оновленням.

        Альфа-функція, контрольована через функціональну можливість ClusterTrustBundleProjection.

        Обʼєкти ClusterTrustBundle можуть бути вибрані за іменем або за комбінацією імені підписувача і селектора міток.

        Kubelet виконує агресивну нормалізацію вмісту PEM, записаного у файлову систему podʼа. Езотеричні функції PEM, такі як міжблочні коментарі та заголовки блоків, видаляються. Сертифікати дедуплікуються. Порядок сертифікатів у файлі довільний, і Kubelet може змінювати його з часом.

        ClusterTrustBundleProjection описує, як вибрати набір обʼєктів ClusterTrustBundle і спроєктувати їх вміст у файлову систему подів.

        • projected.sources.clusterTrustBundle.path (string), обовʼязково

          Відносний шлях від кореня тому для запису пакунка.

        • projected.sources.clusterTrustBundle.labelSelector (LabelSelector)

          Вибирає всі ClusterTrustBundles, які відповідають цьому селектору міток. Має ефект, тільки якщо задано signerName. Взаємовиключне з name. Якщо не задано, інтерпретується як «не збігається ні з чим». Якщо задано, але пусте, інтерпретується як «збігається з усім».

        • projected.sources.clusterTrustBundle.name (string)

          Вибирає один ClusterTrustBundle за назвою об'єкта. Взаємовиключне з signerName та labelSelector.

        • projected.sources.clusterTrustBundle.optional (boolean)

          Якщо true, не блокувати запуск podʼа, якщо посилання на ClusterTrustBundle(и) недоступні. Якщо використовується імʼя, тоді дозволено відсутність вказаного ClusterTrustBundle. Якщо використовується signerName, тоді комбінація signerName і labelSelector може не відповідати жодному ClusterTrustBundle.

        • projected.sources.clusterTrustBundle.signerName (string)

          Виберає усі ClusterTrustBundles, які відповідають цьому імені підписувача. Взаємовиключні з name. Вміст усіх вибраних ClusterTrustBundles буде уніфіковано та дедупліковано.

      • projected.sources.configMap (ConfigMapProjection)

        configMap — інформація про дані ConfigMap, які мають бути спроєцьовані

        *Адаптує ConfigMap для projected тому

        Вміст поля Data цільового ConfigMap буде представлений у projected томі у вигляді файлів, використовуючи ключі у полі даних як назви файлів, якщо елемент items заповнений конкретними зіставленнями ключів зі шляхами. Зверніть увагу, що це ідентично джерелу тому ConfigMap без стандартного режиму.*

        • projected.sources.configMap.name (string)

          Name — назва обʼєкта на який посилаються. Це поле є обов'язковим для заповнення, але для забезпечення зворотної сумісності дозволяється залишати його порожнім. Екземпляри цього типу з порожнім значенням тут майже напевно є помилковими. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • projected.sources.configMap.optional (boolean)

          optional — вказує, чи ConfigMap або його ключі мають бути визначені.

        • projected.sources.configMap.items ([]KeyToPath)

          Atomic: буде замінено під час злиття

          Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного ConfigMap буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у ConfigMap, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.

      • projected.sources.downwardAPI (DownwardAPIProjection)

        downwardAPI — інформація про дані downward API, які мають бути спроєцьовані

        Представляє інформацію downward API для проєцювання у projected том. Зверніть увагу, що це ідентично джерелу тому downward API без стандартного режиму.

        • projected.sources.downwardAPI.items ([]DownwardAPIVolumeFile)

          Atomic: буде замінено під час злиття

          Items — список файлів DownwardAPIVolume

      • projected.sources.secret (SecretProjection)

        secret – інформація про дані Secret, які мають бути спроєцьовані

        *Адаптує Secret для projected тому.

        Вміст поля Data цільового Secret буде представлений у projected томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів. Зверніть увагу, що це ідентично джерелу тому Secret без стандартного режиму.*

        • projected.sources.secret.name (string)

          Name — назва обʼєкта на який посилаються. Це поле є обов'язковим для заповнення, але для забезпечення зворотної сумісності дозволяється залишати його порожнім. Екземпляри цього типу з порожнім значенням тут майже напевно є помилковими. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • projected.sources.secret.optional (boolean)

          optional — вказує, чи Secret або його ключі мають бути визначені.

        • projected.sources.secret.items ([]KeyToPath)

          Atomic: буде замінено під час злиття

          Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного Secret буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у Secret, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.

      • projected.sources.serviceAccountToken (ServiceAccountTokenProjection)

        serviceAccountToken — інформація про дані serviceAccountToken, які мають бути спроєцьовані

        ServiceAccountTokenProjection представляє projected том токена службового облікового запису. Ця проєкція може бути використана для вставки токена службового облікового запису в файлову систему Podʼа для використання з API (сервера API Kubernetes або іншого).

        • projected.sources.serviceAccountToken.path (string), обовʼязково

          path — це шлях відносно точки монтування файлу для проєцювання токена.

        • projected.sources.serviceAccountToken.audience (string)

          audience — це призначений отримувач токена. Отримувач токена повинен ідентифікувати себе із вказаним ідентифікатором в аудиторії токена або, в іншому випадку, повинен відхилити токен. Стандартно audience — це ідентифікатор apiserver.

        • projected.sources.serviceAccountToken.expirationSeconds (int64)

          expirationSeconds — це запитаний термін дійсності токена службового облікового запису. В міру наближення до закінчення терміну дії токена, втулок томів kubelet буде працювати у режимі проактивної ротації токена службового облікового запису. Kubelet буде спробувати почати ротацію токена, якщо токен старше 80 відсотків його часу життя або якщо токен старше 24 годин. Стандартне значення — 1 година і повинно бути принаймні 10 хвилин.

Локальні / Тимчасові теки

  • emptyDir (EmptyDirVolumeSource)

    emptyDir представляє тимчасову теку, яка існує впродовж часу існування Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#emptydir

    Представляє порожню теку для Podʼа. Томи порожніх тек підтримують управління власністю та перепризначення міток SELinux.

    • emptyDir.medium (string)

      medium представляє тип носія для зберігання, який повинен підтримувати цю теку. Стандартне значення — "" (порожній рядок), що означає використання стандартного носія вузла. Повинно бути порожнім рядком (стандартно) або "Memory". Додаткова інформація: Посилання на документацію Kubernetes про EmptyDir

    • emptyDir.sizeLimit (Quantity)

      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.

Постійні томи

  • awsElasticBlockStore (AWSElasticBlockStoreVolumeSource)

    awsElasticBlockStore представляє ресурс AWS Disk, який підключений до хост-машини kubelet і потім доступний Podʼу. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    *Представляє ресурс Persistent Disk в AWS.

    Диск AWS EBS повинен існувати перед підключенням до контейнера. Диск також повинен знаходитися в тій же зоні AWS, що і kubelet. Диск AWS EBS може бути змонтований з приавами читання/запис тільки один раз. Томи AWS EBS підтримують управління власністю та перепризначення міток SELinux.*

    • awsElasticBlockStore.volumeID (string), обовʼязково

      volumeID — це унікальний ідентифікатор постійного дискового ресурсу в AWS (том Amazon EBS). Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.fsType (string)

      fsType — це тип файлової системи тому, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Якщо не вказано, неявно припускається, що це "ext4". Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.partition (int32)

      partition — це розділ у томі, який ви хочете змонтувати. Якщо він не вказаний, то стандартно монтується за назвою тому. Приклади: Для тому /dev/sda1 ви вказуєте розділ "1". Аналогічно, розділ тому для /dev/sda є "0" (або ви можете залишити властивість порожньою).

    • awsElasticBlockStore.readOnly (boolean)

      readOnly — значення true примусово встановлює налаштування readOnly у VolumeMounts. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

  • azureDisk (AzureDiskVolumeSource)

    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.

    • cephfs.monitors ([]string), обовʼязкове

      Atomic: буде замінено під час злиття

      monitors є обовʼязковим: Monitors — це колекція моніторів Ceph. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.path (string)

      path є необовʼязковим: Використовується як корінь монтування, а не як повне дерево Ceph. Стандартне значення — /

    • cephfs.readOnly (boolean)

      readOnly є необовʼязковим: Стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretFile (string)

      secretFile є необовʼязковим: SecretFile — це шлях до вʼязки ключів користувача. Стандартне значення — /etc/ceph/user.secret. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretRef (LocalObjectReference)

      secretRef є необовʼязковим: SecretRef — це посилання на секрет автентифікації для користувача. Стандартне значення — порожнє. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.user (string)

      user є необовʼязковим: User — це імʼя користувача rados. Стандартне значення — admin. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

  • cinder (CinderVolumeSource)

    cinder представляє том Cinder, підключений і змонтований на хост-машині kubelet. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md

    Представляє ресурс тому Cinder в Openstack. Том Cinder повинен існувати перед монтуванням до контейнера. Том також повинен знаходитися в тому ж регіоні, що і kubelet. Томи Cinder підтримують управління власністю та перепризначення міток SELinux.

    • cinder.volumeID (string), обовʼязкове

      volumeID використовується для ідентифікації тому в Cinder. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.fsType (string)

      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

    • cinder.secretRef (LocalObjectReference)

      secretRef є необовʼязковим: вказує на обʼєкт секрету, що містить параметри, які використовуються для підключення до OpenStack.

  • csi (CSIVolumeSource)

    csi (Container Storage Interface) представляє ефемерне сховище, яке обробляється певними зовнішніми драйверами CSI (бета-функція).

    Представляє джерело розташування тому для монтування, керованого зовнішнім драйвером CSI

    • csi.driver (string), обовʼязкове

      driver — це імʼя драйвера CSI, який обробляє цей том. Проконсультуйтеся з адміністратором для отримання правильного імені, зареєстрованого в кластері.

    • csi.fsType (string)

      fsType для монтування. Наприклад, "ext4", "xfs", "ntfs". Якщо не вказано, порожнє значення передається відповідному драйверу CSI, який визначить стандартну файлову систему.

    • csi.nodePublishSecretRef (LocalObjectReference)

      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 може одночасно використовувати як ефемерні томи, так і постійні томи.

    Представляє ефемерний том, який обробляється звичайним драйвером зберігання.

    • ephemeral.volumeClaimTemplate (PersistentVolumeClaimTemplate)

      Буде використовуватись для створення окремого 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.

      • ephemeral.volumeClaimTemplate.spec (PersistentVolumeClaimSpec), обовʼязкове

        Специфікація для PersistentVolumeClaim. Весь вміст копіюється без змін у PVC, який створюється з цього шаблону. Ті ж самі поля, що й у PersistentVolumeClaim, також дійсні тут.

      • ephemeral.volumeClaimTemplate.metadata (ObjectMeta)

        Може містити мітки та анотації, які будуть скопійовані у 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)

      Atomic: буде замінено під час злиття

      targetWWNs є необовʼязковими: FC звертається до всесвітніх імен (WWNs)

    • fc.wwids ([]string)

      Atomic: буде замінено під час злиття

      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.

    • flexVolume.secretRef (LocalObjectReference)

      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.

  • gcePersistentDisk (GCEPersistentDiskVolumeSource)

    gcePersistentDisk представляє ресурс диска GCE, який приєднаний до хост-машини kubelet і потім відкривається для доступу у Podʼі. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    *Представляє ресурс постійного диска в Google Compute Engine.

    Для монтування до контейнера повинен існувати диск GCE PD. Диск також повинен знаходитися в тому ж проєкті GCE та зоні, що й kubelet. Диск GCE PD може бути змонтований лише один раз для читання/запису або багато разів для читання. Диски GCE PD підтримують керування власністю та перепризначення міток SELinux.*

    • gcePersistentDisk.pdName (string), обовʼязково

      pdName — унікальна назва ресурсу PD в GCE. Використовується для ідентифікації диска в GCE. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    • gcePersistentDisk.fsType (string)

      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

    • gcePersistentDisk.readOnly (boolean)

      readOnly тут примусово встановить параметр ReadOnly у VolumeMounts. Стандартне значення — false. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

  • glusterfs (GlusterfsVolumeSource)

    glusterfs представляє монтування Glusterfs на хості, яке діє впрожовж життєвого циклу Podʼа. Додаткова інформація: https://examples.k8s.io/volumes/glusterfs/README.md

    Представляє монтування Glusterfs, яке діє впрожовж життєвого циклу Podʼа. Томи Glusterfs не підтримують керування власністю або перепризначення міток SELinux.

  • iscsi (ISCSIVolumeSource)

    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)

      Atomic: буде замінено під час злиття

      portals — це список цільових порталів ISCSI. Портал — це IP або ip_addr:порт, якщо порт відмінний від типового (зазвичай TCP-порти 860 і 3260).

    • iscsi.readOnly (boolean)

      readOnly тут примусово встановить параметр ReadOnly у VolumeMounts. Стандартне значення — false.

    • iscsi.secretRef (LocalObjectReference)

      secretRef — це Секрет CHAP для автентифікації цілі та ініціатора ISCSI.

  • image (ImageVolumeSource)

    image представляє обʼєкт OCI (образ контейнерна або артефакт), який завантажується та монтується на хост-машині kubelet. Том призначається під час запуску Podʼа в залежності від значення PullPolicy:

    • Always: kubelet завжди намагається завантажити посилання. Створення контейнера завершиться невдачею, якщо завантаження не вдасться.
    • Never: kubelet ніколи не завантажує посилання і використовує лише локальний образ або артефакт. Створення контейнера завершиться невдачею, якщо посилання немає.
    • IfNotPresent: kubelet завантажує посилання, якщо воно вже не присутнє на диску. Створення контейнера завершиться невдачею, якщо посилання немає, а завантаження не вдасться.

    Том буде перепризначатись, якщо pod буде видалено перестворено, що означає, що новий віддалений контент стане доступним при перестворенні Podʼа. Невдача при визначенні або завантаженні образу під час запуску Podʼа блокуватиме запуск контейнерів і може додати значну затримку. У разі невдачі будуть виконані повторні спроби за допомогою стандартного часу зворотнього відліку для томів і про них буде повідомлено у полі reason і message Podʼа.

    Типи обʼєктів, які можуть бути змонтовані цим томом, визначаються реалізацією серодовища виконання контейнерів на хост-машині і, як мінімум, повинні включати всі дійсні типи, підтримувані полем image контейнера. Обʼєкт OCI монтується в одну теку (spec.containers[*].volumeMounts.mountPath), обʼєднуючи шари маніфесту так само, як і для образів контейнерів. Том буде змонтований тільки для читання (ro) та міститиме файли, які не можна виконувати (noexec). Монтування субшляхів для контейнерів не підтримуються (spec.containers[*].volumeMounts.subpath). Поле spec.securityContext.fsGroupChangePolicy не впливає на цей тип тому.

    ImageVolumeSource представляє ресурс тома image.

    • image.pullPolicy (string)

      Політика завантаження OCI об\єктів. Можливі значення:

      • Always: kubelet завжди намагається завантажити посилання. Створення контейнера завершиться невдачею, якщо завантаження не вдасться.
      • Never: kubelet ніколи не завантажує посилання і використовує лише локальний образ або артефакт. Створення контейнера завершиться невдачею, якщо посилання немає.
      • IfNotPresent: kubelet завантажує посилання, якщо воно вже не присутнє на диску. Створення контейнера завершиться невдачею, якщо посилання немає, а завантаження не вдасться.

      Стандартно використовується значення Always, якщо вказано тег :latest, або IfNotPresent в інших випадках.

    • image.reference (string)

      Обовʼязково: Посилання на образ або артефакт, що буде використовуватися. Працює так само, як і поле pod.spec.containers[*].image. Секрети для завантаження (pull secrets) будуть зібрані так само, як і для образу контейнера, за допомогою пошуку облікових даних вузла, секретів для завантаження образів у Service Account та секретів для завантаження образів у специфікації podʼа. Більше інформації: https://kubernetes.io/docs/concepts/containers/images.

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

  • nfs (NFSVolumeSource)

    nfs представляє монтування NFS на хості, яке діє впрожовж життєвого циклу Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#nfs

    Представляє монтування NFS, яке діє впрожовж життєвого циклу Podʼа. Томи NFS не підтримують керування власністю або перепризначення міток SELinux.

  • photonPersistentDisk (PhotonPersistentDiskVolumeSource)

    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.

  • rbd (RBDVolumeSource)

    rbd представляє монтування блочного пристрою Rados на хості, яке діє впродовж життєвого циклу Podʼа. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md

    Представляє монтування блочного пристрою Rados, яке діє впродовж життєвого циклу Podʼа. Томи RBD підтримують керування власністю та перепризначення міток SELinux.

    • rbd.image (string), обовʼязково

      image — це імʼя образу Rados. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.monitors ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      monitors — це колекція моніторів Ceph. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.fsType (string)

      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

    • rbd.pool (string)

      pool — це імʼя пулу Rados. Стандартне значення — rbd. Додаткова інформація: https://exampes.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.readOnly (boolean)

      readOnly тут примусово встановить параметр ReadOnly у VolumeMounts. Стандартне значення — false. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.secretRef (LocalObjectReference)

      secretRef — це імʼя автентифікаційного секрету для користувача RBDUser. Якщо вказано, перевизначає keyring. Стандартне значення — nil. Додаткова інформація: https://exampes.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.user (string)

      user — це імʼя користувача Rados. Стандартне значення — admin. Додаткова інформація: https://exampes.k8s.io/volumes/rbd/README.md#how-to-use-it

  • scaleIO (ScaleIOVolumeSource)

    scaleIO представляє постійний том ScaleIO, приєднаний та змонтований на вузлах Kubernetes.

    ScaleIOVolumeSource представляє постійний том ScaleIO

    • scaleIO.gateway (string), обовʼязково

      gateway — це адреса хоста шлюзу API ScaleIO.

    • scaleIO.secretRef (LocalObjectReference), обовʼязково

      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.

    • storageos.secretRef (LocalObjectReference)

      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. Перший елемент відносного шляху не повинен починатися з "..".

  • fieldRef (ObjectFieldSelector)

    Обовʼязково: Вибирає поле pod: підтримуються лише анотації, мітки, імʼя, uid та простір імен.

  • mode (int32)

    Опціонально: біти режиму, які використовуються для встановлення дозволів на цей файл, повинні бути вісімковим значенням від 0000 до 0777 або десятковим значенням від 0 до 511. У YAML приймаються як вісімкові, так і десяткові значення, у JSON потрібні десяткові значення для бітів режиму. Якщо не вказано, буде використано стандартне значення для тому. Це може конфліктувати з іншими параметрами, що впливають на режим файлу, наприклад, fsGroup, і результат може бути іншим набором бітів режиму.

  • resourceFieldRef (ResourceFieldSelector)

    Вибирає ресурс контейнера: наразі підтримуються лише обмеження та запити ресурсів (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.11 - VolumeAttachment

VolumeAttachment фіксує намір приєднати або відʼєднати вказаний том до/від вказаного вузла.

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

VolumeAttachment

VolumeAttachment фіксує намір приєднати або відʼєднати вказаний том до/від вказаного вузла.

Обʼєкти VolumeAttachment не належать до просторів імен.

  • apiVersion: storage.k8s.io/v1

  • kind: VolumeAttachment

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (VolumeAttachmentSpec), обовʼязково

    spec представляє специфікацію бажаної поведінки при приєднанні/відʼєднанні тому. Заповнюється системою Kubernetes.

  • status (VolumeAttachmentStatus)

    status представляє статус запиту VolumeAttachment. Заповнюється сутністю, що завершує операцію приєднання або відʼєднання, тобто external-attacher.

VolumeAttachmentSpec

VolumeAttachmentSpec — це специфікація запиту на приєднання тому.

  • attacher (string), обовʼязково

    attacher вказує назву драйвера тому, який МАЄ обробити цей запит. Це назва, яку повертає GetPluginName().

  • nodeName (string), обовʼязково

    nodeName представляє вузол, до якого повинен бути приєднаний том.

  • source (VolumeAttachmentSource), обовʼязково

    source представляє том, який повинен бути приєднаний.

    VolumeAttachmentSource представляє том, який повинен бути приєднаний. Зараз лише PersistenVolumes можуть бути приєднані за допомогою зовнішнього attacherʼa, у майбутньому ми можемо дозволити також inline томи в Podʼах. Може бути встановлений лише один елемент.

    • source.inlineVolumeSpec (PersistentVolumeSpec)

      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.

Операції

get отримати вказаний VolumeAttachment

HTTP запит

GET /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

401: Unauthorized

get отримати статус вказаного VolumeAttachment

HTTP запит

GET /apis/storage.k8s.io/v1/volumeattachments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

401: Unauthorized

list перелік абоперегляд обʼєктів типу VolumeAttachment

HTTP запит

GET /apis/storage.k8s.io/v1/volumeattachments

Параметри

Відповідь

200 (VolumeAttachmentList): OK

401: Unauthorized

create створення VolumeAttachment

HTTP запит

POST /apis/storage.k8s.io/v1/volumeattachments

Параметри

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

202 (VolumeAttachment): Accepted

401: Unauthorized

update заміна вказаного VolumeAttachment

HTTP запит

PUT /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: VolumeAttachment, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

update заміна вказаного VolumeAttachment

HTTP запит

PUT /apis/storage.k8s.io/v1/volumeattachments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: VolumeAttachment, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

patch часткове оновлення вказаного VolumeAttachment

HTTP запит

PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

patch часткове оновлення статусу вказаного VolumeAttachment

HTTP запит

PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

delete видалення VolumeAttachment

HTTP запит

DELETE /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

Відповідь

200 (VolumeAttachment): OK

202 (VolumeAttachment): Accepted

401: Unauthorized

deletecollection видалення колекції VolumeAttachment

HTTP запит

DELETE /apis/storage.k8s.io/v1/volumeattachments

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.3.12 - VolumeAttributesClass v1beta1

VolumeAttributesClass представляє специфікацію змінних атрибутів тома, визначених драйвером CSI.

apiVersion: storage.k8s.io/v1beta1

import "k8s.io/api/storage/v1beta1"

VolumeAttributesClass

VolumeAttributesClass представляє специфікацію змінних атрибутів тома, визначених драйвером CSI. Клас можна вказати під час динамічного резервування PersistentVolumeClaims і змінити у специфікації PersistentVolumeClaim після резервування.

VolumeAttributesClassList

VolumeAttributesClassList — це колекція обʼєктів VolumeAttributesClass.

Операції

get отримати вказаний VolumeAttributesClass

HTTP запит

GET /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttributesClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу VolumeAttributesClass

HTTP запит

GET /apis/storage.k8s.io/v1beta1/volumeattributesclasses

Параметри

Відповідь

200 (VolumeAttributesClassList): OK

401: Unauthorized

create створення VolumeAttributesClass

HTTP запит

POST /apis/storage.k8s.io/v1beta1/volumeattributesclasses

Параметри

Відповідь

200 (VolumeAttributesClass): OK

201 (VolumeAttributesClass): Created

202 (VolumeAttributesClass): Accepted

401: Unauthorized

update заміна вказаного VolumeAttributesClass

HTTP запит

PUT /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • body: VolumeAttributesClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttributesClass): OK

201 (VolumeAttributesClass): Created

401: Unauthorized

patch часткове оновлення вказаного VolumeAttributesClass

HTTP запит

PATCH /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttributesClass): OK

201 (VolumeAttributesClass): Created

401: Unauthorized

delete видалення VolumeAttributesClass

HTTP запит

DELETE /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (VolumeAttributesClass): OK

202 (VolumeAttributesClass): Accepted

401: Unauthorized

deletecollection видалення колекції VolumeAttributesClass

HTTP запит

DELETE /apis/storage.k8s.io/v1beta1/volumeattributesclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.4 - Ресурси автентифікації

5.4.1 - ServiceAccount

ServiceAccount повʼязує разом:

  • імʼя, зрозуміле користувачам і, можливо, периферійним системам, для ідентифікації;
  • головну діючу особу, яка може бути автентифікована і авторизована;
  • набір секретів.

apiVersion: v1

import "k8s.io/api/core/v1"

ServiceAccount

ServiceAccount повʼязує разом

  • імʼя, зрозуміле користувачам і, можливо, периферійним системам, для ідентифікації;
  • головну діючу особу, яка може бути автентифікована і авторизована;
  • набір секретів.

  • apiVersion: v1

  • kind: ServiceAccount

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • automountServiceAccountToken (boolean)

    automountServiceAccountToken вказує, чи повинні Podʼи, які працюють від імені цього службового облікового запису, автоматично мати змонтований API токен. Може бути перевизначено на рівні Podʼа.

  • imagePullSecrets ([]LocalObjectReference)

    Atomic: буде замінено під час злиття

    imagePullSecrets — це список посилань на Sercretʼи в тому ж просторі імен для використання при завантаженні будь-яких образів у Podʼах, які використовують цей службовий обліковий запис. ImagePullSecrets відрізняються від Secrets тим, що Secrets можуть бути змонтовані в Pod, а ImagePullSecrets доступні лише для kubelet. Докладніше: https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod

  • secrets ([]ObjectReference)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    secrets — це список секретів у тому ж просторі імен, які Podʼи, що використовують цей службовий обліковий запис, можуть використовувати. Podʼи обмежуються цим списком лише у випадку, якщо цей службовий обліковий запис має анотацію "kubernetes.io/enforce-mountable-secrets" зі значенням "true". Це поле не слід використовувати для пошуку автоматично створених секретів токенів службових облікових записів для використання поза межами Podʼів. Натомість токени можна запитувати безпосередньо за допомогою API TokenRequest або секрети токенів службових облікових записів можна створювати вручну. Докладніше: https://kubernetes.io/docs/concepts/configuration/secret

ServiceAccountList

ServiceAccountList — це список обʼєктів ServiceAccount.

Операції

get отримати вказаний ServiceAccount

HTTP запит

GET /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceAccount): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ServiceAccount

HTTP запит

GET /api/v1/namespaces/{namespace}/serviceaccounts

Параметри

Відповідь

200 (ServiceAccountList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ServiceAccount

HTTP запит

GET /api/v1/serviceaccounts

Параметри

Відповідь

200 (ServiceAccountList): OK

401: Unauthorized

create створення ServiceAccount

HTTP запит

POST /api/v1/namespaces/{namespace}/serviceaccounts

Параметри

Відповідь

200 (ServiceAccount): OK

201 (ServiceAccount): Created

202 (ServiceAccount): Accepted

401: Unauthorized

update заміна вказаного ServiceAccount

HTTP запит

PUT /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ServiceAccount, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceAccount): OK

201 (ServiceAccount): Created

401: Unauthorized

patch часткове оновлення вказаного ServiceAccount

HTTP запит

PATCH /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceAccount): OK

201 (ServiceAccount): Created

401: Unauthorized

delete видалення ServiceAccount

HTTP запит

DELETE /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ServiceAccount): OK

202 (ServiceAccount): Accepted

401: Unauthorized

deletecollection видалення колекції ServiceAccount

HTTP запит

DELETE /api/v1/namespaces/{namespace}/serviceaccounts

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.4.2 - TokenRequest

TokenRequest запитує токен для вказаного службового облікового запису.

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenRequest

TokenRequest запитує токен для вказаного службового облікового запису.

TokenRequestSpec

TokenRequestSpec містить параметри запиту токена, надані клієнтом.

  • audiences ([]string), обовʼязково

    Atomic: буде замінено під час злиття

    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

Параметри

  • name (в шляху): string, обовʼязково

    name of the TokenRequest

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: TokenRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповіді

200 (TokenRequest): OK

201 (TokenRequest): Created

202 (TokenRequest): Accepted

401: Unauthorized

5.4.3 - TokenReview

TokenReview намагається автентифікувати токен вже відомому користувачу.

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenReview

TokenReview намагається автентифікувати токен вже відомому користувачу. Примітка: запити TokenReview можуть кешуватися dnekrjv автентифікації вебхука в kube-apiserver.

TokenReviewSpec

TokenReviewSpec є описом запиту автентифікації токена.

  • audiences ([]string)

    Atomic: буде замінено під час злиття

    Audiences — це список ідентифікаторів, які сервер ресурсів, представлений токеном, розпізнає як. Автентифікатори токенів, що володіють інформацією про аудиторію, перевірять, що токен був призначений принаймні для однієї з аудиторій у цьому списку. Якщо аудиторії не надані, типово використовується аудиторія Kubernetes apiserver.

  • token (string)

    Token — це непрозорий токен на предʼявника.

TokenReviewStatus

TokenReviewStatus — це результат запиту автентифікації токена.

  • audiences ([]string)

    Atomic: буде замінено під час злиття

    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.

    • user.extra (map[string][]string)

      Будь-яка додаткова інформація, надана автентифікатором.

    • user.groups ([]string)

      Atomic: буде замінено під час злиття

      Назви груп, до яких належить цей користувач.

    • user.uid (string)

      Унікальне значення, яке ідентифікує цього користувача з плином часу. Якщо цього користувача видаляють і додають іншого користувача з тим же імʼям, вони матимуть різні UID.

    • user.username (string)

      Імʼя, яке унікально ідентифікує цього користувача серед усіх активних користувачів.

Операції

create створення TokenReview

HTTP запит

POST /apis/authentication.k8s.io/v1/tokenreviews

Параметри запиту

Відповідь

200 (TokenReview): OK

201 (TokenReview): Created

202 (TokenReview): Accepted

401: Unauthorized

5.4.4 - CertificateSigningRequest

Обʼєкти CertificateSigningRequest надають механізм для отримання сертифікатів x509 шляхом подання запиту на підписання сертифіката та його асинхронного схвалення і видачі.

apiVersion: certificates.k8s.io/v1

import "k8s.io/api/certificates/v1"

CertificateSigningRequest

Обʼєкти CertificateSigningRequest надають механізм для отримання сертифікатів x509 шляхом подання запиту на підписання сертифіката та його асинхронного схвалення і видачі.

Kubelets використовують цей API для отримання:

  1. клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client-kubelet").
  2. серверних сертифікатів для TLS-точок доступу, до яких kube-apiserver може підключатися безпечно (з використанням signerName "kubernetes.io/kubelet-serving").

Цей API може бути використаний для запиту клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client") або для отримання сертифікатів від нестандартних підписувачів, що не належать до Kubernetes.

  • apiVersion: certificates.k8s.io/v1

  • kind: CertificateSigningRequest

  • metadata (ObjectMeta)

  • spec (CertificateSigningRequestSpec), обовʼязково

    spec містить запит на сертифікат і є незмінним після створення. Тільки поля request, signerName, expirationSeconds та usages можуть бути встановлені під час створення. Інші поля визначаються Kubernetes і не можуть бути змінені користувачами.

  • status (CertificateSigningRequestStatus)

    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:

    1. "kubernetes.io/kube-apiserver-client": видає клієнтські сертифікати, які можна використовувати для автентифікації до kube-apiserver. Запити для цього підписувача ніколи не затверджуються автоматично kube-controller-manager, можуть бути видані контролером "csrsigning" у kube-controller-manager.
    2. "kubernetes.io/kube-apiserver-client-kubelet": видає клієнтські сертифікати, які kubelets використовують для автентифікації до kube-apiserver. Запити для цього підписувача можуть бути автоматично затверджені контролером "csrapproving" у kube-controller-manager і можуть бути видані контролером "csrsigning" у kube-controller-manager.
    3. "kubernetes.io/kubelet-serving": видає серверні сертифікати, які kubelets використовують для обслуговування TLS-точок доступу, до яких kube-apiserver може підключатися безпечно. Запити для цього підписувача ніколи не затверджуються автоматично kube-controller-manager і можуть бути видані контролером "csrsigning" у kube-controller-manager.

    Докладніше: https://k8s.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers

    Можуть також бути вказані нестандартні signerNames. Підписувач визначає:

    1. Розповсюдження довіри: як розповсюджуються довірчі пакети (CA bundles).
    2. Дозволені субʼєкти: та поведінка, коли запитується недозволений субʼєкт.
    3. Обовʼязкові, дозволені або заборонені розширення x509 у запиті (включаючи те, чи дозволені subjectAltNames, які типи, обмеження на дозволені значення) та поведінка при запиті недозволеного розширення.
    4. Обовʼязкові, дозволені або заборонені ключові використання / розширені ключові використання.
    5. Термін дії сертифіката: чи він фіксований підписувачем, налаштовується адміністратором.
    6. Чи дозволені запити на сертифікати CA.

  • expirationSeconds (int32)

    expirationSeconds — це запитувана тривалість дії виданого сертифіката. Підписувач сертифіката може видати сертифікат з іншою тривалістю дії, тому клієнт повинен перевірити різницю між полями notBefore і notAfter у виданому сертифікаті, щоб визначити фактичну тривалість.

    Реалізації v1.22+ вбудованих підписувачів Kubernetes дотримуватимуться цього поля, якщо запитувана тривалість не перевищує максимальну тривалість, яку вони дозволяють відповідно до прапорця CLI --cluster-signing-duration для контролера Kubernetes.

    Підписувачі сертифікатів можуть не дотримуватися цього поля з різних причин:

    1. Старий підписувач, який не знає про це поле (наприклад, вбудовані реалізації до v1.22)
    2. Підписувач, чия налаштована максимальна тривалість коротша за запитувану тривалість
    3. Підписувач, чия налаштована мінімальна тривалість довша за запитувану тривалість

    Мінімальне дійсне значення для 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".

    Дійсні значення: "signing", "digital signature", "content commitment", "key encipherment", "key agreement", "data encipherment", "cert sign", "crl sign", "encipher only", "decipher only", "any", "server auth", "client auth", "code signing", "email protection", "s/mime", "ipsec end system", "ipsec tunnel", "ipsec user", "timestamping", "ocsp signing", "microsoft sgc", "netscape sgc"

  • username (string)

    username містить імʼя користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.

CertificateSigningRequestStatus

CertificateSigningRequestStatus містить умови, що використовуються для позначення статусу запиту (схвалено/відхилено/не вдалося), та виданий сертифікат.

  • certificate ([]byte)

    Atomic: буде замінено під час злиття

    certificate заповнюється виданим сертифікатом підписувача після наявності умови "Approved". Це поле встановлюється через субресурс /status. Після заповнення це поле є незмінним.

    Якщо запит на підписання сертифіката відхилено, додається умова типу "Denied", і це поле залишається порожнім. Якщо підписувач не може видати сертифікат, додається умова типу "Failed", і це поле залишається порожнім.

    Вимоги до валідації:

    1. certificate повинно містити один або більше PEM блоків.
    2. Усі PEM блоки повинні мати мітку "CERTIFICATE", не містити заголовків, а закодовані дані повинні бути структурою сертифіката BER-кодованого ASN.1, як описано в розділі 4 RFC5280.
    3. Не-PEM вміст може зʼявлятися до або після блоків PEM "CERTIFICATE" і не перевіряється, щоб дозволити пояснювальний текст, як описано в розділі 5.2 RFC7468.

    Якщо в наявності більше одного блоку PEM, і визначення запитуваного spec.signerName не вказує інше, перший блок є виданим сертифікатом, а наступні блоки слід розглядати як проміжні сертифікати та представлятись під час TLS-handshake.

    Сертифікат закодований у форматі PEM.

    При серіалізації у форматі JSON або YAML дані додатково кодуються в base64, тому вони складаються з:

    base64(
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
)

  • conditions ([]CertificateSigningRequestCondition)

    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.

  • apiVersion: certificates.k8s.io/v1

  • kind: CertificateSigningRequestList

  • metadata (ListMeta)

  • items ([]CertificateSigningRequest), обовʼязково

    items — це колекція обʼєктів CertificateSigningRequest.

Операції

get отримати вказаний CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

401: Unauthorized

get отримати схвалення вказаного CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

401: Unauthorized

get отримати статус вказаного CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests

Параметри

Відповідь

200 (CertificateSigningRequestList): OK

401: Unauthorized

create створення CertificateSigningRequest

HTTP запит

POST /apis/certificates.k8s.io/v1/certificatesigningrequests

Параметри

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

202 (CertificateSigningRequest): Accepted

401: Unauthorized

update заміна вказаного CertificateSigningRequest

HTTP запит

PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: CertificateSigningRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

update заміна підтвердження вказаного CertificateSigningRequest

HTTP запит

PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: CertificateSigningRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

update заміна статусу вказаного CertificateSigningRequest

HTTP запит

PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: CertificateSigningRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

patch часткове оновлення вказаного CertificateSigningRequest

HTTP запит

PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

patch часткове оновлення затвердження вказаного CertificateSigningRequest

HTTP запит

PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

patch часткове оновлення статусу вказаного CertificateSigningRequest

HTTP запит

PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

delete видалення CertificateSigningRequest

HTTP запит

DELETE /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CertificateSigningRequest

HTTP запит

DELETE /apis/certificates.k8s.io/v1/certificatesigningrequests

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.4.5 - ClusterTrustBundle v1alpha1

ClusterTrustBundle — це кластерний контейнер для X.

apiVersion: certificates.k8s.io/v1alpha1

import "k8s.io/api/certificates/v1alpha1"

ClusterTrustBundle

ClusterTrustBundle — це кластерний контейнер для довірчих якорів X.509 (кореневих сертифікатів).

Обʼєкти ClusterTrustBundle вважаються доступними для читання будь-яким автентифікованим користувачем у кластері, оскільки їх можна монтувати в Pod за допомогою проєкції clusterTrustBundle. Усі службові облікові записи типово мають доступ на читання ClusterTrustBundles. Користувачі, які мають доступ лише на рівні простору імен у кластері, можуть читати ClusterTrustBundles, використовуючи serviceaccount, до якого вони мають доступ.

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

  • apiVersion: certificates.k8s.io/v1alpha1

  • kind: ClusterTrustBundle

  • metadata (ObjectMeta)

    metadata містить метадані обʼєкта.

  • spec (ClusterTrustBundleSpec), обовʼязково

    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.

  • apiVersion: certificates.k8s.io/v1alpha1

  • kind: ClusterTrustBundleList

  • metadata (ListMeta)

    metadata містить метадані списку.

  • items ([]ClusterTrustBundle), обовʼязково

    items — це колекція обʼєктів ClusterTrustBundle.

Операції

get отримати вказаний ClusterTrustBundle

HTTP запит

GET /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterTrustBundle): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ClusterTrustBundle

HTTP запит

GET /apis/certificates.k8s.io/v1alpha1/clustertrustbundles

Параметри

Відповідь

200 (ClusterTrustBundleList): OK

401: Unauthorized

create створення ClusterTrustBundle

HTTP запит

POST /apis/certificates.k8s.io/v1alpha1/clustertrustbundles

Параметри

Відповідь

200 (ClusterTrustBundle): OK

201 (ClusterTrustBundle): Created

202 (ClusterTrustBundle): Accepted

401: Unauthorized

update заміна вказаного ClusterTrustBundle

HTTP запит

PUT /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • body: ClusterTrustBundle, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterTrustBundle): OK

201 (ClusterTrustBundle): Created

401: Unauthorized

patch часткове оновлення вказаного ClusterTrustBundle

HTTP запит

PATCH /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterTrustBundle): OK

201 (ClusterTrustBundle): Created

401: Unauthorized

delete видалення ClusterTrustBundle

HTTP запит

DELETE /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ClusterTrustBundle

HTTP запит

DELETE /apis/certificates.k8s.io/v1alpha1/clustertrustbundles

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.4.6 - SelfSubjectReview

SelfSubjectReview містить інформацію про користувача, яку має kube-apiserver про користувача, що робить цей запит.

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

SelfSubjectReview

SelfSubjectReview містить інформацію про користувача, яку має kube-apiserver про користувача, що робить цей запит. При використанні імперсоніфікації, користувачі отримають інформацію про користувача, якого вони імітують. Якщо використовується імперсоніфікація або автентифікація заголовка запиту, будь-які додаткові ключі будуть ігноруватися і повертатися у нижньому регістрі.

SelfSubjectReviewStatus

SelfSubjectReviewStatus заповнюється kube-apiserver і відсилається користувачу.

  • userInfo (UserInfo)

    Атрибути користувача, який робить цей запит.

    UserInfo містить інформацію про користувача, необхідну для реалізації інтерфейсу user.Info.

    • userInfo.extra (map[string][]string)

      Будь-яка додаткова інформація, надана автентифікатором.

    • userInfo.groups ([]string)

      Atomic: буде замінено під час злиття

      Назви груп, до яких належить цей користувач.

    • userInfo.uid (string)

      Унікальне значення, що ідентифікує цього користувача з плином часу. Якщо цей користувач буде видалений і інший користувач з таким самим іменем буде доданий, вони матимуть різні UID.

    • userInfo.username (string)

      Імʼя, яке унікально ідентифікує цього користувача серед усіх активних користувачів.

Операції

create створення SelfSubjectReview

HTTP запит

POST /apis/authentication.k8s.io/v1/selfsubjectreviews

Параметри

Відповідь

200 (SelfSubjectReview): OK

201 (SelfSubjectReview): Created

202 (SelfSubjectReview): Accepted

401: Unauthorized

5.5 - Ресурси авторизації

5.5.1 - LocalSubjectAccessReview

LocalSubjectAccessReview перевіряє, чи може користувач або група виконати дію в заданому просторі імен.

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

LocalSubjectAccessReview

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

  • apiVersion: authorization.k8s.io/v1

  • kind: LocalSubjectAccessReview

  • metadata (ObjectMeta)

    Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (SubjectAccessReviewSpec), обовʼязково

    Специфікація містить інформацію про запит, який оцінюється. spec.namespace повинен дорівнювати простору імен, щодо якого зроблено запит. Якщо поле порожнє, встановлюється стандартне значення.

  • status (SubjectAccessReviewStatus)

    Статус заповнюється сервером і вказує, чи дозволено запит, чи ні.

Операції

create створення LocalSubjectAccessReview

HTTP запит

POST /apis/authorization.k8s.io/v1/namespaces/{namespace}/localsubjectaccessreviews

Параметри

Відповідь

200 (LocalSubjectAccessReview): OK

201 (LocalSubjectAccessReview): Created

202 (LocalSubjectAccessReview): Accepted

401: Unauthorized

5.5.2 - SelfSubjectAccessReview

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.fieldSelector (FieldSelectorAttributes)

      fieldSelector описує обмеження доступу на основі поля. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, ви повинні ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      FieldSelectorAttributes вказує на доступ, обмежений за полем. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.fieldSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, який буде включено в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.fieldSelector.requirements ([]FieldSelectorRequirement)

        Atomic: буде замінено під час злиття

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

        FieldSelectorRequirement — це селектор, який містить значення, ключ та оператор, який повʼязує ключ та значення.

        • resourceAttributes.fieldSelector.requirements.key (string), обовʼязково

          key — це ключ-селектор поля, до якого застосовується вимога.

        • resourceAttributes.fieldSelector.requirements.operator (string), обовʼязково

          operator представляє стосунок ключа до набору значень. Дійсні оператори: In, NotIn, Exists, DoesNotExist. Список операторів може розширюватися в майбутньому.

        • resourceAttributes.fieldSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це масив строкових значень. Якщо оператор — In або NotIn, масив values не може бути порожнім. Якщо ж оператор — Exists або DoesNotExist, масив values повинен бути порожнім.

    • resourceAttributes.group (string)

      Group — це API-група ресурсу. "*" означає всі.

    • resourceAttributes.labelSelector (LabelSelectorAttributes)

      labelSelector описує обмеження доступу на основі міток. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, потрібно ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      LabelSelectorAttributes вказує на доступ, обмежений за мітками. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.labelSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, яка буде включена в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.labelSelector.requirements ([]LabelSelectorRequirement)

        Atomic: буде замінено під час злиття

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

        Вимога до селектора мітки — це селектор, який містить значення, ключ і оператор, який повʼязує ключ і значення.

        • resourceAttributes.labelSelector.requirements.key (string), обовʼязково

          key — це ключ мітки, до якого застосовується селектор.

        • resourceAttributes.labelSelector.requirements.operator (string), обовʼязково

          operator представляє стосунок ключа до набору значень. Дійсні оператори: In, NotIn, Exists та DoesNotExist.

        • resourceAttributes.labelSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це масив строкових значень. Якщо оператор — In або NotIn, масив values не може бути порожнім. Якщо ж оператор — Exists або DoesNotExist, масив values повинен бути порожнім. Цей масив замінюється під час стратегічного злиття патчу.

    • 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

Параметри

Відповідь

200 (SelfSubjectAccessReview): OK

201 (SelfSubjectAccessReview): Created

202 (SelfSubjectAccessReview): Accepted

401: Unauthorized

5.5.3 - SelfSubjectRulesReview

SelfSubjectRulesReview перелічує набір дій, які поточний користувач може виконувати в межах простору імен.

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SelfSubjectRulesReview

SelfSubjectRulesReview перелічує набір дій, які поточний користувач може виконувати в межах простору імен. Отриманий список дій може бути неповним залежно від режиму авторизації сервера та будь-яких помилок, які виникли під час оцінки. SelfSubjectRulesReview слід використовувати інтерфейсами користувача для показу/приховування дій або швидкого надання кінцевому користувачеві можливості оцінити свої дозволи. Він НЕ ПОВИНЕН використовуватися зовнішніми системами для прийняття рішень щодо авторизації, оскільки це викликає проблеми з підміною, тривалістю життя кешу/відкликанням та правильністю. SubjectAccessReview і LocalAccessReview є правильним способом делегування рішень щодо авторизації до API сервера.

  • apiVersion: authorization.k8s.io/v1

  • kind: SelfSubjectRulesReview

  • metadata (ObjectMeta)

    Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (SelfSubjectRulesReviewSpec), обовʼязково

    Специфікація містить інформацію про запит, який оцінюється.

  • status (SubjectRulesReviewStatus)

    Статус заповнюється сервером і вказує на набір дій, які користувач може виконувати.

    SubjectRulesReviewStatus містить результат перевірки правил. Ця перевірка може бути неповною залежно від набору авторизаторів, з якими налаштовано сервер, і будь-яких помилок, що виникли під час оцінки. Оскільки правила авторизації є адитивними, якщо правило зʼявляється у списку, можна безпечно припустити, що субʼєкт має цей дозвіл, навіть якщо цей список неповний.

    • status.incomplete (boolean), обовʼязково

      Incomplete встановлюється у true, коли правила, повернуті цим викликом, є неповними. Це найчастіше зустрічається, коли авторизатор, такий як зовнішній авторизатор, не підтримує оцінку правил.

    • status.nonResourceRules ([]NonResourceRule), обовʼязково

      Atomic: буде замінено під час злиття

      NonResourceRules — це список дій, які субʼєкт має право виконувати щодо не-ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.

      NonResourceRule містить інформацію, яка описує правило для не-ресурсу

      • status.nonResourceRules.verbs ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        Verb — це список дієслів API Kubernetes для не-ресурсів, таких як: get, post, put, delete, patch, head, options. "*" означає всі.

      • status.nonResourceRules.nonResourceURLs ([]string)

        Atomic: буде замінено під час злиття

        NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. * допускаються, але лише як повний, кінцевий крок у шляху. "*" означає всі.

    • status.resourceRules ([]ResourceRule), обовʼязково

      Atomic: буде замінено під час злиття

      ResourceRules — це список дій, які субʼєкт має право виконувати щодо ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.

      ResourceRule — це список дій, які субʼєкт має право виконувати щодо ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.

      • status.resourceRules.verbs ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        Verb — це список дієслів API ресурсу Kubernetes, таких як: get, list, watch, create, update, delete, proxy. "*" означає всі.

      • status.resourceRules.apiGroups ([]string)

        Atomic: буде замінено під час злиття

        APIGroups — це назва API-групи, яка містить ресурси. Якщо зазначено кілька API-груп, будь-яка дія, запитана для одного з перелічених ресурсів у будь-якій API-групі, буде дозволена. "*" означає всі.

      • status.resourceRules.resourceNames ([]string)

        Atomic: буде замінено під час злиття

        ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все. "*" означає всі.

      • status.resourceRules.resources ([]string)

        Atomic: буде замінено під час злиття

        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

Параметри

Відповідь

200 (SelfSubjectRulesReview): OK

201 (SelfSubjectRulesReview): Created

202 (SelfSubjectRulesReview): Accepted

401: Unauthorized

5.5.4 - SubjectAccessReview

SubjectAccessReview перевіряє, чи може користувач або група виконати дію.

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SubjectAccessReview

SubjectAccessReview перевіряє, чи може користувач або група виконати дію.

SubjectAccessReviewSpec

SubjectAccessReviewSpec — це опис запиту на доступ. Має бути встановлено одне з ResourceAuthorizationAttributes або NonResourceAuthorizationAttributes

  • extra (map[string][]string)

    Extra відповідає методу user.Info.GetExtra() з автентифікатора. Оскільки це вхідні дані для авторизатора, це потребує відображення тут.

  • groups ([]string)

    Atomic: буде замінено під час злиття

    Groups — це групи, для яких ви проводите тестування.

  • nonResourceAttributes (NonResourceAttributes)

    NonResourceAttributes описує інформацію для запиту на доступ до не-ресурсів

    NonResourceAttributes включає атрибути авторизації, доступні для запитів на не-ресурси до інтерфейсу Authorizer

    • nonResourceAttributes.path (string)

      Path — це URL шлях запиту

    • nonResourceAttributes.verb (string)

      Verb — це стандартне HTTP дієслово

  • resourceAttributes (ResourceAttributes)

    ResourceAuthorizationAttributes описує інформацію для запиту на доступ до ресурсу

    ResourceAttributes включає атрибути авторизації, доступні для запитів на ресурси до інтерфейсу Authorizer

    • resourceAttributes.fieldSelector (FieldSelectorAttributes)

      fieldSelector описує обмеження доступу на основі поля. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, потрібно ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      FieldSelectorAttributes вказує на доступ, обмежений за полем. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.fieldSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, яка буде включена в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.fieldSelector.requirements ([]FieldSelectorRequirement)

        Atomic: буде замінено під час злиття

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

        FieldSelectorRequirement — це селектор, який містить значення, ключ та оператор, який повʼязує ключ та значення.

        • resourceAttributes.fieldSelector.requirements.key (string), обовʼязково

          key — це ключ селектора поля, до якого застосовується вимога.

        • resourceAttributes.fieldSelector.requirements.operator (string), обовʼязково

          operator представляє звʼязок ключа до набору значень. Дійсні оператори: In, NotIn, Exists та DoesNotExist. Список операторів може розширюватися в майбутньому.

        • resourceAttributes.fieldSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це набір значень, які відповідають ключу. Якщо оператор In або NotIn, це масив значень, які відповідають ключу. Якщо оператор Exists або DoesNotExist, це порожній масив.

    • resourceAttributes.group (string)

      Group — це API група ресурсу. "*" означає всі.

    • resourceAttributes.labelSelector (LabelSelectorAttributes)

      labelSelector описує обмеження доступу на основі міток. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, потрібно ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      LabelSelectorAttributes вказує на доступ, обмежений за мітками. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.labelSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, яка буде включена в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.labelSelector.requirements ([]LabelSelectorRequirement)

        Atomic: буде замінено під час злиття

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

        Вимога до селектора мітки — це селектор, який містить значення, ключ і оператор, який повʼязує ключ і значення.

        • resourceAttributes.labelSelector.requirements.key (string), обовʼязково

          key — це ключ мітки, до якого застосовується селектор.

        • resourceAttributes.labelSelector.requirements.operator (string), обовʼязково

          operator представляє стосунок ключа до набору значень. Дійсні оператори: In, NotIn, Exists та DoesNotExist.

        • resourceAttributes.labelSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це масив строкових значень. Якщо оператор — In або NotIn, масив values не може бути порожнім. Якщо ж оператор — Exists або DoesNotExist, масив values повинен бути порожнім. Цей масив замінюється під час стратегічного злиття патчу.

    • 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

Параметри

Відповідь

200 (SubjectAccessReview): OK

201 (SubjectAccessReview): Created

202 (SubjectAccessReview): Accepted

401: Unauthorized

5.5.5 - ClusterRole

ClusterRole — це логічне групування PolicyRules на рівні кластера, на яке можна посилатися як на єдине ціле за допомогою привʼязки RoleBinding або ClusterRoleBinding.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRole

ClusterRole — це логічне групування PolicyRules на рівні кластера, на яке можна посилатися як на єдине ціле за допомогою привʼязки RoleBinding або ClusterRoleBinding.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRole

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • aggregationRule (AggregationRule)

    AggregationRule — це необовʼязкове поле, яке описує, як створити правила для цього ClusterRole. Якщо AggregationRule встановлено, то правила управляються контролером і прямі зміни до правил будуть перезаписані контролером.

    AggregationRule описує, як знайти ClusterRoles для обʼєднання у ClusterRole

    • aggregationRule.clusterRoleSelectors ([]LabelSelector)

      Atomic: буде замінено під час злиття

      ClusterRoleSelectors містить список селекторів, які будуть використані для пошуку ClusterRoles та створення правил. Якщо будь-який з селекторів збігається, тоді дозволи ClusterRole будуть додані.

  • rules ([]PolicyRule)

    Atomic: буде замінено під час злиття

    Rules містить всі PolicyRules для цього ClusterRole.

    PolicyRule містить інформацію, яка описує правило політики, але не містить інформації про те, до кого застосовується правило або до якого простору імен воно відноситься.

    • rules.apiGroups ([]string)

      Atomic: буде замінено під час злиття

      APIGroups — це назва APIGroup, яка містить ресурси. Якщо вказано декілька API груп, будь-яка дія, запитана для одного з перерахованих ресурсів у будь-якій API групі, буде дозволена. "" представляє основну API групу, а "*" представляє всі API групи.

    • rules.resources ([]string)

      Atomic: буде замінено під час злиття

      Resources — це список ресурсів, до яких застосовується це правило. '*' представляє всі ресурси.

    • rules.verbs ([]string), обовʼязкове

      Atomic: буде замінено під час злиття

      Verbs — це список дієслів, які застосовуються до ВСІХ ResourceKinds, що містяться у цьому правилі. '*' представляє всі дієслова.

    • rules.resourceNames ([]string)

      Atomic: буде замінено під час злиття

      ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

    • rules.nonResourceURLs ([]string)

      Atomic: буде замінено під час злиття

      NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. '*' дозволені, але тільки як повний, кінцевий крок у шляху. Оскільки не ресурсні URL-адреси не належать до простору імен, це поле застосовується тільки для ClusterRoles, на які посилається ClusterRoleBinding. Правила можуть застосовуватися або до API ресурсів (таких як "pods" або "secrets"), або до не ресурсних URL-шляхів (таких як "/api"), але не до обох одночасно.

ClusterRoleList

ClusterRoleList — це колекція ClusterRoles.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRoleList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]ClusterRole), обовʼязково

    Items — це список ClusterRoles.

Операції

get отримати вказану ClusterRole

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ClusterRole

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRole): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ClusterRole

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterroles

Параметри

Відповідь

200 (ClusterRoleList): OK

401: Unauthorized

create створення ClusterRole

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/clusterroles

Параметри

Відповідь

200 (ClusterRole): OK

201 (ClusterRole): Created

202 (ClusterRole): Accepted

401: Unauthorized

update заміна вказаної ClusterRole

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ClusterRole

  • body: ClusterRole, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRole): OK

201 (ClusterRole): Created

401: Unauthorized

patch часткове оновлення вказаної ClusterRole

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ClusterRole

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRole): OK

201 (ClusterRole): Created

401: Unauthorized

delete видалення ClusterRole

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ClusterRole

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterroles

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.5.6 - ClusterRoleBinding

ClusterRoleBinding посилається на ClusterRole, але не містить її.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRoleBinding

ClusterRoleBinding посилається на ClusterRole, але не містить її. ClusterRoleBinding може посилатися на ClusterRole в глобальному просторі імен та додає інформацію про субʼєкти через Subject.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRoleBinding

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • roleRef (RoleRef), обовʼязкове

    RoleRef може посилатися лише на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.

    RoleRef містить інформацію, яка посилається на використану роль

    • roleRef.apiGroup (string), обовʼязкове

      APIGroup — це група для вказаного ресурсу

    • roleRef.kind (string), обовʼязкове

      Kind - тип вказаного ресурсу

    • roleRef.name (string), обовʼязкове

      Name - це імʼя вказаного ресурсу

  • subjects ([]Subject)

    Atomic: буде замінено під час злиття

    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.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRoleBindingList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]ClusterRoleBinding), обовʼязкове

    Items — це список ClusterRoleBindings.

Операції

get отримати вказаний ClusterRoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRoleBinding): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ClusterRoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

Параметри

Відповідь

200 (ClusterRoleBindingList): OK

401: Unauthorized

create створення ClusterRoleBinding

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

Параметри

Відповідь

200 (ClusterRoleBinding): OK

201 (ClusterRoleBinding): Created

202 (ClusterRoleBinding): Accepted

401: Unauthorized

update заміна вказаного ClusterRoleBinding

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • body: ClusterRoleBinding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRoleBinding): OK

201 (ClusterRoleBinding): Created

401: Unauthorized

patch часткове оновлення вказаного ClusterRoleBinding

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRoleBinding): OK

201 (ClusterRoleBinding): Created

401: Unauthorized

delete видалення ClusterRoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ClusterRoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.5.7 - Role

Роль — це логічне групування PolicyRules у просторі імен, на яке можна посилатися як на одиницю за допомогою RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

Role

Роль — це логічне групування PolicyRules у просторі імен, на яке можна посилатися як на одиницю за допомогою RoleBinding.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: Role

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • rules ([]PolicyRule)

    Atomic: буде замінено під час злиття

    Rules містить всі PolicyRules для цієї Ролі

    PolicyRule містить інформацію, що описує правило політики, але не містить інформації про те, до кого застосовується правило або до якого простору імен воно відноситься.

    • rules.apiGroups ([]string)

      Atomic: буде замінено під час злиття

      APIGroups — це назва APIGroup, яка містить ресурси. Якщо вказано декілька API груп, будь-яка дія, запитана для одного з перерахованих ресурсів у будь-якій API групі буде дозволена. "" представляє основну API групу, а "*" представляє всі API групи.

    • rules.resources ([]string)

      Atomic: буде замінено під час злиття

      Resources — це список ресурсів, до яких застосовується це правило. '*' представляє всі ресурси.

    • rules.verbs ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      Verbs — це список дієслів, які застосовуються до ВСІХ ResourceKinds, що містяться у цьому правилі. '*' представляє всі дієслова.

    • rules.resourceNames ([]string)

      Atomic: буде замінено під час злиття

      ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

    • rules.nonResourceURLs ([]string)

      Atomic: буде замінено під час злиття

      NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. '*' дозволені, але тільки як повний, кінцевий крок у шляху. Оскільки не ресурсні URL-адреси не належать до простору імен, це поле застосовується тільки для ClusterRoles, на які посилається ClusterRoleBinding. Правила можуть застосовуватися або до API ресурсів (таких як "pods" або "secrets"), або до не ресурсних URL-шляхів (таких як "/api"), але не до обох одночасно.

RoleList

RoleList — це колекція Ролей.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: RoleList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]Role), обовʼязково

    Items — це список Ролей.

Операції

get отримати вказану Role

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Role

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles

Параметри

Відповідь

200 (RoleList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Role

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/roles

Параметри

Відповідь

200 (RoleList): OK

401: Unauthorized

create створення Role

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Role, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

201 (Role): Created

202 (Role): Accepted

401: Unauthorized

update заміна вказаної Role

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Role, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

201 (Role): Created

401: Unauthorized

patch часткове оновлення вказаної Role

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

201 (Role): Created

401: Unauthorized

delete видалення Role

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection вилучення колекції Role

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.5.8 - RoleBinding

RoleBinding посилається на роль, але не містить її.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

RoleBinding

RoleBinding посилається на роль, але не містить її. RoleBinding може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. RoleBinding додає інформацію про субʼєкти через Subjects і інформацію про простір імен, в якому існує. RoleBindings у визначеному просторі імен мають вплив лише в цьому просторі імен.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: RoleBinding

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • roleRef (RoleRef), обовʼязкове

    RoleRef може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.

    RoleRef містить інформацію, яка посилається на використану роль

    • roleRef.apiGroup (string), обовʼязкове

      APIGroup — це група для вказаного ресурсу

    • roleRef.kind (string), обовʼязкове

      Kind — тип вказаного ресурсу

    • roleRef.name (string), обовʼязкове

      Name — це імʼя вказаного ресурсу

  • subjects ([]Subject)

    Atomic: буде замінено під час злиття

    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", і це значення не порожнє, Авторизатор повинен повідомити про помилку.

RoleBindingList

RoleBindingList — це колекція RoleBindings.

  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: RoleBindingList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]RoleBinding), обовʼязкове

    Items — це список RoleBindings.

Операції

get отримати вказаний RoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (RoleBinding): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу RoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings

Параметри

Відповідь

200 (RoleBindingList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу RoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/rolebindings

Параметри

Відповідь

200 (RoleBindingList): OK

401: Unauthorized

create створення RoleBinding

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings

Параметри

Відповідь

200 (RoleBinding): OK

201 (RoleBinding): Created

202 (RoleBinding): Accepted

401: Unauthorized

update заміна вказаного RoleBinding

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: RoleBinding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (RoleBinding): OK

201 (RoleBinding): Created

401: Unauthorized

patch часткове оновлення вказаного RoleBinding

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (RoleBinding): OK

201 (RoleBinding): Created

401: Unauthorized

delete видалення RoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції RoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6 - Ресурси політики

5.6.1 - FlowSchema

FlowSchema визначає схему групи потоків.

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

FlowSchema

FlowSchema визначає схему групи потоків. Зверніть увагу, що потік складається з набору вхідних API-запитів з подібними атрибутами та ідентифікується парою рядків: імʼям FlowSchema та "розрізнювачем потоку".

FlowSchemaSpec

FlowSchemaSpec описує вигляд специфікації FlowSchema.

  • distinguisherMethod (FlowDistinguisherMethod)

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

    FlowDistinguisherMethod вказує на метод розрізнювача потоку.

    • distinguisherMethod.type (string), обовʼязково

      type - це тип методу розрізнювача потоку. Підтримувані типи: "ByUser" та "ByNamespace". Обовʼязково.

  • matchingPrecedence (int32)

    matchingPrecedence використовується для вибору серед FlowSchema, які відповідають заданому запиту. Обрана FlowSchema є серед тих, що мають чисельно найменший (який ми вважаємо логічно найвищим) MatchingPrecedence. Кожне значення MatchingPrecedence повинно бути в діапазоні [1, 10000]. Зауважте, що якщо пріоритет не вказано, він буде стандартно встановлений на 1000.

  • priorityLevelConfiguration (PriorityLevelConfigurationReference), обовʼязково

    priorityLevelConfiguration повинна посилатися на PriorityLevelConfiguration в кластері. Якщо посилання не вдається вирішити, FlowSchema буде ігноруватися і позначатися як недійсна в її статусі. Обовʼязково.

    PriorityLevelConfigurationReference містить інформацію, яка посилається на використання "request-priority".

    • priorityLevelConfiguration.name (string), обовʼязково

      name — це імʼя конфігурації рівня пріоритетів, на яку є посилання. Обовʼязково.

  • rules ([]PolicyRulesWithSubjects)

    Atomic: буде замінено під час злиття

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

    PolicyRulesWithSubjects визначає тест, який застосовується до запиту до apiserver. Тест враховує субʼєкт, який робить запит, дієслово, яке запитується, і ресурс, яким має бути дія. Цей PolicyRulesWithSubjects відповідає запиту, якщо і тільки якщо обидва (а) принаймні один член subjects відповідає запиту і (б) принаймні один член resourceRules або nonResourceRules відповідає запиту.

    • rules.subjects ([]Subject), обовʼязково

      Atomic: буде замінено під час злиття

      subjects — це список звичайних користувачів, службових облікових записів або груп, яких це правило стосується. У цьому зрізі повинен бути принаймні один член. Зріз, який включає як системні групи "system:authenticated" і "system:unauthenticated", відповідає кожному запиту. Обовʼязково.

      Тема відповідає ініціатору запиту, визначеному системою автентифікації запиту. Існує три способи зіставлення автора; за обліковим записом користувача, групи або службового облікового запиту.

      • rules.subjects.kind (string), обовʼязково

        kind показує, яке з полів не пусте. Обовʼязково.

      • rules.subjects.group (GroupSubject)

        group відповідає на підставі назви групи користувачів.

        GroupSubject містить детальну інформацію для субʼєкта типу групи.

      • rules.subjects.serviceAccount (ServiceAccountSubject)

        serviceAccount відповідає службовим обліковим записам.

        ServiceAccountSubject містить детальну інформацію для субʼєкта типу службового облікового запису.

        • rules.subjects.serviceAccount.name (string), обовʼязково

          name — це імʼя облікових записів ServiceAccount, або "*" для відповідності незалежно від імені. Обовʼязково.

        • rules.subjects.serviceAccount.namespace (string), обовʼязково

          namespace — це простір імен відповідних обʼєктів ServiceAccount. Обовʼязково.

      • rules.subjects.user (UserSubject)

        user збіг на основі імені користувача.

        UserSubject містить детальну інформацію для субʼєкта типу користувача.

        • rules.subjects.user.name (string), обовʼязково

          name — це імʼя користувача, яке має збіг, або "*" для відповідності всім іменам користувачів. Обовʼязково.

    • rules.nonResourceRules ([]NonResourcePolicyRule)

      Atomic: буде замінено під час злиття

      nonResourceRules — це список NonResourcePolicyRules, які ідентифікують відповідні запити відповідно до їх дієслова і цільового URL без ресурсів.

      NonResourcePolicyRule є предикатом, який відповідає запитам без ресурсів відповідно до їх дієслова і цільового URL без ресурсів. NonResourcePolicyRule відповідає запиту, якщо і тільки якщо обидва (а) принаймні один член verbs відповідає запиту і (б) принаймні один член nonResourceURLs відповідає запиту.

      • rules.nonResourceRules.nonResourceURLs ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        nonResourceURLs — це набір префіксів URL, до яких користувач має мати доступ і не може бути порожнім. Наприклад:

        • "/healthz" є допустимим
        • "/hea*" є недійсним
        • "/hea" є допустимим, але не відповідає нічому
        • "/hea/*" також не відповідає нічому
        • "/healthz/*" відповідає всім перевіркам стану компонентів. "*" відповідає всім URL без ресурсів. Якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

      • rules.nonResourceRules.verbs ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        verbs — це список відповідних дієслів і не може бути порожнім. "*" відповідає всім дієсловам. Якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

    • rules.resourceRules ([]ResourcePolicyRule)

      Atomic: буде замінено під час злиття

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

      ResourcePolicyRule є предикатом, який відповідає деяким запитам ресурсів, перевіряючи дієслово запиту і цільовий ресурс. ResourcePolicyRule відповідає запиту ресурсу, якщо і тільки якщо: (а) принаймні один член verbs відповідає запиту, (б) принаймні один член apiGroups відповідає запиту, (в) принаймні один член resources відповідає запиту, і (г) або (d1) запит не вказує простір імен (тобто Namespace=="") і clusterScope є true або (d2) запит вказує простір імен, і принаймні один член namespaces відповідає простору імен запиту.

      • rules.resourceRules.apiGroups ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        apiGroups — це список відповідних API-груп і не може бути порожнім. "*" відповідає всім API-групам і, якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

      • rules.resourceRules.resources ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        resources — це список відповідних ресурсів (тобто в нижньому регістрі та множині) і, за бажанням, субресурс. Наприклад, ["services", "nodes/status"]. Цей список не може бути порожнім. "*" відповідає всім ресурсам і, якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

      • rules.resourceRules.verbs ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        verbs — це список відповідних дієслів і не може бути порожнім. "*" відповідає всім дієсловам і, якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

      • rules.resourceRules.clusterScope (boolean)

        clusterScope показує, чи потрібно відповідати запитам, які не вказують простір імен (це стається або тому, що ресурс не має простору імен, або запит цілісно охоплює всі простори імен). Якщо це поле відсутнє або false, то поле namespaces повинне містити не порожній список.

      • rules.resourceRules.namespaces ([]string)

        Set: унікальні значення будуть збережені під час злиття

        namespaces — це список цільових просторів імен, які обмежують збіги. Запит, який вказує на простір імен, має збіг тільки у випадку, якщо або (a) цей список містить цільовий простір імен або (b) цей список містить "*". Зверніть увагу, що "*" відповідає будь-якому вказаному простору імен, але не відповідає запиту, який не вказує простір імен (див. поле clusterScope для цього). Цей список може бути порожнім, але лише в тому випадку, якщо clusterScope є true.

FlowSchemaStatus

FlowSchemaStatus відображає поточний стан FlowSchema.

  • conditions ([]FlowSchemaCondition)

    Patch стратегія: злиття за ключем type

    Map: унікальні значення за ключем type будуть збережені під час злиття

    conditions — це список поточних станів FlowSchema.

    FlowSchemaCondition описує умови для FlowSchema.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — час останнього переходу стану з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message — повідомлення зрозуміле людині, що вказує деталі про останній перехід.

    • conditions.reason (string)

      reason — унікальна причина у вигляді одного слова у CamelCase для останньої зміни стану.

    • conditions.status (string)

      status — статус стану. Може бути True, False, Unknown. Обовʼязково.

    • conditions.type (string)

      type — тип стану. Обовʼязково.

FlowSchemaList

FlowSchemaList - це список обʼєктів FlowSchema.

Операції

get отримату вказану FlowSchema

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

401: Unauthorized

get отримати статус вказаної FlowSchema

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

401: Unauthorized

list перелвк або перегляд обʼєктів типу FlowSchema

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas

Параметри

Відповідь

200 (FlowSchemaList): OK

401: Unauthorized

create створення FlowSchema

HTTP запит

POST /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas

Параметри

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

202 (FlowSchema): Accepted

401: Unauthorized

update заміна вказаної FlowSchema

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: FlowSchema, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

updateзаміна статусу вказаної FlowSchema

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: FlowSchema, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

patch часткове оновлення вказаної FlowSchema

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

patch часткове оновлення статусу вказаної FlowSchema

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

delete видалення FlowSchema

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції FlowSchema

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6.2 - LimitRange

LimitRange встановлює обмеження на використання ресурсів для кожного типу ресурсу у просторі імен.

apiVersion: v1

import "k8s.io/api/core/v1"

LimitRange

LimitRange встановлює обмеження на використання ресурсів для кожного типу ресурсу в просторі імен.

LimitRangeSpec

LimitRangeSpec визначає мінімальні та максимальні обмеження на використання ресурсів, які відповідають певному типу.

  • limits ([]LimitRangeItem), обовʼязково

    Atomic: буде замінено під час злиття

    Limits — це список обʼєктів LimitRangeItem, що застосовуються.

    LimitRangeItem визначає мінімальні та максимальні обмеження на використання будь-якого ресурсу, який відповідає певному типу.

    • limits.type (string), обовʼязково

      Тип ресурсу, до якого застосовується це обмеження.

    • limits.default (map[string]Quantity)

      Стандартні граничні значення запиту ресурсу за назвою ресурсу, якщо обмеження ресурсів не вказано.

    • limits.defaultRequest (map[string]Quantity)

      DefaultRequest — це стандартне значення запиту на вимоги до ресурсу за назвою ресурсу, якщо запит на ресурси не вказано.

    • limits.max (map[string]Quantity)

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

    • limits.maxLimitRequestRatio (map[string]Quantity)

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

    • limits.min (map[string]Quantity)

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

LimitRangeList

LimitRangeList — це список елементів LimitRange.

Операції

get отримати вказаний LimitRange

HTTP запит

GET /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (LimitRange): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LimitRange

HTTP запит

GET /api/v1/namespaces/{namespace}/limitranges

Параметри

Відповідь

200 (LimitRangeList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LimitRange

HTTP запит

GET /api/v1/limitranges

Параметри

Відповідь

200 (LimitRangeList): OK

401: Unauthorized

create створення LimitRange

HTTP запит

POST /api/v1/namespaces/{namespace}/limitranges

Параметри

Відповідь

200 (LimitRange): OK

201 (LimitRange): Created

202 (LimitRange): Accepted

401: Unauthorized

update заміна вказаного LimitRange

HTTP запит

PUT /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: LimitRange, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (LimitRange): OK

201 (LimitRange): Created

401: Unauthorized

patch часткове оновлення вказаного LimitRange

HTTP запит

PATCH /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (LimitRange): OK

201 (LimitRange): Created

401: Unauthorized

delete видалення LimitRange

HTTP запит

DELETE /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції LimitRange

HTTP запит

DELETE /api/v1/namespaces/{namespace}/limitranges

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6.3 - ResourceQuota

ResourceQuota встановлює сукупні обмеження квоти, що застосовуються до простору імен.

apiVersion: v1

import "k8s.io/api/core/v1"

ResourceQuota

ResourceQuota встановлює сукупні квоти, які застосовуються для кожного простору імен.

ResourceQuotaSpec

ResourceQuotaSpec визначає бажані жорсткі обмеження для застосування квоти.

  • hard (map[string]Quantity)

    hard — це набір бажаних жорстких обмежень для кожного названого ресурсу. Докладніше: https://kubernetes.io/docs/concepts/policy/resource-quotas/

  • scopeSelector (ScopeSelector)

    scopeSelector — це також набір фільтрів, таких як scopes, які повинні відповідати кожному обʼєкту, відстежуваному квотою, але виражені за допомогою ScopeSelectorOperator у поєднанні з можливими значеннями. Для відповідності ресурсу повинні відповідати як scopes, так і scopeSelector (якщо зазначено у spec).

    Селектор області застосування являє собою AND селекторів, представлених вимогами селектора ресурсу з обмеженою областю застосування.

    • scopeSelector.matchExpressions ([]ScopedResourceSelectorRequirement)

      Atomic: буде замінено під час злиття

      Список вимог селектора за областю застосування ресурсів.

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

      • scopeSelector.matchExpressions.operator (string), обовʼязково

        Представляє стосунок області застосування з до набору значень. Допустимі оператори In, NotIn, Exists, DoesNotExists.

      • scopeSelector.matchExpressions.scopeName (string), обовʼязково

        Імʼя області застосування, до якої застосовується селектор.

      • scopeSelector.matchExpressions.values ([]string)

        Atomic: буде замінено під час злиття

        Масив рядкових значень. Якщо оператор In або NotIn, масив значень не повинен бути порожнім. Якщо оператор Exists або DoesNotExist, масив значень повинен бути порожнім. Цей масив замінюється під час стратегії обʼєднання патчів.

  • scopes ([]string)

    Atomic: буде замінено під час злиття

    Набір фільтрів, які повинні відповідати кожному обʼєкту, відстежуваному квотою. Якщо не вказано, квота відповідає всім обʼєктам.

ResourceQuotaStatus

ResourceQuotaStatus визначає застосовані жорсткі обмеження та спостережуване використання.

  • hard (map[string]Quantity)

    Hard — це набір застосованих жорстких обмежень для кожного названого ресурсу. Докладніше: https://kubernetes.io/docs/concepts/policy/resource-quotas/

  • used (map[string]Quantity)

    Used — це поточне спостережуване загальне використання ресурсу в просторі імен.

ResourceQuotaList

ResourceQuotaList — це список елементів ResourceQuota.

Операції

get отримати вказану ResourceQuota

HTTP запит

GET /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

401: Unauthorized

get отримати статус вказаної ResourceQuota

HTTP запит

GET /api/v1/namespaces/{namespace}/resourcequotas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceQuota

HTTP запит

GET /api/v1/namespaces/{namespace}/resourcequotas

Параметри

Відповідь

200 (ResourceQuotaList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceQuota

HTTP запит

GET /api/v1/resourcequotas

Параметри

Відповідь

200 (ResourceQuotaList): OK

401: Unauthorized

create створення ResourceQuota

HTTP запит

POST /api/v1/namespaces/{namespace}/resourcequotas

Параметри

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

202 (ResourceQuota): Accepted

401: Unauthorized

update заміна вказаної ResourceQuota

HTTP запит

PUT /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceQuota, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

update заміна статусу вказаної ResourceQuota

HTTP запит

PUT /api/v1/namespaces/{namespace}/resourcequotas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceQuota, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

patch часткове оновлення вказаної ResourceQuota

HTTP запит

PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

patch часткове оновлення статусу вказаної ResourceQuota

HTTP запит

PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

delete видалення ResourceQuota

HTTP запит

DELETE /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ResourceQuota): OK

202 (ResourceQuota): Accepted

401: Unauthorized

deletecollection видалення колекції ResourceQuota

HTTP запит

DELETE /api/v1/namespaces/{namespace}/resourcequotas

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6.4 - NetworkPolicy

NetworkPolicy описує, який мережевий трафік дозволено для набору Podʼів.

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

NetworkPolicy

NetworkPolicy описує, який мережевий трафік дозволений для набору Podʼів

NetworkPolicySpec

NetworkPolicySpec надає специфікацію NetworkPolicy

  • podSelector (LabelSelector), обовʼязково

    podSelector вибирає Podʼи, до яких застосовується цей обʼєкт NetworkPolicy. Масив правил ingress застосовується до будь-яких Podʼів, вибраних цим полем. Кілька мережевих політик можуть вибирати той самий набір Podʼів. У цьому випадку правила ingress для кожного з них поєднуються. Це поле НЕ є необовʼязковим і слідує стандартним семантикам вибору міток. Порожній podSelector збігається з усіма Podʼами в цьому простору імен.

  • policyTypes ([]string)

    Atomic: буде замінено під час злиття

    policyTypes — це список типів правил, до яких відноситься NetworkPolicy. Дійсні опції включають [“Ingress"], [“Egress"] або [“Ingress", “Egress"]. Якщо це поле не вказано, воно буде визначено стандартно на основі наявності правил ingress або egress; політики, які містять розділ egress, вважаються такими, що впливають на egress, а всі політики (незалежно від того, чи містять вони розділ ingress) вважаються такими, що впливають на ingress. Якщо ви хочете написати політику тільки для egress, ви повинні явно вказати policyTypes [“Egress"]. Аналогічно, якщо ви хочете написати політику, яка визначає, що egress не дозволений, ви повинні вказати значення policyTypes, яке включає “Egress" (оскільки така політика не включатиме розділ egress і стандартно буде просто [“Ingress" ]). Це поле є рівнем бета у версії 1.8.

  • ingress ([]NetworkPolicyIngressRule)

    Atomic: буде замінено під час злиття

    ingress  — це список правил ingress, які застосовуються до вибраних Podʼів. Трафік дозволено до Podʼа, якщо немає мережевих політик, які вибирають Pod (і кластерна політика інакше дозволяє трафік), АБО якщо джерелом трафіку є локальний вузол Podʼа, АБО якщо трафік відповідає принаймні одному правилу ingress серед усіх обʼєктів NetworkPolicy, чий podSelector відповідає Podʼу. Якщо це поле порожнє, ця NetworkPolicy не дозволяє жодного трафіку (і стандартно слугує виключно для того, щоб забезпечити ізоляцію вибраних Podʼів).

    NetworkPolicyIngressRule описує конкретний набір трафіку, який дозволено до Podʼів, вибраних podSelector у NetworkPolicySpec. Трафік повинен відповідати як ports, так і from.

    • ingress.from ([]NetworkPolicyPeer)

      Atomic: буде замінено під час злиття

      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)

          Atomic: буде замінено під час злиття

          except — це перелік CIDR, які не повинні бути включені до IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64". Значення except будуть відхилені, якщо вони виходять за межі діапазону cidr.

      • ingress.from.namespaceSelector (LabelSelector)

        namespaceSelector вибирає простори імен за допомогою кластерних міток. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі простори імен.

        Якщо також встановлено podSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних namespaceSelector. Інакше він вибирає всі Podʼи в просторах імен, вибраних namespaceSelector.

      • ingress.from.podSelector (LabelSelector)

        podSelector — це вибір міток, що вибирає Podʼи. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі Podʼи.

        Якщо також встановлено namespaceSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних NamespaceSelector. Інакше він вибирає Podʼи, які відповідають podSelector у власному просторі імен політики.

    • ingress.ports ([]NetworkPolicyPort)

      Atomic: буде замінено під час злиття

      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)

    Atomic: буде замінено під час злиття

    egress — це список правил egress, які застосовуються до вибраних Podʼів. Вихідний трафік дозволений, якщо немає мережевих політик, які вибирають Pod (і кластерна політика інакше дозволяє трафік), АБО якщо трафік відповідає принаймні одному правилу egress серед усіх обʼєктів NetworkPolicy, чий podSelector відповідає Podʼу. Якщо це поле порожнє, ця NetworkPolicy обмежує весь вихідний трафік (і слугує виключно для того, щоб стандартно забезпечити ізоляцію вибраних Podʼів). Це поле є рівнем бета у версії 1.8.

    NetworkPolicyEgressRule описує конкретний набір трафіку, який дозволено від Podʼів, вибраних podSelector у NetworkPolicySpec. Трафік повинен відповідати як ports, так і to. Цей тип є рівнем бета у версії 1.8.

    • egress.to ([]NetworkPolicyPeer)

      Atomic: буде замінено під час злиття

      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)

          Atomic: буде замінено під час злиття

          except — це перелік CIDR, які не повинні бути включені до IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64". Значення except будуть відхилені, якщо вони виходять за межі діапазону cidr.

      • egress.to.namespaceSelector (LabelSelector)

        namespaceSelector вибирає простори імен за допомогою кластерних міток. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі простори імен.

        Якщо також встановлено podSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних namespaceSelector. Інакше він вибирає всі Podʼи в просторах імен, вибраних namespaceSelector.

      • egress.to.podSelector (LabelSelector)

        podSelector — це вибір міток, що вибирає Podʼи. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі Podʼи.

        Якщо також встановлено namespaceSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних NamespaceSelector. Інакше він вибирає Podʼи, які відповідають podSelector у власному просторі імен політики.

    • egress.ports ([]NetworkPolicyPort)

      Atomic: буде замінено під час злиття

      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.

Операції

get отримату ввказану NetworkPolicy

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (NetworkPolicy): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу NetworkPolicy

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies

Параметри

Відповідь

200 (NetworkPolicyList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу

HTTP запит

GET /apis/networking.k8s.io/v1/networkpolicies

Параметри

Відповідь

200 (NetworkPolicyList): OK

401: Unauthorized

create створення NetworkPolicy

HTTP запит

POST /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies

Параметри

Відповідь

200 (NetworkPolicy): OK

201 (NetworkPolicy): Created

202 (NetworkPolicy): Accepted

401: Unauthorized

update заміна вказаної NetworkPolicy

HTTP запит

PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: NetworkPolicy, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (NetworkPolicy): OK

201 (NetworkPolicy): Created

401: Unauthorized

patch часткове оновлення вказаної NetworkPolicy

HTTP запит

PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (NetworkPolicy): OK

201 (NetworkPolicy): Created

401: Unauthorized

delete видалення NetworkPolicy

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції NetworkPolicy

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6.5 - PodDisruptionBudget

PodDisruptionBudget — обʼєкт, який визначає максимальний розлад, який може бути завданий колекції Podʼів.

apiVersion: policy/v1

import "k8s.io/api/policy/v1"

PodDisruptionBudget

PodDisruptionBudget — обʼєкт, який визначає максимальний розлад, який може бути завданий колекції Podʼів.

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, яке може приймати імʼя або число.

  • selector (LabelSelector)

    Запит міток для 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.

PodDisruptionBudgetList

PodDisruptionBudgetList —це колекція PodDisruptionBudgets.

Операції

get отримати вказаний PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

401: Unauthorized

get отримати статус вказаного PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets

Параметри

Відповідь

200 (PodDisruptionBudgetList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/poddisruptionbudgets

Параметри

Відповідь

200 (PodDisruptionBudgetList): OK

401: Unauthorized

create ствоерння PodDisruptionBudget

HTTP запит

POST /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets

Параметри

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

202 (PodDisruptionBudget): Accepted

401: Unauthorized

update заміна вказаного PodDisruptionBudget

HTTP запит

PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodDisruptionBudget, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

update заміна статусу вказанрого PodDisruptionBudget

HTTP запит

PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodDisruptionBudget, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

patch часткове оновлення вказаного PodDisruptionBudget

HTTP запит

PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

patch часткове оновлення статусу вказаного PodDisruptionBudget

HTTP запит

PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

delete видалення PodDisruptionBudget

HTTP запит

DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції PodDisruptionBudget

HTTP запит

DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6.6 - PriorityLevelConfiguration

PriorityLevelConfiguration представляє конфігурацію рівня пріоритету.

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

PriorityLevelConfiguration

PriorityLevelConfiguration представляє конфігурацію рівня пріоритету.

PriorityLevelConfigurationSpec

PriorityLevelConfigurationSpec визначає конфігурацію рівня пріоритету.

  • exempt (ExemptPriorityLevelConfiguration)

    exempt вказує, як обробляються запити для виняткового рівня пріоритету. Це поле ПОВИННО бути порожнім, якщо type встановлено на "Limited". Це поле МОЖЕ бути не порожнім, якщо type встановлено на "Exempt". Якщо воно порожнє і type встановлено на "Exempt", застосовуються стандартне значення для ExemptPriorityLevelConfiguration.

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

    • exempt.lendablePercent (int32)

      lendablePercent вказує частку NominalCL рівня, яка може бути позичена іншими рівнями пріоритету. Значення цього поля повинно бути в діапазоні від 0 до 100 включно, стандартне значення — 0. Кількість місць, які інші рівні можуть позичати у цього рівня, визначається наступним чином:

      LendableCL(i) = round( NominalCL(i) * lendablePercent(i)/100.0 )

    • exempt.nominalConcurrencyShares (int32)

      nominalConcurrencyShares (NCS) вносить свій внесок до обчислення NominalConcurrencyLimit (NominalCL) цього рівня. Це кількість виконавчих місць, які номінально зарезервовані для цього рівня пріоритету. Це НЕ обмежує розподіл з цього рівня, але впливає на інші рівні пріоритету через механізм позичання. Ліміт конкурентності сервера (ServerCL) розподіляється серед всіх рівнів пріоритету пропорційно їх значенням NCS:

      NominalCL(i) = ceil( ServerCL * NCS(i) / sum_ncs ) sum_ncs = sum[priority level k] NCS(k)

      Більші значення означають більший номінальний ліміт конкурентності за рахунок інших рівнів пріоритету. Стандартно це поле має значення 0.

  • limited (LimitedPriorityLevelConfiguration)

    limited вказує, як обробляються запити для обмеженого рівня пріоритету. Це поле повинно бути не порожнім лише тоді, коли type встановлено на "Limited".

    LimitedPriorityLevelConfiguration вказує, як обробляти запити, які підлягають обмеженням. Він вирішує дві проблеми:

    • Які обмеження на запити для цього рівня пріоритету?

    • Що робити з запитами, які перевищують ліміт?

    • limited.borrowingLimitPercent (int32)

      borrowingLimitPercent, якщо вказано, налаштовує ліміт на кількість місць, які цей рівень пріоритету може позичати від інших рівнів пріоритету. Ліміт відомий як BorrowingConcurrencyLimit (BorrowingCL) і є обмеженням на загальну кількість місць, які цей рівень може позичати одночасно. Це поле визначає співвідношення цього ліміту до номінального ліміту конкурентності рівня. Коли це поле не є нульовим, воно має вказувати невідʼємне ціле число, і ліміт обчислюється так:

      BorrowingCL(i) = round( NominalCL(i) * borrowingLimitPercent(i)/100.0 )

      Значення цього поля може перевищувати 100, що означає, що цей рівень пріоритету може позичати більше місць, ніж його власний номінальний ліміт конкурентності (NominalCL). Якщо це поле залишити nil, ліміт фактично нескінченний.

    • limited.lendablePercent (int32)

      lendablePercent вказує частку NominalCL рівня, яка може бути позичена іншими рівнями пріоритету. Значення цього поля повинно бути в діапазоні від 0 до 100 включно, стандартно — 0. Кількість місць, які інші рівні можуть позичати у цього рівня, визначається наступним чином:

      LendableCL(i) = round( NominalCL(i) * lendablePercent(i)/100.0 )

    • limited.limitResponse (LimitResponse)

      limitResponse вказує, як поводитися з запитами, які зараз не можна виконати.

      LimitResponse визначає, як обробляти запити, які зараз не можна виконати.

      • limited.limitResponse.type (string), обовʼязково

        type — "Queue" або "Reject". "Queue" означає, що запити, які зараз не можна виконати, утримуються в черзі, поки їх не буде можливо виконати або досягнуто обмеження черги. "Reject" означає, що запити, які зараз не можна виконати, відхиляються. Обовʼязковщ.

      • limited.limitResponse.queuing (QueuingConfiguration)

        queuing містить параметри конфігурації для черги. Це поле може бути не порожнім лише тоді, коли type встановлено на "Queue".

        QueuingConfiguration містить параметри конфігурації для черги

        • limited.limitResponse.queuing.handSize (int32)

          handSize — невелике позитивне число, яке налаштовує розподіл замовлень до черг. При включенні запита на цьому рівні пріоритету ідентифікатор потоку запиту (пара рядків) хешується, і значення хеша використовується для перетасовки списку черг і роздачі руки розміру, вказаного тут. Запит поміщається в одну з найкоротших черг в цій руці. handSize не повинно бути більшим, ніж queues, і повинно бути значно меншим (щоб кілька важких потоків не насичували більшість черг). Див. документацію для користувачів для більш детальної інформації щодо налаштування цього поля. Стандартне значення — 8.

        • limited.limitResponse.queuing.queueLengthLimit (int32)

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

        • limited.limitResponse.queuing.queues (int32)

          queues — кількість черг для цього рівня пріоритету. Черги існують незалежно в кожному apiserver. Значення повинно бути позитивним. Встановлення його на 1 фактично виключає shufflesharding і, таким чином, робить метод відмінності асоційованих схем потоків неактуальним. Стандартно поле має значення 64.

    • limited.nominalConcurrencyShares (int32)

      nominalConcurrencyShares (NCS) вносить свій внесок до обчислення NominalConcurrencyLimit (NominalCL) цього рівня. Це кількість виконавчих місць, доступних на цьому рівні пріоритету. Це використовується як для запитів, розподілених з цього рівня пріоритету, так і для запитів, розподілених з інших рівнів пріоритету, які позичають місця з цього рівня. Ліміт конкурентності сервера (ServerCL) розподіляється серед обмежених рівнів пріоритету в пропорції до їх значень NCS:

      NominalCL(i) = ceil( ServerCL * NCS(i) / sum_ncs ) sum_ncs = sum[priority level k] NCS(k)

      Більші значення означають більший номінальний ліміт конкурентності, за рахунок інших рівнів пріоритету.

      Якщо не вказано, стандартно це поле має значення 30.

      Встановлення цього поля в нуль підтримує створення «вʼязниці» для цього рівня пріоритету, яка використовується для утримання деяких запитів

  • type (string), required

    type вказує, чи підлягає цей рівень пріоритету обмеженням на виконання запитів. Значення "Exempt" означає, що запити цього рівня пріоритету не підлягають обмеженням (і, отже, ніколи не ставляться в чергу) і не впливають на потужність, доступну для інших рівнів пріоритету. Значення "Limited" означає, що (a) запити цього рівня пріоритету підлягають обмеженням і (b) частина обмеженої потужності сервера доступна виключно для цього рівня пріоритету. Обовʼязкове.

PriorityLevelConfigurationStatus

PriorityLevelConfigurationStatus представляє поточний стан "пріоритету запитів".

  • conditions ([]PriorityLevelConfigurationCondition)

    Patch strategy: обʼєднання за ключем type

    Map: унікальні значення за ключем типу зберігатимуться під час обʼєднання

    conditions - поточний стан "пріоритету запитів".

    PriorityLevelConfigurationCondition визначає стан рівня пріоритету.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — останній час, коли стан змінився з одного статусу на інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message — це повідомлення, зрозуміле людині та вказує на деталі останнього переходу.

    • conditions.reason (string)

      reason — унікальна причина, одне слово, у CamelCase причина останнього переходу стану.

    • conditions.status (string)

      status — це стан статусу. Може бути True, False, Unknown. Обовʼязково.

    • conditions.type (string)

      type - це тип умови. Обовʼязково.

PriorityLevelConfigurationList

PriorityLevelConfigurationList — це список обʼєктів PriorityLevelConfiguration.

Операції

get отримати вказану PriorityLevelConfiguration

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

401: Unauthorized

get отримати статус вказаної PriorityLevelConfiguration

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PriorityLevelConfiguration

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations

Параметри

Відповідь

200 (PriorityLevelConfigurationList): OK

401: Unauthorized

create створення PriorityLevelConfiguration

HTTP запит

POST /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations

Параметри

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

202 (PriorityLevelConfiguration): Accepted

401: Unauthorized

update заміна вказаної PriorityLevelConfiguration

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: PriorityLevelConfiguration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

update заміна статусу вказаної PriorityLevelConfiguration

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: PriorityLevelConfiguration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

patch часткове оновлення вказаної PriorityLevelConfiguration

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

patch часткове оновлення статусу вказаної PriorityLevelConfiguration

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

delete видалення PriorityLevelConfiguration

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection вилучення колекції PriorityLevelConfiguration

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6.7 - ValidatingAdmissionPolicy

ValidatingAdmissionPolicy описує визначення політики перевірки допуску, яка приймає або відхиляє обʼєкт, не змінюючи його.

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingAdmissionPolicy

ValidatingAdmissionPolicy описує визначення політики перевірки допуску, яка приймає або відхиляє обʼєкт, не змінюючи його.

  • apiVersion: admissionregistration.k8s.io/v1

  • kind: ValidatingAdmissionPolicy

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicySpec)

    Специфікація бажаної поведінки ValidatingAdmissionPolicy.

    ValidatingAdmissionPolicySpec — це специфікація бажаної поведінки AdmissionPolicy.

    • spec.auditAnnotations ([]AuditAnnotation)

      Atomic: буде замінено під час обʼєднання

      auditAnnotations містить вирази CEL, які використовуються для створення анотацій аудити для події аудити запиту API. validations і auditAnnotations не можуть бути одночасно порожніми; потрібна щонайменше одна з validations або auditAnnotations.

      AuditAnnotation описує, як створити анотацію аудиту для запиту API.

      • spec.auditAnnotations.key (string), обовʼязково

        key визначає ключ анотації аудиту. Ключі анотацій аудиту ValidatingAdmissionPolicy мають бути унікальними. Ключ повинен бути кваліфікованим імʼям ([A-Za-z0-9][-A-Za-z0-9_.]*) довжиною не більше 63 байт.

        Ключ поєднується з імʼям ресурсу ValidatingAdmissionPolicy для створення ключа анотації аудиту: "{ValidatingAdmissionPolicy name}/{key}".

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

        Обовʼязково.

      • spec.auditAnnotations.valueExpression (string), обовʼязково

        valueExpression представляє вираз, який оцінюється CEL для створення значення анотації аудиту. Вираз має оцінюватися або як рядок, або як значення null. Якщо вираз оцінюється як рядок, анотація аудиту включається зі значенням рядка. Якщо вираз оцінюється як null або порожній рядок, анотація аудиту буде пропущена. valueExpression може бути не довше 5 КБ. Якщо результат valueExpression перевищує 10 КБ, він буде скорочений до 10 КБ.

        Якщо кілька ресурсів ValidatingAdmissionPolicyBinding відповідають запиту API, то valueExpression буде оцінено для кожного звʼязування. Усі унікальні значення, створені valueExpressions, будуть обʼєднані в список, розділений комами.

        Обовʼязково.

    • spec.failurePolicy (string)

      failurePolicy визначає, як обробляти невдачі для admission policy. Невдачі можуть виникати через помилки розбору виразів CEL, помилки перевірки типів, помилки виконання та невірні або неправильно налаштовані визначення політики або звʼязувань.

      Політика вважається недійсною, якщо spec.paramKind посилається на відсутній Kind. Звʼязок вважається недійсним, якщо spec.paramRef.name посилається на нвідсутній ресурс.

      failurePolicy не визначає, як обробляються перевірки, які оцінюються як false.

      Коли failurePolicy встановлено на Fail, ValidatingAdmissionPolicyBinding validationActions визначають, як оцінюються невдачі.

      Допустимі значення: Ignore або Fail. Стандартне значення — Fail.

    • spec.matchConditions ([]MatchCondition)

      Patch strategy: обʼєднання за ключем name

      Map: під час обʼєднання зберігаються унікальні значення за ключем name

      MatchConditions — це список умов, які мають бути виконані для перевірки запиту. Умови збігу фільтрують запити, які вже відповідали правилам, namespaceSelector та objectSelector. Порожній список matchConditions відповідає всім запитам. Максимально допустимо 64 умови перевірки збігів.

      Якщо надається обʼєкт параметрів, до нього можна отримати доступ за допомогою дескриптора params так само як до виразів перевірки.

      Логіка точного збігу така (за порядком):

      1. Якщо БУДЬ-ЯКА умова відповідності оцінюється як FALSE, політика оминається.
      2. Якщо ВСІ умови відповідності оцінюються як TRUE, політика оцінюється.
      3. Якщо будь-яка умова відповідності оцінюється як помилка (але жодна не є FALSE):
        • Якщо failurePolicy=Fail, запит відхиляється
        • Якщо failurePolicy=Ignore, політика пропускається

      MatchCondition представляє умову, яка має бути виконана для надсилання запиту до webhook.

      • spec.matchConditions.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінено CEL. Має оцінюватися як bool. CEL вирази мають доступ до вмісту AdmissionRequest та Authorizer, які знаходяться у змінних CEL:

        'object' — Обʼєкт із вхідного запиту. Значення null для запитів DELETE. 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE. 'request' — Атрибути запиту на допуск (/pkg/apis/admission/types.go#AdmissionRequest). 'authorizer' — Авторизатор CEL. Може використовуватися для виконання перевірок авторизації для виконавця (користувача або службового облікового запису) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz 'authorizer.requestResource' — Ресурс CEL, створений із 'authorizer' і налаштований із запитним ресурсом. Документація по CEL: https://kubernetes.io/docs/reference/using-api/cel/

        Обовʼязково.

      • spec.matchConditions.name (string), обовʼязково

        Name є ідентифікатором для цієї умови збігу, використовується для стратегічного обʼєднання MatchConditions, а також для надання ідентифікатора для цілей логування. Хороше імʼя має бути описовим для повʼязаної з ним умови. Імʼя повинно бути кваліфікованим імʼям, що складається з алфавітно-цифрових символів, '-', '' або '.', і повинно починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName', або 'my.name', або '123-abc', регулярний вираз, що використовується для перевірки '([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS піддомену та '/' (наприклад, 'example.com/MyName')

        Обовʼязково.

    • spec.matchConstraints (MatchResources)

      MatchConstraints вказує, які ресурси ця політика призначена перевіряти. AdmissionPolicy піклується про запит, якщо він відповідає всім Constraints. Однак, щоб запобігти стану нестабільності кластерів, який не можна виправити через API, ValidatingAdmissionPolicy не може відповідати ValidatingAdmissionPolicy та ValidatingAdmissionPolicyBinding. Обовʼязково.

      MatchResources вирішує, чи запускати політику контролю доступу до обʼєкта на основі того, чи відповідає він критеріям відповідності. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом, він виключається)

      • spec.matchConstraints.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ExcludeResourceRules описує, які операції над якими ресурсами/субресурсами не повинні цікавити політику ValidatingAdmissionPolicy. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом правилам, він виключається)

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це API групи, до яких належать ресурси. '*' означає всі групи. Якщо присутній симовл '*', довжина масиву повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це API версії, до яких належать ресурси. '*' означає всі версії. Якщо присутній '*', довжина масиву повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій та будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина масиву повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames —це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — це список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає Podʼи. 'pods/log' означає субресурс логу для Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

          Якщо присутній символ підстановки, правило перевірки забезпечить, що ресурси не перекривають один одного.

          Залежно від обʼєкта, що охоплює, субресурси можуть бути недозволеними. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.scope (string)

          scope вказує область застосування цього правила. Допустимі значення: "Cluster", "Namespaced" і "*" "Cluster" означає, що тільки ресурси на рівні кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що тільки ресурси на рівні простору імен відповідатимуть цьому правилу. "*" означає, що немає обмежень щодо області застосування. Субресурси відповідають області свого батьківського ресурсу. Стандартно — "*".

      • spec.matchConstraints.matchPolicy (string)

        matchPolicy визначає, як використовувати список "MatchResources" для відповідності вхідним запитам. Допустимі значення: "Exact" або "Equivalent".

        • Exact: відповідність запиту лише в разі точного збігу з певним правилом. Наприклад, якщо розгортання (deployments) можна змінити через apps/v1, apps/v1beta1 і extensions/v1beta1, але "правила" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде відправлено до ValidatingAdmissionPolicy.

        • Equivalent: відповідність запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу або версію API. Наприклад, якщо розгортання можна змінити через apps/v1, apps/v1beta1 і extensions/v1beta1, і "правила" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і відправлено до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchConstraints.namespaceSelector (LabelSelector)

        NamespaceSelector визначає, чи запускати політику контролю допуску для обʼєкта на основі того, чи відповідає простір імен для цього обʼєкта селектору. Якщо сам обʼєкт є простором імен, перевірка збігу виконується для обʼєкта.metadata.labels. Якщо обʼєкт є іншим кластерним ресурсом, політика ніколи не пропускається.

        Наприклад, щоб запускати вебхук для будь-яких обʼєктів, простір імен яких не повʼязаний з "runlevel" 0 або 1; ви встановите селектор наступним чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "runlevel",
      "operator": "NotIn",
      "values": [
        "0",
        "1"
      ]
    }
  ]
}

        Якщо замість цього ви хочете запускати політику лише для будь-яких обʼєктів, простір імен яких повʼязаний з "environment" "prod" або "staging"; ви встановите селектор наступним чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "environment",
      "operator": "In",
      "values": [
        "prod",
        "staging"
      ]
    }
  ]
}

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

        Стандартно — пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.objectSelector (LabelSelector)

        ObjectSelector визначає, чи запускати перевірку на основі наявності в обʼєкта відповідних міток. objectSelector оцінюється щодо старого та нового обʼєктів, які будуть відправлені на cel перевірку, і вважається, що є збіг, якщо хоча б один обʼєкт має збіг з селектором. Порожній обʼєкт (oldObject у разі створення або newObject у разі видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions) не вважається таким, що має збіг. Використовуйте селектор обʼєктів тільки якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Стандартно пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції з якими ресурсами/субресурсами відповідають ValidatingAdmissionPolicy. Політика цікавиться операцією, якщо вона відповідає будь-якому Правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — це список ресурсів, до яких застосовується це правило.

          Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

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

          Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

        • spec.matchConstraints.resourceRules.scope (string)

          scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*" "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • spec.paramKind (ParamKind)

      ParamKind визначає тип ресурсів, що використовуються для параметризації цієї політики. Якщо відсутній, то для цієї політики немає параметрів і змінна param CEL не буде надана для виразів перевірки. Якщо ParamKind посилається на неіснуючий тип, ця політика налаштована неправильно і застосовується FailurePolicy. Якщо paramKind вказано, але paramRef не встановлено в ValidatingAdmissionPolicyBinding, змінна params буде null.

      ParamKind є кортежем Group, Kind і Version.

      • spec.paramKind.apiVersion (string)

        APIVersion — це версія групи API, до якої належать ресурси. У форматі "group/version". Обовʼязково.

      • spec.paramKind.kind (string)

        Kind — це тип API, до якого належать ресурси. Обовʼязково.

    • spec.validations ([]Validation)

      Atomic: буде замінено під час злиття

      Validations містять CEL-вирази, які використовуються для застосування перевірки. Validations і AuditAnnotations не можуть обидва бути порожніми; потрібен мінімум щось одне з Validations або AuditAnnotations.

      Validation визначає CEL-вираз, який використовується для перевірки.

      • spec.validations.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінюватися CEL. ref: https://github.com/google/cel-spec CEL-вирази мають доступ до вмісту запиту/відповіді API, організованих у змінні CEL, а також деякі інші корисні змінні:

        • 'object' — Обʼєкт з вхідного запиту. Значення null для запитів DELETE.
        • 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE.
        • 'request' — Атрибути запиту API(ref).
        • 'params' — Параметр ресурсу, на який посилається перевірка політики. Заповнюється лише, якщо політика має ParamKind.
        • 'namespaceObject' — Обʼєкт простору імен, до якого належить вхідний обʼєкт. Значення null для ресурсів на рівні кластера.
        • 'variables' - Map змінних, від їх назви до їхнього ледачого (lazily) оцінюваного значення. Наприклад, змінна з назвою 'foo' може бути доступна як 'variables.foo'.
        • 'authorizer' — CEL Authorizer. Може використовуватися для виконання перевірок авторизації для виконавця (користувача або облікового запису служби) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz
        • 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' та налаштований для ресурсу запиту.

        apiVersion, kind, metadata.name і metadata.generateName завжди доступні з кореня обʼєкта. Інші властивості метаданих недоступні.

        Доступні лише імена властивостей у формі [a-zA-Z_.-/][a-zA-Z0-9_.-/]*. Доступні імена властивостей екрануються згідно з наступними правилами, коли доступні у виразі:

        • '__' екранується як 'underscores'

        • '.' екранується як 'dot'

        • '-' екранується як 'dash'

        • '/' екранується як 'slash'

        • Імена властивостей, що точно збігаються з CEL РЕЗЕРВОВАНИМИ ключовими словами, екрануються як '{keyword}'. Ключові слова включають: "true", "false", "null", "in", "as", "break", "const", "continue", "else", "for", "function", "if", "import", "let", "loop", "package", "namespace", "return". Приклади:

        • Вираз, що звертається до властивості з назвою "namespace": {"Expression": "object.namespace > 0"}

        • Вираз, що звертається до властивості з назвою "x-prop": {"Expression": "object.x__dash__prop > 0"}

        • Вираз, що звертається до властивості з назвою "redact__d": {"Expression": "object.redact__underscores__d > 0"}

        Рівність масивів із типом списку 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація масивів із типом списку x-kubernetes використовує семантику типу списку:

        • 'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів у X зберігаються, а елементи в Y, що не перетинаються, додаються зі збереженням їх часткового порядку.
        • 'map': X + Y виконує злиття, де позиції масиву всіх ключів у X зберігаються, але значення замінюються значеннями з Y, коли множини ключів X та Y перетинаються. Елементи в Y з ключами, що не перетинаються з ключами, що не перетинаються, додаються зі збереженням їх часткового порядку. Обовʼязково.

      • spec.validations.message (string)

        Message представляє повідомлення, що відображається при невдалій перевірці. Повідомлення обовʼязкове, якщо Expression містить розриви рядка. Повідомлення не повинно містити розриви рядка. Якщо не вказано, повідомлення — "failed rule: {Rule}". Наприклад, "must be a URL with the host matching spec.host" Якщо Expression містить розриви рядка, повідомлення обовʼязкове. Повідомлення не повинно містити розриви рядка. Якщо не встановлено, повідомлення — "failed Expression: {Expression}".

      • spec.validations.messageExpression (string)

        messageExpression оголошує CEL-вираз, який оцінюється як повідомлення про невдачу перевірки, що повертається, коли це правило не виконується. Оскільки messageExpression використовується як повідомлення про невдачу, воно повинно оцінюватися як рядок. Якщо і message, і messageExpression присутні у перевірці, то messageExpression буде використано, якщо перевірка не вдалася. Якщо messageExpression призводить до помилки під час виконання, помилка записується в лог, і повідомлення про невдачу перевірки створюється так, ніби поле messageExpression не було встановлено. Якщо messageExpression оцінюється як порожній рядок, рядок з лише пробілами або рядок, що містить розриви рядка, то повідомлення про невдачу перевірки також створюється так, ніби поле messageExpression не було встановлено, і факт того, що messageExpression створило порожній рядок/рядок з лише пробілами/рядок з розривами рядка, буде записано в лог. messageExpression має доступ до всіх тих самих змінних, що і expression, за винятком 'authorizer' та 'authorizer.requestResource'. Приклад: "object.x must be less than max ("+string(params.max)+")"

      • spec.validations.reason (string)

        Reason представляє машинно-зчитуваний опис того, чому ця перевірка не вдалася. Якщо це перша перевірка в списку, що не вдалася, ця причина, а також відповідний код відповіді HTTP, використовуються у відповіді HTTP клієнту. Наразі підтримувані причини: "Unauthorized", "Forbidden", "Invalid", "RequestEntityTooLarge". Якщо не встановлено, використовується StatusReasonInvalid у відповіді клієнту.

    • spec.variables ([]Variable)

      Patch strategy: злиття по ключу name

      Map: унікальні значення по ключу name будуть зберігатися під час злиття

      Variables містять визначення змінних, які можна використовувати у складі інших виразів. Кожна змінна визначена як іменований CEL-вираз. Змінні, визначені тут, будуть доступні у variables в інших виразах політики, за винятком MatchConditions, оскільки MatchConditions оцінюються перед рештою політики.

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

      Variable — це визначення змінної, яка використовується для складання. Змінна визначається як іменований вираз.

      • spec.variables.expression (string), обовʼязково

        Expression — це вираз, який буде оцінений як значення змінної. CEL-вираз має доступ до тих самих ідентифікаторів, що і CEL-вирази в Validation.

      • spec.variables.name (string), обовʼязково

        Name — це назва змінної. Назва повинна бути дійсним ідентифікатором CEL і унікальною серед усіх змінних. Змінна може бути доступна в інших виразах через variables Наприклад, якщо name є "foo", змінна буде доступна як variables.foo.

  • status (ValidatingAdmissionPolicyStatus)

    Статус ValidatingAdmissionPolicy, включаючи попередження, які корисні для визначення, чи працює політика відповідно до очікувань. Заповнюється системою. Тільки для читання.

    ValidatingAdmissionPolicyStatus представляє статус політики перевірки допуску.

    • status.conditions ([]Condition)

      Map: унікальні значення по ключу type будуть зберігатися під час злиття

      Стани представляють останні доступні спостереження поточного стану політики.

      Condition містить деталі одного аспекту поточного стану цього API-ресурсу.

      • status.conditions.lastTransitionTime (Time), обовʼязково

        lastTransitionTime — це останній час, коли стан перейшов з одного стану в інший. Це має бути, коли змінився основний стан. Якщо це невідомо, то прийнятно використовувати час, коли змінилося поле API.

        Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • status.conditions.message (string), обовʼязково

        message — це повідомлення зрозуміле людині, яке вказує деталі про зміну стану. Воно може бути порожній рядок.

      • status.conditions.reason (string), обовʼязково

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

      • status.conditions.status (string), обовʼязково

        статус стану, один з True, False, Unknown.

      • status.conditions.type (string), обовʼязково

        тип стану у форматі CamelCase або у форматі foo.example.com/CamelCase.

      • status.conditions.observedGeneration (int64)

        observedGeneration представляє .metadata.generation, на основі якого було встановлено стан. Наприклад, якщо .metadata.generation зараз 12, але .status.conditions[x].observedGeneration - 9, стан застарів відносно поточного стану екземпляра.

    • status.observedGeneration (int64)

      Покоління, яке спостерігалося контролером.

    • status.typeChecking (TypeChecking)

      Результати перевірки типу для кожного виразу. Наявність цього поля вказує на завершення перевірки типу.

      TypeChecking містить результати перевірки типу виразів у ValidatingAdmissionPolicy

      • status.typeChecking.expressionWarnings ([]ExpressionWarning)

        Atomic: буде замінено під час злиття

        Попередження перевірки типу для кожного виразу.

        ExpressionWarning — це інформація про попередження, що стосується конкретного виразу.

        • status.typeChecking.expressionWarnings.fieldRef (string), обовʼязково

          Шлях до поля, що посилається на вираз. Наприклад, посилання на вираз першого елемента перевірок є "spec.validations[0].expression".

        • status.typeChecking.expressionWarnings.warning (string), обовʼязково

          Вміст інформації про попередження перевірки типу у формі, зручною для читання людиною. Кожен рядок попередження містить тип, за яким перевірено вираз, а потім помилку перевірки типу від компілятора.

ValidatingAdmissionPolicyList

ValidatingAdmissionPolicyList - це список ValidatingAdmissionPolicy.

ValidatingAdmissionPolicyBinding

ValidatingAdmissionPolicyBinding повʼязує ValidatingAdmissionPolicy з параметризованими ресурсами. ValidatingAdmissionPolicyBinding та параметризовані CRD разом визначають, як адміністратори кластерів налаштовують політики для кластерів.

Для даного запиту на допуск кожне привʼязування спричиняє оцінку його політики N разів, де N дорівнює 1 для політик/привʼязок, які не використовують параметри, або кількість параметрів, обраних привʼязкою.

CEL вирази політики повинні мати обчислену вартість CEL нижче максимально допустимого бюджету CEL. Кожна оцінка політики отримує незалежний бюджет CEL. Додавання/видалення політик, привʼязок або параметрів не може впливати на те, чи знаходиться комбінація (policy, binding, param) у своєму бюджеті CEL.

  • apiVersion (string)

    APIVersion визначає версійну схему цього представлення обʼєкта. Сервери повинні перетворювати визнані схеми на останнє внутрішнє значення і можуть відхиляти невідомі значення. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources.

  • kind (string)

    Kind — це рядкове значення, що представляє REST ресурс, який представляє цей обʼєкт. Сервери можуть визначити це з точки доступу, до якої клієнт надсилає запити. Не можоже бути оновлене. У CamelCase. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds.

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicyBindingSpec)

    Специфікація бажаної поведінки ValidatingAdmissionPolicyBinding.

    ValidatingAdmissionPolicyBindingSpec - це специфікація ValidatingAdmissionPolicyBinding.

    • spec.matchResources (MatchResources)

      MatchResources оголошує, які ресурси відповідають цій привʼязці і будуть перевірені нею. Зауважте, що це перетинається з matchConstraints політики, тому лише запити, які відповідають політиці, можуть бути обрані. Якщо це поле не встановлено, всі ресурси, які відповідають політиці, перевіряються цією привʼязкою. Якщо resourceRules не встановлено, це не обмежує відповідність ресурсу. Якщо ресурс відповідає іншим полям цього обʼєкта, він буде перевірений. Зауважте, що це відрізняється від matchConstraints ValidatingAdmissionPolicy, де resourceRules є обовʼязковими.

      MatchResources вирішує, чи запускати політику контролю допуску на обʼєкті на основі відповідності критеріям відповідності. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом, він виключається).

      • spec.matchResources.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час обʼєднання

        ExcludeResourceRules описує, які операції на яких ресурсах/субресурсах ValidatingAdmissionPolicy не повинна враховувати. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом, він виключається).

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час обʼєднання

          APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час обʼєднання

          APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час обʼєднання

          Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час обʼєднання

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchResources.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час обʼєднання

          Resources — це список ресурсів, до яких застосовується це правило.

          Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

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

          Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

        • spec.matchResources.excludeResourceRules.scope (string)

          scope визначає сферу дії цього правила. Дійсні значення — "Cluster", "Namespaced" та "*". "Cluster" означає, що тільки ресурси кластерного рівня відповідатимуть цьому правилу. Обʼєкти API namespace є ресурсами кластерного рівня. "Namespaced" означає, що тільки ресурси namespace відповідатимуть цьому правилу. "*" означає, що немає обмежень на сферу дії. Субресурси відповідають сфері дії їхнього батьківського ресурсу. Стандартне значння — "*".

      • spec.matchResources.matchPolicy (string)

        matchPolicy визначає, як список "MatchResources" використовується для пошуку збігів з вхідними запитами. Дозволені значення — "Exact" або "Equivalent".

        • Exact: відповідати запиту тільки, якщо він точно відповідає зазначеному правилу. Наприклад, якщо розгортання (deployments) можна змінювати через apps/v1, apps/v1beta1 та extensions/v1beta1, але "rules" включали тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит на apps/v1beta1 або extensions/v1beta1 не буде надіслано до ValidatingAdmissionPolicy.

        • Equivalent: відповідати запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу або версію API. Наприклад, якщо розгортання (deployments) можна змінювати через apps/v1, apps/v1beta1 та extensions/v1beta1, і "rules" включали тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит на apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і надіслано до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchResources.namespaceSelector (LabelSelector)

        NamespaceSelector визначає, чи застосовувати політику контролю доступу до об’єкта на основі відповідності простору імен цього об’єкта селектору. Якщо об’єкт сам по собі є простором імен, відповідність перевіряється по обʼєкту.metadata.labels. Якщо об’єкт є іншим ресурсом на рівні кластера, він ніколи не пропускає політику.

        Наприклад, щоб запустити вебхук для будь-яких об’єктів, простір імен яких не пов’язаний з "runlevel" 0 або 1, необхідно налаштувати селектор наступним чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "runlevel",
      "operator": "NotIn",
      "values": [
        "0",
        "1"
      ]
    }
  ]
}

        Якщо натомість ви хочете застосовувати політику лише для об’єктів, простір імен яких пов’язаний з "environment" "prod" або "staging", необхідно налаштувати селектор наступним чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "environment",
      "operator": "In",
      "values": [
        "prod",
        "staging"
      ]
    }
  ]
}

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

        Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.objectSelector (LabelSelector)

        ObjectSelector визначає, чи потрібно виконувати перевірку на основі відповідності міток об’єкта. objectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані на перевірку cel, і вважається відповідним, якщо будь-який об’єкт відповідає селектору. Null обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або об’єкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions), не вважається відповідним. Використовуйте селектор об’єктів, тільки якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції на яких ресурсах/субресурсах відповідають ValidatingAdmissionPolicy. Політика враховує операцію, якщо вона відповідає будь-якому правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що все дозволено.

        • spec.matchResources.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — це список ресурсів, до яких застосовується це правило.

        Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

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

        Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

        • spec.matchResources.resourceRules.scope (string)

          scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*". "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • spec.paramRef (ParamRef)

      paramRef вказує на ресурс параметра, який використовується для налаштування політики контролю допуску. Він повинен вказувати на ресурс типу, визначеного в ParamKind прив’язаної ValidatingAdmissionPolicy. Якщо політика вказує ParamKind, а ресурс, на який посилається ParamRef, не існує, ця привʼязка вважається неправильно налаштованою, і застосовується FailurePolicy ValidatingAdmissionPolicy. Якщо політика не вказує ParamKind, це поле ігнорується, і правила оцінюються без параметра.

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

      • spec.paramRef.name (string)

        name — це імʼя ресурсу, на який посилаються.

        Одне з name або selector повинно бути встановлено, але name і selector є взаємовиключними властивостями. Якщо одне встановлено, інше повинно бути відключено.

        Один параметр, який використовується для всіх запитів на допуск, можна налаштувати, встановивши поле name, залишивши selector порожнім і встановивши простір імен, якщо paramKind має простір імен.

      • spec.paramRef.namespace (string)

        namespace — це простір імен ресурсу, на який посилаються. Дозволяє обмежити пошук параметрів певним простором імен. Застосовується як до полів name, так і до selector.

        Можна використовувати параметр для кожного простору імен, вказавши простір імен для paramKind у політиці та залишивши це поле порожнім.

        • Якщо paramKind є кластерним, це поле МАЄ бути не встановленим. Встановлення цього поля призведе до помилки конфігурації.

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

      • spec.paramRef.parameterNotFoundAction (string)

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

        Допустимі значення: Allow або Deny.

        Обовʼязково

      • spec.paramRef.selector (LabelSelector)

        selector може бути використаний для відповідності кільком обʼєктам параметрів на основі їх міток. Поставте selector: {} для відповідності всім ресурсам ParamKind.

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

        Одне з name або selector повинно бути встановлено, але name і selector є взаємовиключними властивостями. Якщо одне встановлено, інше повинно бути відключено.

    • spec.policyName (string)

      PolicyName посилається на ім’я ValidatingAdmissionPolicy, до якої прив’язується ValidatingAdmissionPolicyBinding. Якщо вказаний ресурс не існує, ця прив’язка вважається недійсною і буде ігнорована. Обовʼязково.

    • spec.validationActions ([]string)

      Set: під час злиття зберігатимуться унікальні значення

      validationActions визначає, як виконуються перевірки ValidatingAdmissionPolicy, на яку посилається ValidatingAdmissionPolicyBinding. Якщо перевірка оцінюється як хибна, вона завжди виконується відповідно до цих дій.

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

      validationActions оголошується як набір значень дій. Порядок не має значення. validationActions не можуть містити дублікатів одного й того самого значення дії.

      Підтримувані значення дій:

      "Deny" означає, що збій перевірки призводить до відхилення запиту.

      "Warn" означає, що збій перевірки повідомляється клієнту запиту в HTTP-заголовках попередження з кодом попередження 299. Попередження можуть надсилатися як для дозволених, так і для відхилених відповідей на допуск.

      "Audit" означає, що збій перевірки включається до опублікованої події аудиту для запиту. Подія аудиту міститиме анотацію аудиту validation.policy.admission.k8s.io/validation_failure зі значенням, що містить деталі збоїв перевірки, відформатовані як JSON-список об’єктів, кожен з яких має наступні поля:

      • message: Рядок повідомлення про збій перевірки
      • policy: Ім’я ресурсу ValidatingAdmissionPolicy
      • binding: Ім’я ресурсу ValidatingAdmissionPolicyBinding
      • expressionIndex: Індекс збоїв перевірки в ValidatingAdmissionPolicy
      • validationActions: Дії примусового виконання для збою перевірки Приклад анотації аудиту: "validation.policy.admission.k8s.io/validation_failure": "[{"message": "Invalid value", {"policy": "policy.example.com", {"binding": "policybinding.example.com", {"expressionIndex": "1", {"validationActions": ["Audit"]}]"

      Клієнти повинні очікувати обробки додаткових значень, ігноруючи будь-які значення, які не розпізнаються.

      "Deny" і "Warn" не можуть використовуватися разом, оскільки ця комбінація непотрібно дублює збій перевірки як у тілі відповіді API, так і в HTTP-заголовках попередження.

      Обовʼязково.

Операції

get отримати вказану ValidatingAdmissionPolicy

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

401: Unauthorized

get отримати статус вказаної ValidatingAdmissionPolicy

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ValidatingAdmissionPolicy

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies

Параметри

Відповідь

200 (ValidatingAdmissionPolicyList): OK

401: Unauthorized

create створення ValidatingAdmissionPolicy

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies

Параметри

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

202 (ValidatingAdmissionPolicy): Accepted

401: Unauthorized

update заміна вказаної ValidatingAdmissionPolicy

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: ValidatingAdmissionPolicy, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

update заміна статусу вказаної ValidatingAdmissionPolicy

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: ValidatingAdmissionPolicy, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

patch часткове оновлення вказаної ValidatingAdmissionPolicy

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

patch часткове оновдення статусу вказанох ValidatingAdmissionPolicy

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

delete видалення ValidatingAdmissionPolicy

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ValidatingAdmissionPolicy

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.6.8 - ValidatingAdmissionPolicyBinding

ValidatingAdmissionPolicyBinding звʼязує ValidatingAdmissionPolicy з параметризованими ресурсами.

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingAdmissionPolicyBinding

ValidatingAdmissionPolicyBinding повʼязує ValidatingAdmissionPolicy з параметризованими ресурсами. ValidatingAdmissionPolicyBinding і параметризовані CRD разом визначають, як адміністраторам кластерів налаштовувати політики для кластерів.

Для кожного запиту на допуск кожне звʼязування спричинить оцінку його політики N разів, де N дорівнює 1 для політик/звʼязувань, які не використовують параметри, в іншому випадку N є кількість параметрів, вибраних звʼязуванням.

CEL вирази політики повинні мати обчислену вартість CEL нижчу за максимальний бюджет CEL. Кожна оцінка політики отримує незалежний бюджет витрат CEL. Додавання/видалення політик, звʼязувань або параметрів не повинно впливати на те, чи є дана комбінація (політика, звʼязування, параметр) у межах свого бюджету CEL.

  • apiVersion: admissionregistration.k8s.io/v1

  • kind: ValidatingAdmissionPolicyBinding

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicyBindingSpec)

    Визначення бажаної поведінки ValidatingAdmissionPolicyBinding.

    ValidatingAdmissionPolicyBindingSpec є специфікацією ValidatingAdmissionPolicyBinding.

    • spec.matchResources (MatchResources)

      MatchResources декларує, які ресурси відповідають цьому звʼязуванню і будуть перевірені ним. Зверніть увагу, що це перетинається з matchConstraints політики, тому тільки запити, які відповідають політиці, можуть бути вибрані цим звʼязуванням. Якщо це не задано, всі ресурси, що відповідають політиці, будуть перевірені цим звʼязуванням.

      Коли resourceRules не задано, це не обмежує відповідність ресурсів. Якщо ресурс відповідає іншим полям цього обʼєкта, він буде перевірений. Зверніть увагу, що це відрізняється від matchConstraints ValidatingAdmissionPolicy, де resourceRules є обовʼязковими.

      MatchResources визначає, чи слід застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає він критеріям відповідності. Правила виключення мають перевагу над правилами включення (якщо ресурс відповідає обом, він буде виключений).

      • spec.matchResources.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ExcludeResourceRules описує, які операції над якими ресурсами/підресурсами ValidatingAdmissionPolicy не повинна враховувати. Правила виключення мають перевагу над правилами включення (якщо ресурс відповідає обом, він буде виключений).

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — це всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — необовʼязковий білий список імен, до яких застосовується правило. Порожній список означає, що дозволено все.

        • spec.matchResources.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

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

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchResources.excludeResourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

      • spec.matchResources.matchPolicy (string)

        matchPolicy визначає, як список "MatchResources" використовується для відповідності вхідним запитам. Дійсні значення: "Exact" або "Equivalent".

        • Exact: відповідати запиту лише тоді, коли він точно відповідає зазначеному правилу. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включали лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надісланий до ValidatingAdmissionPolicy.

        • Equivalent: відповідати запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу API або версію. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і надіслано до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchResources.namespaceSelector (LabelSelector)

        NamespaceSelector вирішує, чи слід застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає простір імен цього обʼєкта селектору. Якщо сам обʼєкт є простором імен, відповідність перевіряється за object.metadata.labels. Якщо обʼєкт є іншим ресурсом з областю кластеру, політика ніколи не пропускається.

        Наприклад, щоб застосовувати вебхук до будь-яких обʼєктів, простір імен яких не асоційований з "runlevel" значенням "0" або "1", ви встановите селектор наступним чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "runlevel",
      "operator": "NotIn",
      "values": [
        "0",
        "1"
      ]
    }
  ]
}

        Якщо ви хочете застосовувати політику лише до об'єктів, простір імен яких асоційований з "environment" значенням "prod" або "staging", ви встановите селектор наступним чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "environment",
      "operator": "In",
      "values": [
        "prod",
        "staging"
      ]
    }
  ]
}

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для прикладів селекторів міток.

        Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.objectSelector (LabelSelector)

        ObjectSelector вирішує, чи слід виконувати валідацію на основі того, чи має обʼєкт відповідні мітки. objectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані на перевірку CEL, і вважається відповідним, якщо хоча б один з обʼєктів відповідає селектору. Обʼєкт null (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions), не вважається таким, що мають збіг.

        Використовуйте селектор обʼєкта лише якщо вебхук є опціональним, оскільки кінцеві користувачі можуть пропустити вебхук допуску, встановивши мітки. Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції з якими ресурсами/підресурсами мають збіг ValidatingAdmissionPolicy. Політика враховує операцію, якщо вона відповідає будь-якому правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchResources.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

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

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchResources.resourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

    • spec.paramRef (ParamRef)

      paramRef вказує на ресурс параметра, який використовується для конфігурації політики контролю доступу. Він має вказувати на ресурс типу, зазначеного в ParamKind привʼязаної ValidatingAdmissionPolicy. Якщо політика вказує ParamKind, а ресурс, на який посилається ParamRef, не існує, це привʼязування вважається неправильно налаштованим, і застосовується FailurePolicy ValidatingAdmissionPolicy. Якщо політика не вказує ParamKind, це поле ігнорується, а правила оцінюються без параметра.

      ParamRef описує, як знайти параметри, які будуть використовуватися як вхідні дані для виразів правил, застосованих привʼязуванням політики.

      • spec.paramRef.name (string)

        name — це ім'я ресурсу, на який посилаються.

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

        Один параметр, що використовується для всіх запитів на допуск, можна налаштувати, задавши поле name, залишивши selector порожнім і задавши простір імен, якщо paramKind має область простору імен.

      • spec.paramRef.namespace (string)

        namespace — це простір імен ресурсу, на який посилаються. Дозволяє обмежити пошук параметрів певним простором імен. Застосовується до обох полів name і selector.

        Параметр для кожного простору імен можна використовувати, вказавши у політиці paramKind для простору імен і залишивши це поле порожнім.

        • Якщо paramKind має область дії кластер, це поле МАЄ бути не задане. Встановлення цього поля призводить до помилки конфігурації.

        • Якщо paramKind має область дії простір імен, буде використано простір імен обʼєкта, що оцінюється для допуску, коли це поле залишено порожнім. Зверніть увагу, що якщо це поле залишено пустим, привʼязування не повинно відповідати жодним ресурсам з областю дії кластера, що призведе до помилки.

      • spec.paramRef.parameterNotFoundAction (string)

        parameterNotFoundAction контролює поведінку привʼязування, коли ресурс існує, і name або selector є дійсними, але не знайдено жодних параметрів, які відповідають привʼязуванню. Якщо значення встановлено на Allow, то відсутність відповідних параметрів буде розглядатися привʼязуванням як успішна валідація. Якщо встановлено на Deny, то відсутність відповідних параметрів підлягатиме failurePolicy політиці.

        Дозволені значення — Allow або Deny

        Обовʼязково.

      • spec.paramRef.selector (LabelSelector)

      selector може використовуватися для відповідності кільком обʼєктам параметрів на основі їхніх міток. Постачайте selector: {} для відповідності всім ресурсам типу ParamKind.

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

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

    • spec.policyName (string)

      PolicyName посилається на імʼя ValidatingAdmissionPolicy, до якого привʼязується ValidatingAdmissionPolicyBinding. Якщо посиланий ресурс не існує, це привʼязування вважається недійсним і буде ігноруватися. Обовʼязкове.

    • spec.validationActions ([]string)

      Set: унікальні значення будуть збережені під час злиття

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

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

      validationActions оголошено як набір значень дій. Порядок не має значення. validationActions не може містити дублікатів однієї і тієї ж дії.

      Підтримувані значення дій:

      "Deny" вказує, що невдача валідації призводить до відмови у запиті.

      "Warn" вказує, що невдача валідації повідомляється клієнту запиту в заголовках HTTP Warning з кодом попередження 299. Попередження можуть бути надіслані як для дозволених, так і для відхилених відповідей на допуск.

      "Audit" вказує, що невдача валідації включена в опубліковану подію аудиту запиту. Подія аудиту буде містити анотацію аудиту validation.policy.admission.k8s.io/validation_failure зі значенням, яке містить деталі невдач валідації у форматі JSON списку обʼєктів, кожен з яких має такі поля:

      • message: Рядок повідомлення про невдачу валідації
      • policy: Імʼя ресурсу ValidatingAdmissionPolicy
      • binding: Імʼя ресурсу ValidatingAdmissionPolicyBinding
      • expressionIndex: Індекс невдалих валідацій у ValidatingAdmissionPolicy
      • validationActions: Дії виконання, що були застосовані до невдачі валідації

      Приклад анотації аудиту: "validation.policy.admission.k8s.io/validation_failure": "[{"message": "Invalid value", {"policy": "policy.example.com", {"binding": "policybinding.example.com", {"expressionIndex": "1", {"validationActions": ["Audit"]}]"

      Клієнти повинні очікувати обробку додаткових значень, ігноруючи будь-які нерозпізнані значення.

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

      Обовʼязкове.

ValidatingAdmissionPolicy

ValidatingAdmissionPolicy описує визначення політики валідації допуску, яка приймає або відхиляє обʼєкт без його зміни.

  • apiVersion (string)

    APIVersion визначає версію схеми цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення і можуть відхиляти невизнані значення. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  • kind (string)

    Kind — це рядкове значення, що представляє REST-ресурс, який цей обʼєкт уособлює. Сервери можуть виводити його з точки доступу, до якої клієнт надсилає запити. Не може бути оновлено. У форматі CamelCase. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicySpec)

    Визначення бажаної поведінки ValidatingAdmissionPolicy.

    ValidatingAdmissionPolicySpec — це специфікація бажаної поведінки AdmissionPolicy.

    • spec.auditAnnotations ([]AuditAnnotation)

      Atomic: буде замінено під час злиття

      auditAnnotations містить вирази CEL, які використовуються для створення анотацій аудиту для події аудиту API-запиту. validations і auditAnnotations не можуть бути обидва порожніми; принаймні одне з них є обовʼязковим.

      AuditAnnotation описує, як створити анотацію аудиту для запиту API.

      • spec.auditAnnotations.key (string), обовʼязково

        key визначає ключ анотації аудиту. Ключі анотацій аудиту для ValidatingAdmissionPolicy повинні бути унікальними. Ключ повинен бути кваліфікованим іменем ([A-Za-z0-9][-A-Za-z0-9_.]*) довжиною не більше 63 байтів.

        Ключ комбінується з іменем ресурсу ValidatingAdmissionPolicy для створення ключа анотації аудиту: "{Ім'я ValidatingAdmissionPolicy}/{ключ}".

        Якщо admission webhook використовує те саме ім'я ресурсу, що і ця ValidatingAdmissionPolicy, та той же ключ анотації аудиту, ключ анотації буде ідентичним. У цьому випадку перша анотація, написана з цим ключем, буде включена в подію аудиту, а всі наступні анотації з тим же ключем будуть відкинуті.

        Обовʼязкове.

      • spec.auditAnnotations.valueExpression (string), обовʼязково

        valueExpression представляє вираз, який оцінюється CEL для створення значення анотації аудиту. Вираз має оцінюватися як рядок або null. Якщо вираз оцінюється як рядок, анотація аудиту включається з рядковим значенням. Якщо вираз оцінюється як null або порожній рядок, анотація аудиту буде пропущена. valueExpression не може перевищувати 5 КБ в довжину. Якщо результат valueExpression перевищує 10 КБ в довжину, він буде обрізаний до 10 КБ.

        Якщо кілька ресурсів ValidatingAdmissionPolicyBinding відповідають API-запиту, вираз valueExpression буде оцінений для кожного привʼязування. Всі унікальні значення, отримані від valueExpressions, будуть обʼєднані в список, розділений комами.

        Обовʼязкове.

    • spec.failurePolicy (string)

      failurePolicy визначає, як обробляти помилки для політики допуску. Помилки можуть виникати через помилки парсингу виразів CEL, помилки перевірки типів, помилки виконання та неправильні або некоректно налаштовані визначення політики або привʼязки.

      Політика вважається недійсною, якщо spec.paramKind посилається на неіснуючий Kind. Привʼязка є недійсною, якщо spec.paramRef.name посилається на неіснуючий ресурс.

      failurePolicy не визначає, як обробляються валідації, що оцінюються як невірні.

      Коли failurePolicy встановлено на Fail, ValidatingAdmissionPolicyBinding validationActions визначає, як застосовуються помилки.

      Допустимі значення: Ignore або Fail. Стандартно — Fail.

    • spec.matchConditions ([]MatchCondition)

      Patch strategy: обʼєднання за ключем name

      Map: унікальні значення ключа name будуть збережені під час злиття

      MatchConditions — це список умов, які повинні бути виконані для валідації запиту. Умови збігу фільтрують запити, які вже були відповідно до правил, namespaceSelector і objectSelector. Порожній список matchConditions відповідає всім запитам. Максимальна кількість умов збігу — 64.

      Якщо надано обʼєкт параметра, до нього можна звертатися через дескриптор params так само, як і до виразів валідації.

      Точна логіка збігу (впорядкована):

      1. Якщо будь-яка умова matchCondition оцінюється як FALSE, політика пропускається.
      2. Якщо всі умови matchConditions оцінюються як TRUE, політика оцінюється.
      3. Якщо будь-яка умова matchCondition оцінюється як помилка (але жодна не є FALSE):
        • Якщо failurePolicy=Fail, запит відхиляється.
        • Якщо failurePolicy=Ignore, політика пропускається.

      MatchCondition представляє умову, яка повинна бути виконана для того, щоб запит був надісланий до вебхука.

      • spec.matchConditions.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінюватися CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту AdmissionRequest та Authorizer, організованого у змінні CEL:

        • 'object' — обʼєкт з вхідного запиту. Значення є null для запитів DELETE.
        • 'oldObject' — існуючий обʼєкт. Значення є null для запитів CREATE.
        • 'request' — атрибути запиту на допуск (/pkg/apis/admission/types.go#AdmissionRequest).
        • 'authorizer' — CEL Authorizer. Може бути використаний для виконання перевірок авторизації для принципала (користувача або облікового запису служби) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz.
        • 'authorizer.requestResource' — CEL ResourceCheck, створений з authorizer і налаштований з ресурсом запиту.

        Документація про CEL: https://kubernetes.io/docs/reference/using-api/cel/

        Обовʼязкове.

      • spec.matchConditions.name (string), обовʼязково

        Name є ідентифікатором для цієї умови збігу, який використовується для стратегічного злиття MatchConditions, а також для надання ідентифікатора для цілей журналювання. Добре вибране імʼя повинно бути описовим для відповідного виразу. Name повинно бути кваліфікованим іменем, що складається з алфавітно-цифрових символів, '-', '_' або '.', і повинно починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName', 'my.name', '123-abc', регулярний вираз для перевірки — '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS піддомену та '/' (наприклад, 'example.com/MyName').

        Обовʼязкове.

    • spec.matchConstraints (MatchResources)

      MatchConstraints визначає ресурси, які ця політика має перевіряти. AdmissionPolicy турбується про запит, якщо він відповідає усім Constraints. Однак, для запобігання випадкам, коли кластер може бути переведений в нестабільний стан, з якого не можна відновитися через API, ValidatingAdmissionPolicy не може відповідати ValidatingAdmissionPolicy і ValidatingAdmissionPolicyBinding.

      Обовʼязкове.

      MatchResources визначає, чи потрібно застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає він критеріям збігу. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом критеріям, він буде виключений).

      • spec.matchConstraints.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ExcludeResourceRules описує операції над ресурсами/підресурсами, про які ValidatingAdmissionPolicy не повинна турбуватися. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом критеріям, він буде виключений).

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

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

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchConstraints.excludeResourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

      • spec.matchConstraints.matchPolicy (string)

        matchPolicy визначає, як список "MatchResources" використовується для відповідності вхідним запитам. Дійсні значення: "Exact" або "Equivalent".

        • Exact: відповідати запиту лише тоді, коли він точно відповідає зазначеному правилу. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включали лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надісланий до ValidatingAdmissionPolicy.

        • Equivalent: відповідати запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу API або версію. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і надіслано до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchConstraints.namespaceSelector (LabelSelector)

        NamespaceSelector визначає, чи слід застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає простір імен цього обʼєкта селектору. Якщо обʼєкт сам є простором імен, то відповідність перевіряється на object.metadata.labels. Якщо обʼєкт є іншим ресурсом, що охоплює кластер, політика ніколи не пропускається.

        Наприклад, щоб застосувати вебхук до будь-яких обʼєктів, простір імен яких не асоціюється з "runlevel" "0" або "1", ви повинні встановити селектор наступним чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "runlevel",
      "operator": "NotIn",
      "values": [
        "0",
        "1"
      ]
    }
  ]
}

        Якщо ви хочете застосувати політику лише до обʼєктів, простір імен яких асоційований з "середовищем" "prod" або "staging", ви повинні налаштувати селектор таким чином:

        "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "environment",
      "operator": "In",
      "values": [
        "prod",
        "staging"
      ]
    }
  ]
}

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ щоб отримати більше прикладів селекторів міток.

        Стандартне значення пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.objectSelector (LabelSelector)

        ObjectSelector визначає, чи потрібно виконати перевірку на основі того, чи має обʼєкт відповідні мітки. ObjectSelector оцінюється як для старого обʼєкта (oldObject), так і для нового обʼєкта (newObject), які будуть надіслані для перевірки cel, і вважається, що він відповідає, якщо будь-який з обʼєктів відповідає селектору. Null-обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати мітки (такі як DeploymentRollback або PodProxyOptions), не вважається таким, що має збіг. Використовуйте селектор обʼєктів лише в разі, якщо веб-хук є опційним, оскільки кінцеві користувачі можуть пропустити admission webhook, налаштувавши мітки. Стандартно використовуйте пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції на яких ресурсах/підресурсах відповідає ValidatingAdmissionPolicy. Політика враховує операцію, якщо вона відповідає будь-якому правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

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

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchConstraints.resourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

    • spec.paramKind (ParamKind)

      ParamKind вказує тип ресурсів, які використовуються для параметризації цієї політики. Якщо відсутній, параметрів для цієї політики немає, і змінна param CEL не буде надана для виразів перевірки. Якщо ParamKind посилається на неіснуючий тип, ця конфігурація політики є неправильною, і застосовується FailurePolicy. Якщо paramKind зазначено, але paramRef не встановлено у ValidatingAdmissionPolicyBinding, змінна params буде null.

      ParamKind — це кортеж Group Kind та Version.

      • spec.paramKind.apiVersion (string)

        APIVersion - версія групи API, до якої належать ресурси. У форматі "group/version". Обовʼязковий параметр.

      • spec.paramKind.kind (string)

        Kind — це тип API, до якого належать ресурси. Обовʼязковий параметр.

    • spec.validations ([]Validation)

      Atomic: буде замінено під час злиття

      Validations містять вирази CEL, які використовуються для застосування перевірки. Validations та AuditAnnotations не можуть бути обидва пустими; потрібно щонайменше один з Validations або AuditAnnotations.

      Validation вказує вираз CEL, який використовується для застосування перевірки.

      • spec.validations.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінюватися CEL. ref: https://github.com/google/cel-spec CEL-вирази мають доступ до вмісту запиту/відповіді API, організованих у змінні CEL, а також деякі інші корисні змінні:

        • 'object' — Обʼєкт з вхідного запиту. Значення null для запитів DELETE.
        • 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE.
        • 'request' — Атрибути запиту API(ref).
        • 'params' — Параметр ресурсу, на який посилається перевірка політики. Заповнюється лише, якщо політика має ParamKind.
        • 'namespaceObject' — Обʼєкт простору імен, до якого належить вхідний обʼєкт. Значення null для ресурсів на рівні кластера.
        • 'variables' - Map змінних, від їх назви до їхнього ледачого (lazily) оцінюваного значення. Наприклад, змінна з назвою 'foo' може бути доступна як 'variables.foo'.
        • 'authorizer' — CEL Authorizer. Може використовуватися для виконання перевірок авторизації для виконавця (користувача або облікового запису служби) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz
        • 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' та налаштований для ресурсу запиту.

        apiVersion, kind, metadata.name і metadata.generateName завжди доступні з кореня обʼєкта. Інші властивості метаданих недоступні.

        Доступні лише імена властивостей у формі [a-zA-Z_.-/][a-zA-Z0-9_.-/]*. Доступні імена властивостей екрануються згідно з наступними правилами, коли доступні у виразі:

        • '__' екранується як 'underscores'

        • '.' екранується як 'dot'

        • '-' екранується як 'dash'

        • '/' екранується як 'slash'

        • Імена властивостей, що точно збігаються з CEL РЕЗЕРВОВАНИМИ ключовими словами, екрануються як '{keyword}'. Ключові слова включають: "true", "false", "null", "in", "as", "break", "const", "continue", "else", "for", "function", "if", "import", "let", "loop", "package", "namespace", "return". Приклади:

        • Вираз, що звертається до властивості з назвою "namespace": {"Expression": "object.namespace > 0"}

        • Вираз, що звертається до властивості з назвою "x-prop": {"Expression": "object.x__dash__prop > 0"}

        • Вираз, що звертається до властивості з назвою "redact__d": {"Expression": "object.redact__underscores__d > 0"}

        Рівність масивів із типом списку 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація масивів із типом списку x-kubernetes використовує семантику типу списку:

        • 'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів у X зберігаються, а елементи в Y, що не перетинаються, додаються зі збереженням їх часткового порядку.
        • 'map': X + Y виконує злиття, де позиції масиву всіх ключів у X зберігаються, але значення замінюються значеннями з Y, коли множини ключів X та Y перетинаються. Елементи в Y з ключами, що не перетинаються з ключами, що не перетинаються, додаються зі збереженням їх часткового порядку. Обовʼязково.

      • spec.validations.message (string)

        Message представляє повідомлення, що відображається при невдалій перевірці. Повідомлення обовʼязкове, якщо Expression містить розриви рядка. Повідомлення не повинно містити розриви рядка. Якщо не вказано, повідомлення — "failed rule: {Rule}". Наприклад, "must be a URL with the host matching spec.host" Якщо Expression містить розриви рядка, повідомлення обовʼязкове. Повідомлення не повинно містити розриви рядка. Якщо не встановлено, повідомлення — "failed Expression: {Expression}".

      • spec.validations.messageExpression (string)

        messageExpression оголошує CEL-вираз, який оцінюється як повідомлення про невдачу перевірки, що повертається, коли це правило не виконується. Оскільки messageExpression використовується як повідомлення про невдачу, воно повинно оцінюватися як рядок. Якщо і message, і messageExpression присутні у перевірці, то messageExpression буде використано, якщо перевірка не вдалася. Якщо messageExpression призводить до помилки під час виконання, помилка записується в лог, і повідомлення про невдачу перевірки створюється так, ніби поле messageExpression не було встановлено. Якщо messageExpression оцінюється як порожній рядок, рядок з лише пробілами або рядок, що містить розриви рядка, то повідомлення про невдачу перевірки також створюється так, ніби поле messageExpression не було встановлено, і факт того, що messageExpression створило порожній рядок/рядок з лише пробілами/рядок з розривами рядка, буде записано в лог. messageExpression має доступ до всіх тих самих змінних, що і expression, за винятком 'authorizer' та 'authorizer.requestResource'. Приклад: "object.x must be less than max ("+string(params.max)+")"

      • spec.validations.reason (string)

        Reason представляє машинно-зчитуваний опис того, чому ця перевірка не вдалася. Якщо це перша перевірка в списку, що не вдалася, ця причина, а також відповідний код відповіді HTTP, використовуються у відповіді HTTP клієнту. Наразі підтримувані причини: "Unauthorized", "Forbidden", "Invalid", "RequestEntityTooLarge". Якщо не встановлено, використовується StatusReasonInvalid у відповіді клієнту.

    • spec.variables ([]Variable)

      Patch strategy: злиття по ключу name

      Map: унікальні значення по ключу name будуть зберігатися під час злиття

      Variables містять визначення змінних, які можна використовувати у складі інших виразів. Кожна змінна визначена як іменований CEL-вираз. Змінні, визначені тут, будуть доступні у variables в інших виразах політики, за винятком MatchConditions, оскільки MatchConditions оцінюються перед рештою політики.

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

      Variable — це визначення змінної, яка використовується для складання. Змінна визначається як іменований вираз.

      • spec.variables.expression (string), обовʼязково

        Expression — це вираз, який буде оцінений як значення змінної. CEL-вираз має доступ до тих самих ідентифікаторів, що і CEL-вирази в Validation.

      • spec.variables.name (string), обовʼязково

        Name — це назва змінної. Назва повинна бути дійсним ідентифікатором CEL і унікальною серед усіх змінних. Змінна може бути доступна в інших виразах через variables Наприклад, якщо name є "foo", змінна буде доступна як variables.foo.

  • status (ValidatingAdmissionPolicyStatus)

    Статус ValidatingAdmissionPolicy, включаючи попередження, які корисні для визначення, чи працює політика відповідно до очікувань. Заповнюється системою. Тільки для читання.

    ValidatingAdmissionPolicyStatus представляє статус політики перевірки допуску.

    • status.conditions ([]Condition)

      Map: унікальні значення по ключу type будуть зберігатися під час злиття

      Стани представляють останні доступні спостереження поточного стану політики.

      Condition містить деталі одного аспекту поточного стану цього API-ресурсу.

      • status.conditions.lastTransitionTime (Time), обовʼязково

        lastTransitionTime — це останній час, коли стан перейшов з одного стану в інший. Це має бути, коли змінився основний стан. Якщо це невідомо, то прийнятно використовувати час, коли змінилося поле API.

        Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • status.conditions.message (string), обовʼязково

        message — це повідомлення зрозуміле людині, яке вказує деталі про зміну стану. Воно може бути порожній рядок.

      • status.conditions.reason (string), обовʼязково

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

      • status.conditions.status (string), обовʼязково

        статус стану, один з True, False, Unknown.

      • status.conditions.type (string), обовʼязково

        тип стану у форматі CamelCase або у форматі foo.example.com/CamelCase.

      • status.conditions.observedGeneration (int64)

        observedGeneration представляє .metadata.generation, на основі якого було встановлено стан. Наприклад, якщо .metadata.generation зараз 12, але .status.conditions[x].observedGeneration - 9, стан застарів відносно поточного стану екземпляра.

    • status.observedGeneration (int64)

      Покоління, яке спостерігалося контролером.

    • status.typeChecking (TypeChecking)

      Результати перевірки типу для кожного виразу. Наявність цього поля вказує на завершення перевірки типу.

      TypeChecking містить результати перевірки типу виразів у ValidatingAdmissionPolicy

      • status.typeChecking.expressionWarnings ([]ExpressionWarning)

        Atomic: буде замінено під час злиття

        Попередження перевірки типу для кожного виразу.

        ExpressionWarning — це інформація про попередження, що стосується конкретного виразу.

        • status.typeChecking.expressionWarnings.fieldRef (string), обовʼязково

          Шлях до поля, що посилається на вираз. Наприклад, посилання на вираз першого елемента перевірок є "spec.validations[0].expression".

        • status.typeChecking.expressionWarnings.warning (string), обовʼязково

          Вміст інформації про попередження перевірки типу у формі, зручною для читання людиною. Кожен рядок попередження містить тип, за яким перевірено вираз, а потім помилку перевірки типу від компілятора.

ValidatingAdmissionPolicyBindingList

ValidatingAdmissionPolicyBindingList — це список ValidatingAdmissionPolicyBinding.

Операції

get отримати вказанний ValidatingAdmissionPolicyBinding

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicyBinding

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ValidatingAdmissionPolicyBinding

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings

Параметри

Відповідь

200 (ValidatingAdmissionPolicyBindingList): OK

401: Unauthorized

create створення ValidatingAdmissionPolicyBinding

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings

Параметри

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

201 (ValidatingAdmissionPolicyBinding): Created

202 (ValidatingAdmissionPolicyBinding): Accepted

401: Unauthorized

update заміна вказаного ValidatingAdmissionPolicyBinding

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

201 (ValidatingAdmissionPolicyBinding): Created

401: Unauthorized

patch часткове оновлення вказаного ValidatingAdmissionPolicyBinding

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicyBinding

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

201 (ValidatingAdmissionPolicyBinding): Created

401: Unauthorized

delete видалення ValidatingAdmissionPolicyBinding

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicyBinding

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ValidatingAdmissionPolicyBinding

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.7 - Розширені ресурси

5.7.1 - CustomResourceDefinition

CustomResourceDefinition представляє ресурс, який повинен бути експонований на сервері API.

apiVersion: apiextensions.k8s.io/v1

import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

CustomResourceDefinition

CustomResourceDefinition представляє ресурс, який повинен бути експонований на сервері API. Його імʼя повинно бути у форматі <.spec.name>.<.spec.group>.

CustomResourceDefinitionSpec

CustomResourceDefinitionSpec визначає, як користувач хоче, щоб їхні ресурси виглядали

  • group (string), обовʼязково

    group — це API-група визначеного власного ресурсу. Власні ресурси обслуговуються як /apis/<group>/.... Повинно відповідати імені CustomResourceDefinition у форматі <names.plural>.<group>.

  • names (CustomResourceDefinitionNames), обовʼязково

    names вказують імена ресурсу та виду для власного ресурсу.

    CustomResourceDefinitionNames вказує імена для обслуговування цього CustomResourceDefinition

    • names.kind (string), обовʼязково

      kind — серіалізована версія виду ресурсу. Зазвичай CamelCase та однина. Екземпляри власного ресурсу використовуватимуть це значення як атрибут kind у викликах API.

    • names.plural (string), обовʼязково

      plural — імʼя ресурсу в множині для обслуговування. Власні ресурси обслуговуються як /apis/<group>/<version>/.../<plural>. Повинно відповідати імені CustomResourceDefinition у форматі <names.plural>.<group>. Всі літери мають бути у нижньому регістрі.

    • names.categories ([]string)

      Atomic: буде замінено під час злиття

      categories — це список згрупованих ресурсів, до яких належить цей власний ресурс (наприклад, 'all'). Публікується в документах відкриття API та використовується клієнтами для підтримки викликів типу kubectl get all.

    • names.listKind (string)

      listKind — серіалізована версія списку для цього ресурсу. Стандартне значення "kindList".

    • names.shortNames ([]string)

      Atomic: буде замінено під час злиття

      shortNames — короткі імена ресурсу, відображені в документах відкриття API та використовувані клієнтами для підтримки викликів типу kubectl get <shortname>. Всі літери мають бути у нижньому регістрі.

    • names.singular (string)

      singular — назва ресурсу в однині. Всі літери мають бути у нижньому регістрі. Стандартно, це значення є приведеним до нижнього регістру kind.

  • scope (string), обовʼязково

    scope вказує, чи має визначений власний ресурс область застосування, спільну для кластера або простору імен. Допустимі значення: Cluster і Namespaced.

  • versions ([]CustomResourceDefinitionVersion), обовʼязково

    Atomic: буде замінено під час злиття

    versions — це список всіх API-версій визначеного власного ресурсу. Назви версій використовуються для визначення порядку в зазначених API-версіях. Якщо рядок версії є "kube-like", він буде вище не "kube-like" рядків версій, що упорядковуються лексикографічно. "Kube-like" версії починаються з "v", за яким слідує номер (головна версія), а потім необовʼязково рядок "alpha" або "beta" та інший номер (додаткова версія). Ці версії сортуються так: GA > beta > alpha (де GA - версія без суфікса, такого як beta або alpha), а потім порівнюються головна версія, а потім додаткова версія. Приклад відсортованого списку версій: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.

    CustomResourceDefinitionVersion описує версію для CRD.

    • versions.name (string), обовʼязково

      name — це імʼя версії, наприклад "v1", "v2beta1" і т.д. Власні ресурси обслуговуються під цією версією за адресою /apis/<group>/<version>/..., якщо served встановлено в true.

    • versions.served (boolean), обовʼязково

      served — це прапорець, що дозволяє включити/відключити цю версію для обслуговування через REST API.

    • versions.storage (boolean), обовʼязково

      storage — вказує, що цю версію слід використовувати при збереженні власних ресурсів у сховищі. Повинна бути рівно одна версія з параметром storage=true.

    • versions.additionalPrinterColumns ([]CustomResourceColumnDefinition)

      Atomic: буде замінено під час злиття

      additionalPrinterColumns визначає додаткові стовпці, що повертаються в таблицях. Див. https://kubernetes.io/docs/reference/using-api/api-concepts/#receiving-resources-as-tables для деталей. Якщо стовпці не вказані, використовується один стовпець, що відображає вік власного ресурсу.

      CustomResourceColumnDefinition вказує стовпець для друку на стороні сервера.

      • versions.additionalPrinterColumns.jsonPath (string), обовʼязково

        jsonPath — простий шлях JSON (тобто з нотацією масиву), який оцінюється для кожного власного ресурсу для створення значення цього стовпця.

      • versions.additionalPrinterColumns.name (string), обовʼязково

        name — імʼя для стовпця зрозуміле людині.

      • versions.additionalPrinterColumns.type (string), обовʼязково

        type — визначення типу OpenAPI для цього стовпця. Див. https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types для деталей.

      • versions.additionalPrinterColumns.description (string)

        description — опис цього стовпця зрозумілий людині.

      • versions.additionalPrinterColumns.format (string)

        format - є необовʼязковим визначенням типу OpenAPI для цього стовпця. Формат 'name' застосовується до стовпця первинного ідентифікатора, щоб допомогти клієнтам ідентифікувати стовпець — це імʼя ресурсу. Дивіться https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types для більш детальної інформації.

      • versions.additionalPrinterColumns.priority (int32)

        priority — ціле число, що визначає відносну важливість цього стовпчика порівняно з іншими. Менші числа вважаються більш пріоритетними. Стовпці, які можуть бути пропущені в сценаріях з обмеженим простором, повинні мати пріоритет, більший за 0.

    • versions.deprecated (boolean)

      deprecated вказує, що ця версія API для власних ресурсів застаріла. Якщо встановлено значення true, запити API до цієї версії отримають заголовок попередження у відповіді сервера. Стандартне значення — false.

    • versions.deprecationWarning (string)

      deprecationWarning перевизначає стандартне попередження, що повертається клієнтам API. Може бути встановлене лише тоді, коли deprecated встановлено в true. Стандартне попередження вказує на те, що ця версія застаріла і рекомендує використовувати останню доступну версію з рівною або більшою стабільністю, якщо така існує.

    • versions.schema (CustomResourceValidation)

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

      CustomResourceValidation є переліком методів валідації для CustomResource.

      • versions.schema.openAPIV3Schema (JSONSchemaProps)

        openAPIV3Schema визначає схему OpenAPI v3 для валідації та обрізання власного ресурсу.

    • versions.selectableFields ([]SelectableField)

      Atomic: буде замінено під час злиття

      selectableFields визначає шляхи до полів, які можуть бути використані як селектори полів. Дозволяється використовувати максимум 8 вибіркових полів. https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors

      SelectableField вказує шлях JSON до поля, яке може бути використане з селекторами полів.

      • versions.selectableFields.jsonPath (string), required

        jsonPath — це простий шлях JSON, який оцінюється для кожного власного ресурсу, щоб отримати значення селектора поля. Дозволяються лише JSON-шляхи без нотації масивів. Повинен вказувати на поле типу string, boolean або integer. Дозволяються типи з enum-значеннями та рядки з форматами. Якщо jsonPath посилається на відсутнє поле в ресурсі, він оцінюється як порожній рядок. Не повинен вказувати на поля метаданих. Обовʼязкове поле.

    • versions.subresources (CustomResourceSubresources)

      subresources вказують, які додаткові ресурси цієї версії визначеного власного ресурсу доступні.

      CustomResourceSubresources вказує, як оброляти мастшатабування субресурсів для CustomResource.

      • versions.subresources.scale.specReplicasPath (string), обовʼязково

        specReplicasPath визначає шлях JSON всередині власного ресурсу, який відповідає Scale spec.replicas. Допускаються тільки JSON-шляхи без нотації масиву. Повинен бути JSON-шлях у форматі .spec. Якщо у власному ресурсі немає значення за вказаним шляхом, субресурс /scale поверне помилку при виконанні GET.

      • versions.subresources.scale.statusReplicasPath (string), обовʼязково

        statusReplicasPath визначає шлях JSON всередині власного ресурсу, який відповідає Scale status.replicas. Допускаються лише JSON-шляхи без нотації масиву. Повинен бути JSON-шлях під .status. Якщо у власному ресурсі немає значення за вказаним шляхом, значення status.replicas у субресурсі /scale буде стандартно дорівнювати 0.

      • versions.subresources.scale.labelSelectorPath (string)

        labelSelectorPath визначає шлях JSON всередині власного ресурсу, який відповідає Scale status.selector. Допускаються лише JSON-шляхи без нотації масиву. Повинен бути JSON-шлях під .status або .spec. Має бути налаштований на роботу з HorizontalPodAutoscaler. Поле, на яке вказує цей JSON-шлях, має бути рядковим полем (не складною структурою селектора), яке містить серіалізований селектор міток у рядковій формі. Детальніше: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions#scale-subresource Якщо у власному ресурсі немає значення за вказаним шляхом, значення status.selector у субресурсі /scale буде стандартно дорівнювати порожньому рядку.

      • versions.subresources.status (CustomResourceSubresourceStatus)

        status вказує, що власний ресурс має обслуговувати субресурс /status. Коли ввімкнено:

        1. запити до первинної точки доступу власного ресурсу ігнорують зміни в розділі status обʼєкта.
        2. Запити до субресурсу /status власного ресурсу ігнорують зміни будь-чого, окрім строфи status обʼєкта.

        CustomResourceSubresourceStatus визначає, як обслуговувати субресурс статусу для власних ресурсів. Статус представляється JSON-шляхом .status всередині власного ресурсу. Якщо встановлено,

        • відкриває субресурс /status для власного ресурсу
        • PUT-запити до субресурсу /status отримують обʼєкт власного ресурсу та ігнорують зміни у всьому, окрім рядка статусу
        • PUT/POST/PATCH запити до власного ресурсу ігнорують зміни у рядку стану

  • conversion (CustomResourceConversion)

    conversion визначає налаштування конвертації для CRD.

    CustomResourceConversion описує, як конвертувати різні версії CR.

    • conversion.strategy (string), обовʼязково

      strategy визначає, як налаштовуються власні ресурси між версіями. Допустимі значення:

      • "None": Конвертер змінює тільки apiVersion і не торкається інших полів у власному ресурсі.
      • "Webhook": API Server викликає зовнішній webhook для виконання конвертації. Додаткова інформація потрібна для цього варіанту. Це вимагає, щоб spec.preserveUnknownFields було встановлено у false, а spec.conversion.webhook було налаштовано.

    • conversion.webhook (WebhookConversion)

      webhook описує, як викликати конвертаційний webhook. Обовʼязково, якщо strategy встановлено на "Webhook".

      WebhookConversion описує, як викликати конвертаційний webhook

      • conversion.webhook.conversionReviewVersions ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        conversionReviewVersions — впорядкований список пріоритетних версій ConversionReview, які очікує Webhook. API сервер використовує першу версію зі списку, яку він підтримує. Якщо жодна з версій, зазначених у цьому списку, не підтримується API сервером, конвертація для власного ресурсу не відбудеться. Якщо збережена конфігурація Webhook визначає дозволені версії та не включає жодної версії, відомої API серверу, виклики до webhook не будуть успішними.

      • conversion.webhook.clientConfig (WebhookClientConfig)

        clientConfig містить інструкції щодо виклику webhook, якщо strategy є Webhook.

        WebhookClientConfig містить інформацію для встановлення TLS-зʼєднання з webhook.

        • conversion.webhook.clientConfig.caBundle ([]byte)

          caBundle — PEM-кодований CA пакет, який буде використовуватися для перевірки сертифіката сервера webhook. Якщо не вказано, використовуються системні корені довіри на apiserver.

        • conversion.webhook.clientConfig.service (ServiceReference)

          service — це посилання на сервіс для цього webhook. Необхідно вказати або service, або url.

          Якщо webhook працює в межах кластера, слід використовувати service.

          ServiceReference містить посилання на Service.legacy.k8s.io

          • conversion.webhook.clientConfig.service.name (string), обовʼязково

            name — це імʼя сервісу. Обовʼязково

          • conversion.webhook.clientConfig.service.namespace (string), обовʼязково

            namespace — це простір імен сервісу. Обовʼязково

          • conversion.webhook.clientConfig.service.path (string)

            path — це необовʼязковий URL шлях, за яким буде контактуватися webhook.

          • conversion.webhook.clientConfig.service.port (int32)

            port — це необовʼязковий порт сервісу, за яким буде контактуватися webhook. port повинен бути дійсним номером порту (1-65535, включно). Стандартно встановлено 443 для зворотної сумісності.

        • conversion.webhook.clientConfig.url (string)

          url вказує місце розташування webhook у стандартній URL формі (scheme://host:port/path). Потрібно вказати точно один з url або service.

          host не повинен посилатися на сервіс, що працює в кластері; натомість використовуйте поле service. host може бути знайдений через зовнішній DNS на деяких apiservers (наприклад, kube-apiserver не може розвʼязати DNS у кластері, оскільки це було б порушенням рівнів). host також може бути IP-адресою.

          Зверніть увагу, що використання localhost або 127.0.0.1 як host ризиковано, якщо ви не вживаєте великої обережності, щоб запустити цей webhook на всіх хостах, які можуть потребувати викликів до цього webhook. Такі установки, ймовірно, будуть непереносними, тобто їх не легко переносити в новий кластер.

          Схема повинна бути "https"; URL повинен починатися з "https://".

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

          Спроба використати автентифікацію користувача або базову автентифікацію, наприклад, "user:password@" не дозволена. Фрагменти ("#...") та параметри запиту ("?...") також не дозволені.

  • preserveUnknownFields (boolean)

    preserveUnknownFields вказує, що поля обʼєкта, які не зазначені в схемі OpenAPI, повинні зберігатися під час зберігання. apiVersion, kind, metadata та відомі поля всередині metadata завжди зберігаються. Це поле застаріле і замість нього слід встановлювати x-preserve-unknown-fields на true в spec.versions[*].schema.openAPIV3Schema. Деталі дивіться на https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning.

JSONSchemaProps

JSONSchemaProps є JSON-схемою, яка відповідає Специфікації Draft 4 (http://json-schema.org/).

  • $ref (string)

  • $schema (string)

  • additionalItems (JSONSchemaPropsOrBool)

    JSONSchemaPropsOrBool представляє JSONSchemaProps або булеве значення. Стандартно встановлюється у true для булевого значення.

  • additionalProperties (JSONSchemaPropsOrBool)

    JSONSchemaPropsOrBool представляє JSONSchemaProps або булеве значення. Стандартно встановлюється у true для булевого значення.

  • allOf ([]JSONSchemaProps)

    Atomic: буде замінено під час злиття

  • anyOf ([]JSONSchemaProps)

    Atomic: буде замінено під час злиття

  • default (JSON)

    default є стандартним значенням для невизначених полів обʼєкта. Використання стандартних значень є бета-функцією у функціональних можливостей CustomResourceDefaulting. Використання стандартних значень вимагає, щоб spec.preserveUnknownFields було встановлено у false.

    JSON представляє будь-яке допустиме значення JSON. Підтримуються такі типи: bool, int64, float64, string, []interface{}, map[string]interface{} та nil.

  • definitions (map[string]JSONSchemaProps)

  • dependencies (map[string]JSONSchemaPropsOrStringArray)

    JSONSchemaPropsOrStringArray представляє JSONSchemaProps або масив рядків.

  • description (string)

  • enum ([]JSON)

    Atomic: буде замінено під час злиття

    JSON представляє будь-яке допустиме значення JSON. Підтримуються такі типи: bool, int64, float64, string, []interface{}, map[string]interface{} та nil.

  • example (JSON)

    JSON представляє будь-яке допустиме значення JSON. Підтримуються такі типи: bool, int64, float64, string, []interface{}, map[string]interface{} та nil.

  • exclusiveMaximum (boolean)

  • exclusiveMinimum (boolean)

  • externalDocs (ExternalDocumentation)

    ExternalDocumentation дозволяє посилатися на зовнішній ресурс для розширеної документації.

    • externalDocs.description (string)

    • externalDocs.url (string)

  • format (string)

    format — це рядок формату OpenAPI v3. Невідомі формати ігноруються. Наступні формати перевіряються:

    • bsonobjectid: BSON Object ID, тобто 24-символьний шістнадцятковий рядок
    • uri: URI, який розбирається за допомогою Golang net/url.ParseRequestURI
    • email: адреса електронної пошти, яка розбирається за допомогою Golang net/mail.ParseAddress
    • hostname: дійсне представлення імені хоста в Інтернеті, визначене RFC 1034, розділ 3.1 [RFC1034]
    • ipv4: IPv4 IP, який розбирається за допомогою Golang net.ParseIP
    • ipv6: IPv6 IP, який розбирається за допомогою Golang net.ParseIP
    • cidr: CIDR, який розбирається за допомогою Golang net.ParseCIDR
    • Mac: MAC-адреса, яка розбирається за допомогою Golang net.ParseMAC
    • uuid: UUID, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$
    • uuid3: UUID3, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?3[0-9a-f]{3}-?[0-9a-f]{4}-?[0-9a-f]{12}$
    • uuid4: UUID4, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?4[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$
    • uuid5: UUID5, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?5[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$
    • isbn: номер ISBN10 або ISBN13, наприклад, "0321751043" або "978-0321751041"
    • isbn10: номер ISBN10, наприклад, "0321751043"
    • isbn13: номер ISBN13, наприклад, "978-0321751041"
    • creditcard: номер кредитної картки, який визначається регулярним виразом ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$ з будь-якими нецифровими символами
    • ssn: номер соціального страхування США, який відповідає регулярному виразу ^\d{3}[- ]?\d{2}[- ]?\d{4}$
    • hexcolor: шістнадцятковий код кольору, наприклад, "#FFFFFF", який відповідає регулярному виразу ^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$
    • rgbcolor: код кольору RGB, наприклад, "rgb(255,255,255)"
    • byte: двійкові дані, закодовані в base64
    • password: будь-який тип рядка
    • date: рядок дати, наприклад, "2006-01-02", як визначено у full-date у RFC3339
    • duration: рядок тривалості, наприклад, "22 ns", який розбирається за допомогою Golang time.ParseDuration або сумісний з форматом тривалості Scala
    • datetime: рядок дати і часу, наприклад, "2014-12-15T19:30:20.000Z", як визначено у date-time у RFC3339

  • id (string)

  • items (JSONSchemaPropsOrArray)

    JSONSchemaPropsOrArray представляє значення, яке може бути JSONSchemaProps або масивом JSONSchemaProps. Переважно використовується для цілей серіалізації.

  • maxItems (int64)

  • maxLength (int64)

  • maxProperties (int64)

  • maximum (double)

  • minItems (int64)

  • minLength (int64)

  • minProperties (int64)

  • minimum (double)

  • multipleOf (double)

  • not (JSONSchemaProps)

  • nullable (boolean)

  • oneOf ([]JSONSchemaProps)

Atomic: буде замінено під час злиття

  • pattern (string)

  • patternProperties (map[string]JSONSchemaProps)

  • properties (map[string]JSONSchemaProps)

  • required ([]string)

    Atomic: буде замінено під час злиття

  • title (string)

  • type (string)

  • uniqueItems (boolean)

  • x-kubernetes-embedded-resource (boolean)

    x-kubernetes-embedded-resource визначає, що значення є вбудованим обʼєктом Kubernetes runtime.Object, з TypeMeta та ObjectMeta. Тип має бути object. Дозволяється подальше обмеження вбудованого обʼєкта. kind, apiVersion та metadata перевіряються автоматично. x-kubernetes-preserve-unknown-fields може бути true, але це не обовʼязково, якщо обʼєкт повністю вказаний (аж до kind, apiVersion, metadata).

  • x-kubernetes-int-or-string (boolean)

    x-kubernetes-int-or-string вказує, що це значення є або цілим числом, або рядком. Якщо це true, дозволено порожній тип, а тип як нащадок anyOf дозволений, якщо дотримується один з наступних шаблонів:

    1. anyOf:
      • type: integer
      • type: string
    2. allOf:
      • anyOf:
        • type: integer
        • type: string
      • ... нуль або більше

  • x-kubernetes-list-map-keys ([]string)

    Atomic: буде замінено під час злиття

    x-kubernetes-list-map-keys анотує масив з типом списку x-kubernetes map, вказуючи ключі, які використовуються як індекс map.

    Цей теґ МАЄ використовуватися тільки для списків, які мають розширення "x-kubernetes-list-type" встановлене на "map". Також значення, вказані для цього атрибута, мають бути полем типу scalar структури нащадка (вкладення не підтримується).

    Властивості, зазначені у цьому полі, повинні бути або обовʼязковими, або мати стандартне значення, щоб забезпечити наявність цих властивостей для всіх елементів списку.

  • x-kubernetes-list-type (string)

    x-kubernetes-list-type анотує масив, щоб більш детально описати його топологію. Це розширення має використовуватися тільки для списків і може мати 3 можливі значення:

    1. atomic: список розглядається як єдине ціле, як скаляр. Списки atomic будуть повністю замінені при оновленні. Це розширення може використовуватися для будь-якого типу списків (структур, скалярів тощо).
    2. set: Набори — це списки, які не повинні мати кілька елементів з однаковим значенням. Кожне значення повинно бути скаляром, обʼєктом з x-kubernetes-map-type atomic або масивом з x-kubernetes-list-type atomic.
    3. map: Ці списки схожі на map тим, що їх елементи мають неіндексований ключ, який використовується для їх ідентифікації. Порядок зберігається при злитті. Теґ map має використовуватися тільки для списків з елементами типу object. Стандартне значення для масивів — atomic.

  • x-kubernetes-map-type (string)

    x-kubernetes-map-type анотує обʼєкт, щоб більш детально описати його топологію. Це розширення має використовуватися тільки, коли тип обʼєкта є object і може мати 2 можливі значення:

    1. granular: Ці maps є справжніми map (пари ключ-значення) і кожне поле незалежне одне від одного (їх можна маніпулювати окремими акторами). Це стандартн поведінка для всіх map.
    2. atomic: список розглядається як єдине ціле, як скаляр. Atomic maps будуть повністю замінені при оновленні.

  • x-kubernetes-preserve-unknown-fields (boolean)

    x-kubernetes-preserve-unknown-fields зупиняє етап декодування на сервері API від видалення полів, які не вказані у схемі перевірки. Це впливає на поля рекурсивно, але повертається до нормальної поведінки видалення, якщо вкладені властивості або додаткові властивості вказані у схемі. Це може бути true або не визначено. Використання false заборонено.

  • x-kubernetes-validations

    Patch strategy: злиття за ключем rule.

    Map: унікальні значення ключа rule будуть збережені під час злиття.

    x-kubernetes-validations описує список правил валідації записаних мовою CEL.

    ValidationRule описує правило валідації записане мовою CEL.

    • x-kubernetes-validations.rule (string), обовʼязково

      Правило (rule) представляє вираз, який буде оцінюватися за допомогою CEL. Докладніше: https://github.com/google/cel-spec. Правило обмежується місцем розташування розширення x-kubernetes-validations у схемі. Змінна self у виразі CEL привʼязана до обмеженого значення. Приклад:

      • Правило обмежене коренем ресурсу з субресурсом status: {"rule": "self.status.actual <= self.spec.maxDesired"}

      Якщо Правило обмежене обʼєктом з властивостями, доступні властивості обʼєкта вибираються через self.field, а наявність поля можна перевірити через has(self.field). Поля з нульовим значенням розглядаються як відсутні поля у виразах CEL. Якщо Правило обмежене обʼєктом з additionalProperties (тобто map), значення map доступні через self[mapKey], наявність ключа в map можна перевірити через mapKey in self, а всі записи map доступні через макроси та функції CEL, такі як self.all(...). Якщо Правило обмежене масивом, елементи масиву доступні через self[i], а також через макроси та функції. Якщо Правило обмежене скаляром, self привʼязується до значення скаляра. Приклади:

      • Правило обмежене картою обʼєктів: {"rule": "self.components['Widget'].priority < 10"}
      • Правило обмежене списком цілих чисел: {"rule": "self.values.all(value, value >= 0 && value < 100)"}
      • Правило обмежене рядковим значенням: {"rule": "self.startsWith('kube')"}

      apiVersion, kind, metadata.name та metadata.generateName завжди доступні з кореня обʼєкта та з будь-яких обʼєктів, позначених як x-kubernetes-embedded-resource. Жодні інші властивості метаданих не доступні.

      Невідомі дані, збережені у власних ресурсах через x-kubernetes-preserve-unknown-fields, не доступні у виразах CEL. Це включає:

      • Невідомі значення полів, що зберігаються схемами обʼєктів з x-kubernetes-preserve-unknown-fields.

      • Властивості обʼєкта, де схема властивості має "невідомий тип". "Невідомий тип" рекурсивно визначається як:

      • Схема без типу і з x-kubernetes-preserve-unknown-fields встановленим у true

      • Масив, де схема елементів має "невідомий тип"

      • Обʼєкт, де схема additionalProperties має "невідомий тип"

      Доступні лише імена властивостей формату [a-zA-Z_.-/][a-zA-Z0-9_.-/]*. Доступні імена властивостей екрануються за наступними правилами, коли до них звертаються у виразі:

      • '__' екранується як 'underscores'
      • '.' екранується як 'dot'
      • '-' екранується як 'dash'
      • '/' екранується як 'slash'
      • Імена властивостей, які точно збігаються з зарезервованими ключовими словами CEL, екрануються як '{keyword}'. Ключові слова: "true", "false", "null", "in", "as", "break", "const", "continue", "else", "for", "function", "if", "import", "let", "loop", "package", "namespace", "return".

      Приклади:

      • Правило, яке звертається до властивості з імʼям "namespace": {"rule": "self.namespace > 0"}
      • Правило, яке звертається до властивості з імʼям "x-prop": {"rule": "self.x__dash__prop > 0"}
      • Правило, яке звертається до властивості з імʼям "redact__d": {"rule": "self.redact__underscores__d > 0"}

      Рівність масивів з x-kubernetes-list-type 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація масивів з x-kubernetes-list-type використовує семантику типу списку:

      • 'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів у X зберігаються, а елементи в Y, що не перетинаються, додаються зі збереженням їх часткового порядку.
      • 'map': X + Y виконує злиття, де позиції масиву всіх ключів у X зберігаються, але значення замінюються значеннями в Y, коли набори ключів X та Y перетинаються. Елементи в Y з ключами, що не перетинаються з ключами, додаються зі збереженням їх часткового порядку.

      Якщо в rule використовується змінна oldSelf, це неявно означає, що це "правило переходу" (transition rule).

      Стандартно, змінна oldSelf має той самий тип, що й self. Коли параметр optionalOldSelf встановлено як true, змінна oldSelf стає CEL-варіантом (optional), і її метод value() матиме той самий тип, що й self. Деталі можна знайти в документації до поля optionalOldSelf.

      Правила переходу стандартно застосовуються лише до запитів UPDATE і пропускаються, якщо старе значення не було знайдено. Ви можете налаштувати безумовну оцінку правила переходу, встановивши optionalOldSelf як true.

    • x-kubernetes-validations.fieldPath (string)

      fieldPath представляє шлях до поля, що повертається, коли перевірка не вдається. Він має бути відносним JSON шляхом (тобто з нотацією масиву), обмеженим місцем розташування цього розширення x-kubernetes-validations у схемі та посилатися на існуюче поле. Наприклад, коли перевірка перевіряє, чи існує певний атрибут foo в map testMap, fieldPath може бути встановлений як .testMap.foo. Якщо перевірка перевіряє, що два списки повинні мати унікальні атрибути, fieldPath може бути встановлений як будь-який зі списків: наприклад, .testList. Він не підтримує числовий індекс списку. Він підтримує операції з дочірніми елементами для посилання на існуюче поле. Для отримання додаткової інформації дивіться Підтримка JSONPath у Kubernetes. Числовий індекс масиву не підтримується. Для імені поля, що містить спеціальні символи, використовуйте ['specialName'] для посилання на імʼя поля. Наприклад, для атрибута foo.34$, що зʼявляється у списку testList, fieldPath може бути встановлений як .testList['foo.34$'].

    • x-kubernetes-validations.message (string)

      message представляє повідомлення, яке відображається, коли перевірка не вдається. Повідомлення є обовʼязковим, якщо у Правилі є розриви рядків. Повідомлення не повинно містити розривів рядків. Якщо не встановлено, повідомлення буде "failed rule: {Rule}". Наприклад, "must be a URL with the host matching spec.host".

  • x-kubernetes-validations.messageExpression (string)

    messageExpression оголошує вираз CEL, який оцінюється як повідомлення про помилку перевірки, яке повертається, коли це правило не вдається. Оскільки messageExpression використовується як повідомлення про помилку, він повинен оцінюватися як рядок. Якщо і message, і messageExpression присутні у правилі, тоді messageExpression буде використаний у разі невдалої перевірки. Якщо messageExpression призводить до помилки під час виконання, ця помилка записується в лог, і повідомлення про помилку перевірки створюється так, ніби поле messageExpression не встановлено. Якщо messageExpression оцінюється як порожній рядок, рядок, що містить лише пробіли, або рядок, що містить розриви рядків, то повідомлення про помилку перевірки також створюється так, ніби поле messageExpression не встановлено, і факт того, що messageExpression створив порожній рядок/рядок з пробілами/рядок з розривами рядків, записується в лог. messageExpression має доступ до всіх тих же змінних, що й правило; єдина відмінність — тип значення, що повертається. Приклад: "x must be less than max ("+string(self.max)+")".

    • x-kubernetes-validations.optionalOldSelf (boolean)

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

      Коли цей параметр увімкнено, змінна oldSelf стає CEL-варіантом (optional), значенням якого буде None, якщо старе значення відсутнє або обʼєкт створюється вперше.

      Ви можете перевірити наявність значення у oldSelf за допомогою методу oldSelf.hasValue() і розпакувати його після перевірки за допомогою oldSelf.value(). Більше інформації можна знайти в документації CEL щодо типів Optional: https://pkg.go.dev/github.com/google/cel-go/cel#OptionalTypes

      Цей параметр не може бути встановлений, якщо oldSelf не використовується в rule.

  • x-kubernetes-validations.reason (string)

    reason забезпечує машинозчитувану причину невдачі перевірки, яка повертається до абонента, коли запит не проходить це правило перевірки. Код стану HTTP, що повертається до абонента, буде відповідати причині першого невдалого правила перевірки. Поточні підтримувані причини: "FieldValueInvalid", "FieldValueForbidden", "FieldValueобовʼязково", "FieldValueDuplicate". Якщо не встановлено, стандартно використовується "FieldValueInvalid". Усі майбутні додані причини повинні прийматися клієнтами при читанні цього значення, а невідомі причини повинні оброблятися як FieldValueInvalid.

CustomResourceDefinitionStatus

CustomResourceDefinitionStatus вказує стан CustomResourceDefinition.

  • acceptedNames (CustomResourceDefinitionNames)

    acceptedNames — це імена, які фактично використовуються для обслуговування виявлення ресурсів. Вони можуть відрізнятися від імен у специфікації.

    CustomResourceDefinitionNames вказує імена для обслуговування цього CustomResourceDefinition

    • acceptedNames.kind (string), обовʼязково

      kind — серіалізоване імʼя типу ресурсу. Зазвичай CamelCase в однині. Екземпляри спеціальних ресурсів будуть використовувати це значення як атрибут kind у викликах API.

    • acceptedNames.plural (string), обовʼязково

      plural — імʼя ресурсу для обслуговування в множині. Спеціальні ресурси обслуговуються як /apis/\<group>/\<version>/.../\<plural>. Має відповідати імені CustomResourceDefinition (у формі \<names.plural>.\<group>). Має бути в нижньому регістрі.

    • acceptedNames.categories ([]string)

      Atomic: буде замінено під час злиття

      categories — це список згрупованих ресурсів, до яких належить цей власний ресурс (наприклад, 'all'). Публікується у документах виявлення API і використовується клієнтами для підтримки викликів типу kubectl get all.

    • acceptedNames.listKind (string)

      listKind — серіалізоване імʼя списку для цього ресурсу. Стандартне значення — "kindList".

    • acceptedNames.shortNames ([]string)

      Atomic: буде замінено під час злиття

      shortNames — короткі імена для ресурсу, які відображаються в документах виявлення API і використовуються клієнтами для підтримки викликів типу kubectl get \<shortname>. Мають бути в нижньому регістрі.

    • acceptedNames.singular (string)

      singular — імʼя ресурсу в однині. Має бути в нижньому регістрі. Стандартно використовується нижній регістр kind.

  • conditions ([]CustomResourceDefinitionCondition)

    Map: унікальні значення за типом ключа будуть збережені під час злиття

    conditions — вказують стан для окремих аспектів CustomResourceDefinition

    CustomResourceDefinitionCondition містить деталі поточного стану цього CustomResourceDefinition.

    • conditions.status (string), обовʼязково

      status — статус стану. Може бути True, False або Unknown.

    • conditions.type (string), обовʼязково

      type — тип стану. Типи включають Established, NamesAccepted і Terminating.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — час останньої зміни стану з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message — текст, зрощумілий людині, що вказує деталі останньої зміни стану.

    • conditions.reason (string)

      reason — унікальна однозначна причина в CamelCase для останньої зміни стану.

  • storedVersions ([]string)

    Atomic: буде замінено під час злиття

    storedVersions перераховує всі версії CustomResources, які коли-небудь зберігалися. Відстеження цих версій дозволяє визначити шлях міграції для збережених версій в etcd. Поле є змінним, тому контролер міграції може завершити міграцію до іншої версії (переконавшись, що у сховищі не залишилося старих обʼєктів), а потім видалити решту версій з цього списку. Версії не можна видаляти з spec.versions, доки вони існують у цьому списку.

CustomResourceDefinitionList

CustomResourceDefinitionList є списком обʼєктів CustomResourceDefinition.

Операції

get отримати вказаний CustomResourceDefinition

HTTP запит

GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

401: Unauthorized

get отримати статус вказаного CustomResourceDefinition

HTTP запит

GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CustomResourceDefinition

HTTP запит

GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions

Параметри

Відповідь

200 (CustomResourceDefinitionList): OK

401: Unauthorized

create створення CustomResourceDefinition

HTTP запит

POST /apis/apiextensions.k8s.io/v1/customresourcedefinitions

Параметри

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

202 (CustomResourceDefinition): Accepted

401: Unauthorized

update заміна вказаного CustomResourceDefinition

HTTP запит

PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: CustomResourceDefinition, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

update заміна статусу вказаного CustomResourceDefinition

HTTP запит

PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: CustomResourceDefinition, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

patch часткове оновлення вказаного CustomResourceDefinition

HTTP запит

PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

patch часткове оновлення статусу вказаного CustomResourceDefinition

HTTP запит

PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

delete видалення CustomResourceDefinition

HTTP запит

DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CustomResourceDefinition

HTTP запит

DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.7.2 - DeviceClass v1alpha3

DeviceClass — це ресурс, наданий постачальником або адміністратором, який містить конфігурацію пристрою та селектори.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

DeviceClass

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

Це альфа-тип і вимагає увімкнення функціональної можливості DynamicResourceAllocation.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: DeviceClass

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих

  • spec (DeviceClassSpec), обовʼязково

    Spec визначає, що можна призначити і як це налаштувати.

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

    Зміна spec автоматично збільшує номер metadata.generation.

DeviceClassSpec

DeviceClassSpec використовується в [DeviceClass] для визначення того, що може бути призначено і як це налаштувати.

  • config ([]DeviceClassConfiguration)

    Atomic: буде замінено під час злиття

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

    Вони передаються драйверу, але не враховуються при розподілі заявки.

    DeviceClassConfiguration використовується в DeviceClass.

    • config.opaque (OpaqueDeviceConfiguration)

      Opaque надає специфічні для драйвера параметри конфігурації.

      OpaqueDeviceConfiguration містить параметри конфігурації драйвера у форматі, визначеному постачальником драйвера.

      • config.opaque.driver (string), обовʼязково

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

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

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

      • config.opaque.parameters (RawExtension), обовʼязково

        Параметри можуть містити довільні дані. Відповідальність за перевірку та керування версіями покладається на розробника драйверів. Зазвичай це включає самоідентифікацію та версію ("kind" + "apiVersion" для типів Kubernetes), а також конвертацію між різними версіями.

        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 буде виглядати приблизно так:

        {
	"kind":"MyAPIObject",
	"apiVersion":"v1",
	"myPlugin": {
		"kind":"PluginA",
		"aOption":"foo",
	},
}

        Що відбувається? Спочатку декодування використовує json або yaml для десеріалізації даних у ваш зовнішній MyAPIObject. Це призводить до зберігання необробленого JSON, але без розпакування. Наступний крок — копіювання (за допомогою pkg/conversion) у внутрішню структуру. Функції перетворення, встановлені в DefaultScheme пакета runtime, розпаковують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, коли обʼєкт має невідомий тип, буде створено і збережено обʼєкт runtime.Unknown.)

  • selectors ([]DeviceSelector)

    Atomic: буде замінено під час злиття

    Кожному селектору повинен відповідати пристрій, що заявляється в цьому класі.

    DeviceSelector повинен мати рівно одне встановлене поле.

    • selectors.cel (CELDeviceSelector)

      CEL містить вираз CEL для вибору пристрою.

      CELDeviceSelector містить вираз CEL для вибору пристрою.

      • selectors.cel.expression (string), обовʼязковий

        Вираз є виразом CEL, який оцінює один пристрій. Він має оцінюватися як true, коли пристрій відповідає бажаним критеріям, і як false, коли не відповідає. Будь-який інший результат є помилкою і призводить до зупинки надання пристроїв.

        Вхідні дані виразу — це обʼєкт з назвою "device", який має наступні властивості:

        • driver (рядок): імʼя драйвера, який визначає цей пристрій.
        • attributes (map[string]object): атрибути пристрою, згруповані за префіксом (наприклад, device.attributes["dra.example.com"] оцінюється як обʼєкт з усіма атрибутами, які були префіксовані "dra.example.com").
        • capacity (map[string]object): обсяги пристрою, згруповані за префіксом.

        Приклад: Розглянемо пристрій з driver="dra.example.com", який надає два атрибути з назвою "model" та "ext.example.com/family" і один обсяг з назвою "modules". Вхідні дані для цього виразу будуть мати такі поля:

        device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

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

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

        Якщо невідомий префікс використовується для запиту в device.attributes або device.capacity, буде повернено порожній map. Будь-яке посилання на невідоме поле спричинить помилку оцінки і зупинку виділення.

        Робочий вираз має перевіряти наявність атрибутів перед їх використанням.

        Для зручності використання доступна функція cel.bind(), яка може бути використана для спрощення виразів, що звертаються до кількох атрибутів з одного домену. Наприклад:

        cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

  • suitableNodes (NodeSelector)

    Лише вузли, що відповідають селектору, будуть враховуватися планувальником при спробі знайти Вузол, що підходить для Podʼа, коли цей Pod використовує запит, який ще не був виділений і цей запит виділяється через контролер панелі управління. Він ігнорується, коли запит не використовує контролер панелі управління для виділення.

    Налаштування цього поля є необовʼязковим. Якщо не задано, всі Вузли є кандидатами.

    Це поле є альфа-версією і потребує увімкнення функціональної можливості DRAControlPlaneController.

    Селектор вузлів представляє об'єднання результатів одного або кількох запитів міток над набором вузлів; тобто, він представляє OR (логічне "або") селекторів, що представлені термінами селектора вузлів.

    • suitableNodes.nodeSelectorTerms ([]NodeSelectorTerm), обов'язково

      Atomic: буде замінено під час злиття

      Обов'язковий параметр. Список термів селектора вузлів. Терми обʼєднуються оператором OR.

      Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      • suitableNodes.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузлів за мітками вузлів.

      • suitableNodes.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузла за полями вузла.

DeviceClassList

DeviceClassList — це колекція класів.

  • apiVersion: resource.k8s.io/v1alpha3

  • kind: DeviceClassList

  • metadata (ListMeta)

    Стандартні метадані списку

  • items ([]DeviceClass), обовʼязково

    Items —список класів ресурсів.

Operations

get отримати вказаний DeviceClass

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DeviceClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (DeviceClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу DeviceClass

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/deviceclasses

Параметри

Відповідь

200 (DeviceClassList): OK

401: Unauthorized

create створення DeviceClass

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/deviceclasses

Параметри

Відповідь

200 (DeviceClass): OK

201 (DeviceClass): Created

202 (DeviceClass): Accepted

401: Unauthorized

update заміна вказаного DeviceClass

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DeviceClass

  • body: DeviceClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DeviceClass): OK

201 (DeviceClass): Created

401: Unauthorized

patch часткове оновлення вказаного DeviceClass

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DeviceClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (DeviceClass): OK

201 (DeviceClass): Created

401: Unauthorized

delete видалення DeviceClass

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

Відповідь

200 (DeviceClass): OK

202 (DeviceClass): Accepted

401: Unauthorized

deletecollection видалення колекції DeviceClass

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/deviceclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.7.3 - MutatingWebhookConfiguration

MutatingWebhookConfiguration описує конфігурацію вебхука, який приймає або відхиляє і може змінювати обʼєкт.

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

MutatingWebhookConfiguration

MutatingWebhookConfiguration описує конфігурацію вебхука, який приймає або відхиляє і може змінювати обʼєкт.

  • apiVersion: admissionregistration.k8s.io/v1

  • kind: MutatingWebhookConfiguration

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • webhooks ([]MutatingWebhook)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Webhooks — це список вебхуків та відповідних ресурсів і операцій.

    MutatingWebhook описує вебхук допуску та ресурси й операції, до яких він застосовується.

    • webhooks.admissionReviewVersions ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      AdmissionReviewVersions — це впорядкований список версій AdmissionReview, які очікує вебхук. Сервер API спробує використати першу версію зі списку, яку він підтримує. Якщо жодна з вказаних версій не підтримується сервером API, перевірка цього обʼєкта зазнає невдачі. Якщо збережена конфігурація вебхука вказує дозволені версії, але не включає жодної версії, відомої серверу API, виклики до вебхука зазнають невдачі й підпадають під політику відмови.

    • webhooks.clientConfig (WebhookClientConfig), обовʼязково

      ClientConfig визначає, як спілкуватися з вебхуком. Обовʼязково.

      WebhookClientConfig містить інформацію для встановлення TLS-зʼєднання з вебхуком.

      • webhooks.clientConfig.caBundle ([]byte)

        caBundle — це закодований у PEM набір сертифікатів CA, який використовуватиметься для перевірки сертифіката сервера вебхука. Якщо не вказано, використовуються системні корені довіри на сервері API.

      • webhooks.clientConfig.service (ServiceReference)

        service — це посилання на сервіс для цього вебхука. Необхідно вказати або service, або url.

        Якщо вебхук працює в межах кластера, то слід використовувати service.

        ServiceReference містить посилання на Service.legacy.k8s.io.

        • webhooks.clientConfig.service.name (string), обовʼязково

          name — це імʼя сервісу. Обовʼязково.

        • webhooks.clientConfig.service.namespace (string), обовʼязково

          namespace — це простір імен сервісу. Обовʼязково.

        • webhooks.clientConfig.service.path (string)

          path — це необовʼязковий URL шлях, який буде надіслано в будь-якому запиті до цього сервісу.

        • webhooks.clientConfig.service.port (int32)

          Якщо вказано, то це порт на сервісі, який є хостом вебхуку. Типово 443 для зворотної сумісності. port має бути дійсним номером порту (1-65535, включно).

      • webhooks.clientConfig.url (string)

        url вказує місце розташування вебхука в стандартній формі URL (scheme://host:port/path). Необхідно вказати або url, або service.

        host не повинен посилатися на сервіс, що працює в кластері; використовуйте поле service натомість. Хост може бути знайдений через зовнішній DNS в деяких серверах API (наприклад, kube-apiserver не може працювати з кластерним DNS, оскільки це було б порушенням розшарування). host може також бути IP-адресою.

        Зверніть увагу, що використання localhost або 127.0.0.1 як host є ризикованим, якщо ви не вживаєте великих заходів обережності, щоб запустити цей вебхук на всіх хостах, що запускають сервер API, який може потребувати викликів до цього вебхука. Такі встановлення, ймовірно, будуть непереносимими, тобто їх буде важко розгорнути в новому кластері.

        Схема має бути "https"; URL має починатися з "https://".

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

        Спроба використання автентифікації користувача або базової автентифікації, наприклад, "user:password@", не дозволена. Також не дозволяються фрагменти ("#...") і параметри запиту ("?...").

    • webhooks.name (string), обовʼязково

      Імʼя вебхуку допуску. Імʼя має бути повністю кваліфікованим, наприклад, imagepolicy.kubernetes.io, де "imagepolicy" є назвою вебхука, а kubernetes.io — назвою організації. Обовʼязково.

    • webhooks.sideEffects (string), обовʼязково

      SideEffects вказує, чи має цей вебхук побічні ефекти. Допустимі значення: None, NoneOnDryRun (вебхуки, створені у v1beta1, також можуть вказати Some або Unknown). Вебхуки з побічними ефектами МАЮТЬ реалізувати систему узгодження, оскільки запит може бути відхилено на наступному етапі ланцюжка допуску, і побічні ефекти потрібно буде скасувати. Запити з атрибутом dryRun автоматично відхиляються, якщо вони відповідають вебхуку з sideEffects == Unknown або Some.

    • webhooks.failurePolicy (string)

      FailurePolicy визначає, як обробляються нерозпізнані помилки від точки доступу допуску — дозволені значення: Ignore або Fail. Стандартне значення — Fail.

    • webhooks.matchConditions ([]MatchCondition)

      Patch strategy: злиття за ключем name

      Map: унікальні значення за ключем name будуть збережені під час злиття

      MatchConditions — це список умов, які мають бути виконані для надсилання запиту до цього вебхука. Умови відповідності фільтрують запити, які вже були підібрані за правилами, namespaceSelector і objectSelector. Порожній список matchConditions відповідає всім запитам. Максимальна кількість умов відповідності — 64.

      Логіка точного збігу така (за порядком):

      1. Якщо БУДЬ-ЯКА умова відповідності оцінюється як FALSE, вебхук оминається.
      2. Якщо ВСІ умови відповідності оцінюються як TRUE, вебхук викликається.
      3. Якщо будь-яка умова відповідності оцінюється як помилка (але жодна не є FALSE):
        • Якщо failurePolicy=Fail, запит відхиляється
        • Якщо failurePolicy=Ignore, помилка ігнорується і вебхук оминається

      MatchCondition представляє умову, яка має бути виконана для надсилання запиту до вебхука.

      • webhooks.matchConditions.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінено CEL. Результат обробки — bool. Вирази CEL мають доступ до вмісту AdmissionRequest і Authorizer, організованих у змінні CEL:

        'object' — Обʼєкт із вхідного запиту. Значення null для запитів DELETE. 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE. 'request' — Атрибути запиту допуску (/pkg/apis/admission/types.go#AdmissionRequest). 'authorizer' — CEL Authorizer. Може бути використано для виконання перевірок авторизації для виконавця (користувач або службового облікового запису) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' і налаштований із ресурсом запиту. Документація щодо CEL: https://kubernetes.io/docs/reference/using-api/cel/

        Обовʼязково.

      • webhooks.matchConditions.name (string), обовʼязково

        Name — це ідентифікатор цієї умови відповідності, використовується для стратегії злиття умов відповідності, а також для надання ідентифікатора для цілей логування. Хороша назва має бути описовою для повʼязаного виразу. Назва має бути кваліфікованою назвою, що складається з алфавітно-цифрових символів, '-', '' або '.', і має починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName' або 'my.name' або '123-abc', регулярний вираз, що використовується для перевірки, — '([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS субдомену та '/' (наприклад, 'example.com/MyName').

        Обовʼязково.

    • webhooks.matchPolicy (string)

      matchPolicy визначає, як використовується список "rules" для відповідності вхідним запитам. Допустимі значення — "Exact" або "Equivalent".

      • Exact: відповідність запиту тільки в тому випадку, якщо він точно відповідає зазначеному правилу. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надіслано до вебхука.

      • Equivalent: відповідність запиту, якщо він змінює ресурс, вказаний у правилах, навіть через іншу групу API або версію. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворений на apps/v1 і надісланий до вебхука.

      Стандартне значення — "Equivalent".

    • webhooks.namespaceSelector (LabelSelector)

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

      Наприклад, щоб запустити вебхук для будь-яких обʼєктів, чий простір імен не повʼязаний з "runlevel" 0 або 1, потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "runlevel",
      "operator": "NotIn",
      "values": [
        "0",
        "1"
      ]
    }
  ]
}

      Якщо замість цього ви хочете запустити вебхук для будь-яких обʼєктів, чий простір імен повʼязаний з "environment" "prod" або "staging", потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "environment",
      "operator": "In",
      "values": [
        "prod",
        "staging"
      ]
    }
  ]
}

      Див. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

      Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.objectSelector (LabelSelector)

      ObjectSelector визначає, чи буде вебхук працювати з обʼєктом на основі того, чи має обʼєкт відповідні мітки. ObjectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані до вебхука, і вважається відповідним, якщо будь-який з обʼєктів відповідає селектору. Нульовий обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions обʼєкт), не вважається таким, що має збіг. Використовуйте objectSelector лише якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.reinvocationPolicy (string)

      reinvocationPolicy вказує, чи має цей вебхук викликатися кілька разів у рамках однієї оцінки допуску. Допустимі значення — "Never" і "IfNeeded".

      Never: вебхук не буде викликатися більше одного разу в рамках однієї оцінки допуску.

      IfNeeded: вебхук буде викликаний щонайменше один додатковий раз у рамках оцінки допуску, якщо обʼєкт, який допускаєтсья, змінюється іншими втулками допуску після початкового виклику вебхука. Вебхуки, які вказують цю опцію, мають бути ідемпотентними, здатними обробляти обʼєкти, які вони попередньо прийняли. Зверніть увагу:

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

      Стандартне значення — "Never".

    • webhooks.rules ([]RuleWithOperations)

      Atomic: буде замінено під час злиття

      Rules описує, які операції з якими ресурсами/субресурсами цікавлять вебхук. Вебхук цікавить операція, якщо вона відповідає будь-якому правилу. Однак, щоб запобігти тому, що ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks можуть привести кластер до стану, з якого неможливо відновитися без повного вимкнення втулка, ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks ніколи не викликаються на запити допуску для обʼєктів ValidatingWebhookConfiguration і MutatingWebhookConfiguration.

      RuleWithOperations — це кортеж операцій і ресурсів. Рекомендується переконатися, що всі розширення кортежу є дійсними.

      • webhooks.rules.apiGroups ([]string)

        Atomic: буде замінено під час злиття

        APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.apiVersions ([]string)

        Atomic: буде замінено під час злиття

        APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.operations ([]string)

        Atomic: буде замінено під час злиття

        Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.resources ([]string)

        Atomic: буде замінено під час злиття

        Resources — це список ресурсів, до яких застосовується це правило.

        Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

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

        Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

      • webhooks.rules.scope (string)

        scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*" "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • webhooks.timeoutSeconds (int32)

      TimeoutSeconds визначає тайм-аут для цього вебхука. Після закінчення тайм-ауту виклик вебхука буде проігноровано або виклик API завершиться невдачею залежно від політики відмови. Значення тайм-ауту має бути від 1 до 30 секунд. Стандартне значення — 10 секунд.

MutatingWebhookConfigurationList

MutatingWebhookConfigurationList — це список MutatingWebhookConfiguration.

Операції

get отримати вказану MutatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the MutatingWebhookConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (MutatingWebhookConfiguration): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу MutatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations

Параметри

Відповідь

200 (MutatingWebhookConfigurationList): OK

401: Unauthorized

create створення MutatingWebhookConfiguration

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations

Параметри

Відповідь

200 (MutatingWebhookConfiguration): OK

201 (MutatingWebhookConfiguration): Created

202 (MutatingWebhookConfiguration): Accepted

401: Unauthorized

update заміна вказаної MutatingWebhookConfiguration

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

Відповідь

200 (MutatingWebhookConfiguration): OK

201 (MutatingWebhookConfiguration): Created

401: Unauthorized

patch часткове оновлення вказаної MutatingWebhookConfiguration

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the MutatingWebhookConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (MutatingWebhookConfiguration): OK

201 (MutatingWebhookConfiguration): Created

401: Unauthorized

delete видалення MutatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the MutatingWebhookConfiguration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції MutatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.7.4 - ValidatingWebhookConfiguration

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

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingWebhookConfiguration

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

  • apiVersion: admissionregistration.k8s.io/v1

  • kind: ValidatingWebhookConfiguration

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • webhooks ([]ValidatingWebhook)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Webhooks — це список вебхуків і ресурсів та операцій, які вони зачіпають.

    ValidatingWebhook описує вебхук допуску та ресурси й операції, до яких він застосовується.

    • webhooks.admissionReviewVersions ([]string), обовʼязково

      Atomic: буде замінено під час злиття

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

    • webhooks.clientConfig (WebhookClientConfig), обовʼязково

      ClientConfig визначає, як спілкуватися з вебхуком. Обовʼязково

      WebhookClientConfig містить інформацію для встановлення TLS-зʼєднання з вебхуком

      • webhooks.clientConfig.caBundle ([]byte)

        caBundle — це PEM-кодований набір сертифікатів CA, який буде використовуватися для перевірки сертифіката сервера вебхука. Якщо не вказано, використовуються системні корені довіри на API сервері.

      • webhooks.clientConfig.service (ServiceReference)

        service — це посилання на сервіс для цього вебхука. Необхідно вказати або service, або url.

        Якщо вебхук працює в межах кластера, тоді слід використовувати service.

        ServiceReference містить посилання на Service.legacy.k8s.io

        • webhooks.clientConfig.service.name (string), обовʼязково

          name — це імʼя сервісу. Обовʼязково

        • webhooks.clientConfig.service.namespace (string), обовʼязково

          namespace — це простір імен сервісу. Обовʼязково

        • webhooks.clientConfig.service.path (string)

          path — це необовʼязковий URL-шлях, який буде надіслано в будь-якому запиті до цього сервісу.

        • webhooks.clientConfig.service.port (int32)

        Якщо вказано, то це порт на сервісі, який є хостом вебхуку. Типово 443 для зворотної сумісності. port має бути дійсним номером порту (1-65535, включно).

      • webhooks.clientConfig.url (string)

        url вказує місце розташування вебхука в стандартній формі URL (scheme://host:port/path). Необхідно вказати або url, або service.

        host не повинен посилатися на сервіс, що працює в кластері; використовуйте поле service натомість. Хост може бути знайдений через зовнішній DNS в деяких серверах API (наприклад, kube-apiserver не може працювати з кластерним DNS, оскільки це було б порушенням розшарування). host може також бути IP-адресою.

        Зверніть увагу, що використання localhost або 127.0.0.1 як host є ризикованим, якщо ви не вживаєте великих заходів обережності, щоб запустити цей вебхук на всіх хостах, що запускають сервер API, який може потребувати викликів до цього вебхука. Такі встановлення, ймовірно, будуть непереносимими, тобто їх буде важко розгорнути в новому кластері.

        Схема повинна бути "https"; URL повинен починатися з "https://".

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

        Спроба використання автентифікації користувача або базової автентифікації, наприклад, "user:password@", не дозволена. Також не дозволяються фрагменти ("#...") і параметри запиту ("?...").

    • webhooks.name (string), обовʼязково

      Імʼя вебхука допуску. Імʼя повинно бути повністю кваліфікованим, наприклад, imagepolicy.kubernetes.io, де "imagepolicy" — це імʼя вебхука, а kubernetes.io — це імʼя організації. Обовʼязково.

    • webhooks.sideEffects (string), обовʼязково

      SideEffects вказує, чи має цей вебхук побічні ефекти. Допустимі значення: None, NoneOnDryRun (вебхуки, створені у v1beta1, також можуть вказати Some або Unknown). Вебхуки з побічними ефектами МАЮТЬ реалізувати систему узгодження, оскільки запит може бути відхилено на наступному етапі ланцюжка допуску, і побічні ефекти потрібно буде скасувати. Запити з атрибутом dryRun автоматично відхиляються, якщо вони відповідають вебхуку з sideEffects == Unknown або Some.

    • webhooks.failurePolicy (string)

      FailurePolicy визначає, як обробляються нерозпізнані помилки від точки доступу допуску — дозволені значення: Ignore або Fail. Стандартне значення — Fail.

    • webhooks.matchConditions ([]MatchCondition)

      Patch strategy: обʼєднання за ключем name

      Map: під час обʼєднання будуть збережені унікальні значення за ключем name

    MatchConditions — це список умов, які мають бути виконані для надсилання запиту до цього вебхука. Умови відповідності фільтрують запити, які вже були підібрані за правилами, namespaceSelector і objectSelector. Порожній список matchConditions відповідає всім запитам. Максимальна кількість умов відповідності — 64.

    Логіка точного збігу така (за порядком): 1. Якщо БУДЬ-ЯКА умова відповідності оцінюється як FALSE, вебхук оминається. 2. Якщо ВСІ умови відповідності оцінюються як TRUE, вебхук викликається. 3. Якщо будь-яка умова відповідності оцінюється як помилка (але жодна не є FALSE): - Якщо failurePolicy=Fail, запит відхиляється - Якщо failurePolicy=Ignore, помилка ігнорується і вебхук оминається

    MatchCondition представляє умову, яка повинна бути виконана для надсилання запиту до вебхука.

    • webhooks.matchConditions.expression (string), обовʼязково

      Expression представляє вираз, який буде оцінено CEL. Результат обробки — bool. Вирази CEL мають доступ до вмісту AdmissionRequest і Authorizer, організованих у змінні CEL:

      'object' — Обʼєкт із вхідного запиту. Значення null для запитів DELETE. 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE. 'request' — Атрибути запиту допуску (/pkg/apis/admission/types.go#AdmissionRequest). 'authorizer' — CEL Authorizer. Може бути використано для виконання перевірок авторизації для виконавця (користувач або службового облікового запису) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' і налаштований із ресурсом запиту. Документація щодо CEL: https://kubernetes.io/docs/reference/using-api/cel/

      Обовʼязково.

    • webhooks.matchConditions.name (string), обовʼязково

      Name — це ідентифікатор цієї умови відповідності, використовується для стратегії злиття умов відповідності, а також для надання ідентифікатора для цілей логування. Хороша назва має бути описовою для повʼязаного виразу. Назва має бути кваліфікованою назвою, що складається з алфавітно-цифрових символів, '-', '' або '.', і має починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName' або 'my.name' або '123-abc', регулярний вираз, що використовується для перевірки, — '([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS субдомену та '/' (наприклад, 'example.com/MyName').

      Обовʼязково.

    • webhooks.matchPolicy (string)

      matchPolicy визначає, як використовується список "rules" для відповідності вхідним запитам. Допустимі значення — "Exact" або "Equivalent".

      • Exact: відповідність запиту тільки в тому випадку, якщо він точно відповідає зазначеному правилу. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надіслано до вебхука.

      • Equivalent: відповідність запиту, якщо він змінює ресурс, вказаний у правилах, навіть через іншу групу API або версію. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворений на apps/v1 і надісланий до вебхука.

      Стандартне значення — "Equivalent".

    • webhooks.namespaceSelector (LabelSelector)

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

      Наприклад, щоб запустити вебхук для будь-яких обʼєктів, чий простір імен не повʼязаний з "runlevel" 0 або 1, потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "runlevel",
      "operator": "NotIn",
      "values": [
        "0",
        "1"
      ]
    }
  ]
}

      Якщо замість цього ви хочете запустити вебхук для будь-яких обʼєктів, чий простір імен повʼязаний з "environment" "prod" або "staging", потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
  "matchExpressions": [
    {
      "key": "environment",
      "operator": "In",
      "values": [
        "prod",
        "staging"
      ]
    }
  ]
}

      Див. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

      Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.objectSelector (LabelSelector)

      ObjectSelector визначає, чи буде вебхук працювати з обʼєктом на основі того, чи має обʼєкт відповідні мітки. ObjectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані до вебхука, і вважається відповідним, якщо будь-який з обʼєктів відповідає селектору. Нульовий обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions обʼєкт), не вважається таким, що має збіг. Використовуйте objectSelector лише якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.rules ([]RuleWithOperations)

      Atomic: буде замінено під час злиття

      Rules описують, які операції з якими ресурсами/субресурсами цікавлять вебхук. Вебхук цікавить операція, якщо вона збігаєтьсяз БУДЬ-ЯКИМ правилом. Однак, щоб запобігти ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks від приведення кластера в стан, з якого не можна вийти без повного відключення втулка, ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks ніколи не викликаються для запитів на допуск для обʼєктів ValidatingWebhookConfiguration і MutatingWebhookConfiguration.

      RuleWithOperations — це кортеж операцій і ресурсів. Рекомендується переконатися, що всі розширення кортежу є дійсними.

      • webhooks.rules.apiGroups ([]string)

        Atomic: буде замінено під час обʼєднання

        APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.apiVersions ([]string)

        Atomic: буде замінено під час обʼєднання

        APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.operations ([]string)

        Atomic: буде замінено під час обʼєднання

        Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.resources ([]string)

        Atomic: буде замінено під час обʼєднання

        Resources — це список ресурсів, до яких застосовується це правило.

        Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

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

        Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

      • webhooks.rules.scope (string)

        scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*". "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • webhooks.timeoutSeconds (int32)

      TimeoutSeconds визначає тайм-аут для цього вебхука. Після закінчення тайм-ауту виклик вебхука буде проігноровано або виклик API завершиться невдачею залежно від політики відмови. Значення тайм-ауту має бути від 1 до 30 секунд. Стандартне значення — 10 секунд.

ValidatingWebhookConfigurationList

ValidatingWebhookConfigurationList — це список ValidatingWebhookConfiguration.

Операції

get отримати вказану ValidatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ValidatingWebhookConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingWebhookConfiguration): OK

401: Unauthorized

list перелік або перегляд обʼктів ValidatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations

Параметри

Відповідь

200 (ValidatingWebhookConfigurationList): OK

401: Unauthorized

create створення ValidatingWebhookConfiguration

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations

Параметри

Відповідь

200 (ValidatingWebhookConfiguration): OK

201 (ValidatingWebhookConfiguration): Created

202 (ValidatingWebhookConfiguration): Accepted

401: Unauthorized

update заміна вказаної ValidatingWebhookConfiguration

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

Відповідь

200 (ValidatingWebhookConfiguration): OK

201 (ValidatingWebhookConfiguration): Created

401: Unauthorized

patch часткове оновлення вказаної ValidatingWebhookConfiguration

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ValidatingWebhookConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingWebhookConfiguration): OK

201 (ValidatingWebhookConfiguration): Created

401: Unauthorized

delete видалення ValidatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ValidatingWebhookConfiguration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видаленя колекції ValidatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8 - Ресурси кластера

5.8.1 - APIService

APIService представляє сервер для певної GroupVersion.

apiVersion: apiregistration.k8s.io/v1

import "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1"

APIService

APIService представляє сервер для певної GroupVersion. Імʼя повинно бути "version.group".

APIServiceSpec

APIServiceSpec містить інформацію для пошуку та звʼязку з сервером. Підтримується лише https, хоча ви можете вимкнути перевірку сертифіката.

  • groupPriorityMinimum (int32), обовʼязково

    GroupPriorityMinimum — це мінімальний пріоритет, який має мати ця група. Вищий пріоритет означає, що група має перевагу для клієнтів над групами з нижчим пріоритетом. Зверніть увагу, що інші версії цієї групи можуть мати ще вищі значення GroupPriorityMinimum, що надає групі вищий пріоритет. Першочергове сортування базується на GroupPriorityMinimum, впорядкованому від найвищого до найнижчого (20 перед 10). Вторинне сортування базується на алфавітному порівнянні імені обʼєкта. (v1.bar перед v1.foo) Ми рекомендуємо щось на зразок: *.k8s.io (за винятком extensions) на 18000, а PaaS (OpenShift, Deis) рекомендується бути у 2000-х.

  • versionPriority (int32), обовʼязково

    VersionPriority контролює впорядкування цієї версії API всередині її групи. Повинно бути більше нуля. Першочергове сортування базується на VersionPriority, впорядкованому від найвищого до найнижчого (20 перед 10). Оскільки це всередині групи, число може бути маленьким, ймовірно, у 10-х. У випадку рівних пріоритетів версій, для визначення порядку всередині групи буде використовуватися рядок версії. Якщо рядок версії "kube-like", він буде сортуватися вище за рядки версій, які не є "kube-like", які впорядковуються лексикографічно. "Kube-like" версії починаються з "v", потім йде число (основна версія), потім за бажанням рядок "alpha" або "beta" і ще одне число (другорядна версія). Ці версії сортуються спочатку за принципом GA > beta > alpha (де GA — це версія без суфікса, такого як beta або alpha), а потім порівнюються основна версія, потім другорядна версія. Приклад відсортованого списку версій: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.

  • caBundle ([]byte)

    Atomic: буде замінено під час злиття

    CABundle — це PEM закодований набір сертифікатів CA, який буде використовуватися для перевірки сертифіката сервера API. Якщо не вказано, використовуються системні довірені корені на сервері API.

  • group (string)

    Group — це назва групи API, яку хостить цей сервер

  • insecureSkipTLSVerify (boolean)

    InsecureSkipTLSVerify вимикає перевірку сертифіката TLS при звʼязку з цим сервером. Це категорично не рекомендується. Вам слід використовувати CABundle замість цього.

  • service (ServiceReference)

    Service — це посилання на сервіс для цього сервера API. Воно повинно спілкуватись на порту 443. Якщо Service дорівнює nil, це означає, що обробка для версії API групи виконується локально на цьому сервері. Виклик просто делегується звичайному ланцюгу обробки для виконання.

    ServiceReference утримує посилання на Service.legacy.k8s.io

    • service.name (string)

      Name — це імʼя сервісу

    • service.namespace (string)

      Namespace — це простір імен сервісу

    • service.port (int32)

      Якщо вказано, порт сервісу, який хостить webhook. Стандартно — 443 для зворотної сумісності. port повинен бути допустимим номером порту (1-65535 включно).

  • version (string)

    Version — це версія API, яку хостить цей сервер. Наприклад, "v1"

APIServiceStatus

APIServiceStatus містить похідну інформацію про сервер API

  • conditions ([]APIServiceCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення за ключем type будуть збережені під час злиття

    Поточний стан сервісу apiService.

    APIServiceCondition описує стан APIService у певний момент часу

    • conditions.status (string), обовʼязково

      Status — це стан статусу. Може бути True, False, Unknown.

    • conditions.type (string), обовʼязково

      Type — це тип статусу.

    • conditions.lastTransitionTime (Time)

      Останній раз, коли стан статусу змінився з одного на інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, що вказує деталі про останню зміну статусу.

    • conditions.reason (string)

      Унікальна, однослівна, CamelCase причина останньої зміни статусу.

APIServiceList

APIServiceList — це список обʼєктів APIService.

Операції

get отримати вказаний APIService

HTTP запит

GET /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

401: Unauthorized

get отримати статус вказаного APIService

HTTP запит

GET /apis/apiregistration.k8s.io/v1/apiservices/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу APIService

HTTP запит

GET /apis/apiregistration.k8s.io/v1/apiservices

Параметри

Відповідь

200 (APIServiceList): OK

401: Unauthorized

create створення APIService

HTTP запит

POST /apis/apiregistration.k8s.io/v1/apiservices

Параметри

Відповідь

200 (APIService): OK

201 (APIService): Created

202 (APIService): Accepted

401: Unauthorized

update заміна вказаного APIService

HTTP запит

PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: APIService, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

update заміна статусу вказаного APIService

HTTP запит

PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: APIService, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

patch часткове оновлення вказаного APIService

HTTP запит

PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

patch чатскове оновлення статусу вказаного APIService

HTTP запит

PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

delete видаленя APIService

HTTP запит

DELETE /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видаленя колекції APIService

HTTP запит

DELETE /apis/apiregistration.k8s.io/v1/apiservices

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8.2 - ComponentStatus

ComponentStatus (і ComponentStatusList) містить інформацію про валідацію кластера.

apiVersion: v1

import "k8s.io/api/core/v1"

ComponentStatus

ComponentStatus (і ComponentStatusList) містить інформацію про валідацію кластера. Застаріло: Цей API застарів у версії v1.19+

  • apiVersion: v1

  • kind: ComponentStatus

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • conditions ([]ComponentCondition)

    Patch strategy: обʼєднання за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Список спостережуваних станів компонента

    Інформація про стан компонента.

    • conditions.status (string), обовʼязково

      Статус стану компонента. Допустимі значення для "Healthy": "True", "False" або "Unknown".

    • conditions.type (string), обовʼязково

      Тип стану компонента. Допустиме значення: "Healthy"

    • conditions.error (string)

      Код помилки стану компонента. Наприклад, код помилки перевірки справності.

    • conditions.message (string)

      Повідомлення про стан компонента. Наприклад, інформація про перевірку справності.

ComponentStatusList

Стан усіх умов для компонента у вигляді списку обʼєктів ComponentStatus. Застаріло: Цей API застарів у версії v1.19+

Операції

get отримання вказаного ComponentStatus

HTTP запит

GET /api/v1/componentstatuses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ComponentStatus

  • pretty (в запиті): string

    pretty

Відповідь

200 (ComponentStatus): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ComponentStatus

HTTP запит

GET /api/v1/componentstatuses

Параметри

Відповідь

200 (ComponentStatusList): OK

401: Unauthorized

5.8.3 - Event

Подія — це повідомлення про подію десь у кластері.

apiVersion: events.k8s.io/v1

import "k8s.io/api/events/v1"

Event

Event — це звіт про подію десь у кластері. Зазвичай це вказує на зміну стану в системі. Події мають обмежений термін зберігання, і тригери та повідомлення можуть змінюватися з часом. Споживачі подій не повинні покладатися на час події з певною причиною, що відображає послідовний тригер, або на продовження існування подій з цією причиною. До подій слід ставитися як до інформативних, можливо найкращих, додаткових даних.

  • apiVersion: events.k8s.io/v1

  • kind: Event

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • eventTime (MicroTime), обовʼязково

    eventTime — це час, коли подія вперше спостерігалась. Це обовʼязкове поле.

    MicroTime — це версія Time з мікросекундною точністю.

  • action (string)

    action — це дія, яка була виконана або яка не вдалася щодо відповідного обʼєкта. Це машинний код. Це поле не може бути порожнім для нових Подій і може містити не більше 128 символів.

  • deprecatedCount (int32)

    deprecatedCount — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

  • deprecatedFirstTimestamp (Time)

    deprecatedFirstTimestamp — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • deprecatedLastTimestamp (Time)

    deprecatedLastTimestamp — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • deprecatedSource (EventSource)

    deprecatedSource — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

    EventSource — містить інформацію для події.

    • deprecatedSource.component (string)

      Компонент, з якого була згенерована подія.

    • deprecatedSource.host (string)

      Імʼя вузла, на якому була згенерована подія.

  • note (string)

    note — опис статусу цієї операції, зрозумілий людині. Максимальна довжина примітки — 1 кБ, але бібліотеки повинні бути готові обробляти значення до 64 кБ.

  • reason (string)

    reason — це причина виконання дії. Це текст зрозумілий людині. Це поле не може бути порожнім для нових Подій і може містити не більше 128 символів.

  • regarding (ObjectReference)

    regarding — це обʼєкт, про який йдеться у цій Події. У більшості випадків це обʼєкт, який реалізує контролер звітів, наприклад, ReplicaSetController реалізує ReplicaSets, і ця подія випускається через те, що він діє на деякі зміни в обʼєкті ReplicaSet.

  • related (ObjectReference)

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

  • reportingController (string)

    reportingController — це імʼя контролера, який випустив цю Подію, наприклад, kubernetes.io/kubelet. Це поле не може бути порожнім для нових Подій.

  • reportingInstance (string)

    reportingInstance — це ідентифікатор інстанції контролера, наприклад, kubelet-xyzf. Це поле не може бути порожнім для нових Подій і може містити не більше 128 символів.

  • series (EventSeries)

    series — це дані про серію Подій, яку представляє ця подія, або nil, якщо це поодинока Подія.

    EventSeries — містить інформацію про серію подій, тобто процес, що триває певний час. Частота оновлення EventSeries залежить від звітування подій. Стандартний інструмент повідомлення про події в "k8s.io/client-go/tools/events/event_broadcaster.go" показує, як ця структура оновлюється на тактах та може керувати індивідуалізованими реалізаціями інструментів звітування.

    • series.count (int32), обовʼязково

      count — це кількість випадків у цій серії до останнього часу такту.

    • series.lastObservedTime (MicroTime), обовʼязково

      lastObservedTime — це час, коли останню Подію з серії було побачено перед останім тактом.

      MicroTime — це версія Time з мікросекундною точністю.

  • type (string)

    type — це тип цієї події (Normal, Warning), нові типи можуть бути додані у майбутньому. Це машинне кодування. Це поле не може бути порожнім для нових Подій.

EventList

EventList — це список обʼєктів подій.

Операції

get отримати вказаний Event

HTTP запит

GET /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Event

HTTP запит

GET /apis/events.k8s.io/v1/namespaces/{namespace}/events

Параметри

Відповідь

200 (EventList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Event

HTTP запит

GET /apis/events.k8s.io/v1/events

Параметри

Відповідь

200 (EventList): OK

401: Unauthorized

create створення Event

HTTP запит

POST /apis/events.k8s.io/v1/namespaces/{namespace}/events

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Event, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

201 (Event): Created

202 (Event): Accepted

401: Unauthorized

update заміна вказаного Event

HTTP запит

PUT /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Event, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

201 (Event): Created

401: Unauthorized

patch часткове оновлення вказаного Event

HTTP запит

PATCH /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

201 (Event): Created

401: Unauthorized

delete видалення Event

HTTP запит

DELETE /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Event

HTTP запит

DELETE /apis/events.k8s.io/v1/namespaces/{namespace}/events

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8.4 - IPAddress v1beta1

IP-адреса являє собою одну IP-адресу з одного сімейства IP-адрес.

apiVersion: networking.k8s.io/v1beta1

import "k8s.io/api/networking/v1beta1"

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

IPAddressSpec

IPAddressSpec описує атрибути IP-адреси.

  • parentRef (ParentReference), обовʼязково

    ParentRef посилається на ресурс, до якого приєднана IPAddress. IPAddress повинна мати посилання на батьківський обʼєкт.

    ParentReference описує посилання на батьківський обʼєкт.

    • parentRef.name (string)

      Імʼя є іменем обʼєкта, на який посилаються.

    • parentRef.resource (string)

      Ресурс є ресурсом обʼєкта, на який посилаються.

    • parentRef.group (string)

      Група є групою обʼєкта, на який посилаються.

    • parentRef.namespace (string)

      Простір імен є простором імен обʼєкта, на який посилаються.

IPAddressList

IPAddressList містить список IPAddress.

Операції

get отримати вказану IPAddress

HTTP запит

GET /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IPAddress

  • pretty (в запиті): string

    pretty

Відповідь

200 (IPAddress): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу IPAddress

HTTP запит

GET /apis/networking.k8s.io/v1beta1/ipaddresses

Параметри

Відповідь

200 (IPAddressList): OK

401: Unauthorized

create створення IPAddress

HTTP запит

POST /apis/networking.k8s.io/v1beta1/ipaddresses

Параметри

Відповідь

200 (IPAddress): OK

201 (IPAddress): Created

202 (IPAddress): Accepted

401: Unauthorized

update заміна вказаної IPAddress

HTTP запит

PUT /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IPAddress

  • body: IPAddress, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (IPAddress): OK

201 (IPAddress): Created

401: Unauthorized

patch часткове оновлення вказаної IPAddress

HTTP запит

PATCH /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IPAddress

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (IPAddress): OK

201 (IPAddress): Created

401: Unauthorized

delete видалення IPAddress

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції IPAddress

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/ipaddresses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8.5 - Lease

Lease визначає концепцію оренди.

apiVersion: coordination.k8s.io/v1

import "k8s.io/api/coordination/v1"

Lease

Lease визначає концепцію оренди.

LeaseSpec

LeaseSpec — це специфікація оренди.

  • acquireTime (MicroTime)

    acquireTime — це час, коли поточну оренду було отримано.

    MicroTime — це версія Time з точністю до мікросекунд.

  • holderIdentity (string)

    holderIdentity містить ідентифікатор власника поточної оренди. Якщо використовується координований вибір лідера, ідентифікатор власника повинен відповідати значенню поля LeaseCandidate.metadata.name, яке було обране.

  • leaseDurationSeconds (int32)

    leaseDurationSeconds — це тривалість, яку кандидати на оренду повинні чекати, щоб примусово її отримати. Вона вимірюється від часу останнього спостережуваного renewTime.

  • leaseTransitions (int32)

    leaseTransitions — це кількість переходів оренди між власниками.

  • preferredHolder (string)

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

  • renewTime (MicroTime)

    renewTime — це час, коли поточний власник оренди останнього разу оновив оренду.

    MicroTime — це версія Time з точністю до мікросекунд.

  • strategy (string)

    Strategy вказує стратегію для вибору лідера в координованому виборі лідера. Якщо це поле не вказано, координування для цього лізингу не активне. (Альфа) Для використання цього поля потрібно увімкнути функціональну можливість CoordinatedLeaderElection.

LeaseList

LeaseList — це список обʼєктів Lease.

Операції

get отримати вказаний Lease

HTTP запит

GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Lease

HTTP запит

GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases

Параметри

Відповідь

200 (LeaseList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Lease

HTTP запит

GET /apis/coordination.k8s.io/v1/leases

Параметри

Відповідь

200 (LeaseList): OK

401: Unauthorized

create створення Lease

HTTP запит

POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Lease, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

201 (Lease): Created

202 (Lease): Accepted

401: Unauthorized

update заміна вказаного Lease

HTTP запит

PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Lease, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

201 (Lease): Created

401: Unauthorized

patch часткове оновлення вказаного Lease

HTTP запит

PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

201 (Lease): Created

401: Unauthorized

delete видалення Lease

HTTP запит

DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Lease

HTTP запит

DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8.6 - LeaseCandidate v1alpha1

LeaseCandidate визначає кандидата для об'єкта Lease.

apiVersion: coordination.k8s.io/v1alpha1

import "k8s.io/api/coordination/v1alpha1"

LeaseCandidate

LeaseCandidate визначає кандидата для обʼєкта Lease. Кандидати створюються таким чином, щоб координований вибір лідера вибрав найкращого лідера з переліку кандидатів.

LeaseCandidateSpec

LeaseCandidateSpec є специфікацією Lease.

  • leaseName (string), обовʼязково

    LeaseName — це імʼя Lease, за який цей кандидат змагається. Це поле є незмінним.

  • preferredStrategies ([]string), обовʼязково

    Atomic: буде замінено під час злиття

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

    • Якщо всі клієнти мають стратегію X як перший елемент у цьому списку, буде використана стратегія X.
    • Якщо кандидат має стратегію [X], а інший кандидат має стратегію [Y, X], Y переважає X, і буде використана стратегія Y.
    • Якщо кандидат має стратегію [X, Y], а інший кандидат має стратегію [Y, X], це є помилкою користувача, і вибір лідера не буде здійснюватися до вирішення проблеми.

    (Альфа) Для використання цього поля потрібно увімкнути функціональну можливість CoordinatedLeaderElection.

  • binaryVersion (string)

    BinaryVersion — це бінарна версія. Вона повинна бути у форматі semver без початкової v. Це поле є обовʼязковим, коли стратегія "OldestEmulationVersion".

  • emulationVersion (string)

    EmulationVersion —це версія емуляції. Вона повинна бути у форматі semver без початкової v. EmulationVersion повинна бути менше або дорівнювати BinaryVersion. Це поле є обовʼязковим, коли стратегія є "OldestEmulationVersion".

  • pingTime (MicroTime)

    PingTime — це останній час, коли сервер запитував LeaseCandidate на продовження. Це виконується лише під час вибору лідера, щоб перевірити, чи стали якісь LeaseCandidates недійсними. Коли PingTime оновлюється, LeaseCandidate відповідає, оновлюючи RenewTime.

    MicroTime — це версія Time з точністю до мікросекунд.

  • renewTime (MicroTime)

    RenewTime — це час, коли LeaseCandidate був востаннє оновлений. Щоразу, коли Lease потребує вибору лідера, поле PingTime оновлюється, щоб сигналізувати LeaseCandidate про необхідність оновлення RenewTime. Старі обʼєкти LeaseCandidate також видаляються, якщо пройшло кілька годин з моменту останнього оновлення. Поле PingTime регулярно оновлюється, щоб запобігти видаленню ще активних LeaseCandidates.

    MicroTime — це версія Time з точністю до мікросекунд.

LeaseCandidateList

LeaseCandidateList — перелік обʼєктів Lease.

Operations

get отримати вказаного LeaseCandidate

HTTP запит

GET /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (LeaseCandidate): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LeaseCandidate

HTTP запит

GET /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates

Параметри

Відповідь

200 (LeaseCandidateList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LeaseCandidate

HTTP запит

GET /apis/coordination.k8s.io/v1alpha1/leasecandidates

Параметри

Відповідь

200 (LeaseCandidateList): OK

401: Unauthorized

create створення LeaseCandidate

HTTP запит

POST /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates

Параметри

Відповідь

200 (LeaseCandidate): OK

201 (LeaseCandidate): Created

202 (LeaseCandidate): Accepted

401: Unauthorized

update заміна вказаного LeaseCandidate

HTTP запит

PUT /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: LeaseCandidate, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (LeaseCandidate): OK

201 (LeaseCandidate): Created

401: Unauthorized

patch часткове оновлення вказаного LeaseCandidate

HTTP запит

PATCH /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (LeaseCandidate): OK

201 (LeaseCandidate): Created

401: Unauthorized

delete видалення LeaseCandidate

HTTP запит

DELETE /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції LeaseCandidate

HTTP запит

DELETE /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8.7 - Namespace

Простір імен надає область видимості для імен.

apiVersion: v1

import "k8s.io/api/core/v1"

Namespace

Namespace надає область видимості для імен. Використання кількох просторів імен є необовʼязковим.

NamespaceSpec

NamespaceSpec описує атрибути простору імен.

  • finalizers ([]string)

    Atomic: буде замінено під час злиття

    Finalizers є непрозорим списком значень, які повинні бути порожніми щоб назавжди видалити обʼєкт з сховища. Докладніше: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

NamespaceStatus

NamespaceStatus — це інформація про поточний статус простору імен.

  • conditions ([]NamespaceCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Представляє останні доступні спостереження поточного стану простору імен.

    NamespaceCondition містить деталі про стан контролера просторів імен.

    • conditions.status (string), обовʼязково

      Статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану контролера просторів імен.

    • conditions.lastTransitionTime (Time)

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

    • conditions.reason (string)

  • phase (string)

    Phase — це поточна фаза життєвого циклу простору імен. Докладніше: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

NamespaceList

NamespaceList — це список просторів імен.

Операції

get отримати вказаний Namespace

HTTP запит

GET /api/v1/namespaces/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

401: Unauthorized

get отримати статус вказаного Namespace

HTTP запит

GET /api/v1/namespaces/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Namespace

HTTP запит

GET /api/v1/namespaces

Параметри

Відповідь

200 (NamespaceList): OK

401: Unauthorized

create створення Namespace

HTTP запит

POST /api/v1/namespaces

Параметри

Відповідь

200 (Namespace): OK

201 (Namespace): Created

202 (Namespace): Accepted

401: Unauthorized

update заміна вказаного Namespace

HTTP запит

PUT /api/v1/namespaces/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Namespace, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

update заміна, завершення вказаного Namespace

HTTP запит

PUT /api/v1/namespaces/{name}/finalize

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Namespace, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

update заміна статусу вказаного Namespace

HTTP запит

PUT /api/v1/namespaces/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Namespace, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

patch часткове оновлення вказаного Namespace

HTTP запит

PATCH /api/v1/namespaces/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Namespace

HTTP запит

PATCH /api/v1/namespaces/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

delete видалення Namespace

HTTP запит

DELETE /api/v1/namespaces/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

5.8.8 - Node

Node — робочий вузол в Kubernetes.

apiVersion: v1

import "k8s.io/api/core/v1"

Node

Node є робочим вузлом в Kubernetes. Кожен вузол буде мати унікальний ідентифікатор у кеші (тобто в etcd).

NodeSpec

NodeSpec описує атрибути, з якими створюється вузол.

  • configSource (NodeConfigSource)

    Застаріло: Раніше використовувалося для вказівки джерела конфігурації вузла для функції DynamicKubeletConfig. Цю функцію вилучено.

    NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих) має бути не нульовим. Цей API є застарілим з версії 1.22

    • configSource.configMap (ConfigMapNodeConfigSource)

      ConfigMap є посиланням на ConfigMap вузла.

      ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

      • configSource.configMap.kubeletConfigKey (string), обовʼязково

        KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

      • configSource.configMap.name (string), обовʼязково

        Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

      • configSource.configMap.namespace (string), обовʼязково

        Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

      • configSource.configMap.resourceVersion (string)

        ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

      • configSource.configMap.uid (string)

        UID є metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязково в Node.Status.

  • externalID (string)

    Застаріло. Не всі kubelets встановлюватимуть це поле. Видаліть поле після версії 1.13. див.: https://issues.k8s.io/61966

  • podCIDR (string)

    PodCIDR представляє діапазон IP-адрес Podʼів, призначених вузлу.

  • podCIDRs ([]string)

    Set: унікальні значення будуть збережені під час злиття

    podCIDRs представляє діапазони IP-адрес, призначених вузлу для використання Podʼами на цьому вузлі. Якщо це поле вказане, перший запис повинен відповідати полю podCIDR. Воно може містити не більше одного значення для кожного з IPv4 та IPv6.

  • providerID (string)

    Ідентифікатор вузла, призначений постачальником хмарних послуг у форматі: <ProviderName>://<ProviderSpecificNodeID>

  • taints ([]Taint)

    Atomic: буде замінено під час злиття

    Якщо вказано, задає taints вузла.

    Вузол, до якого прив’язано цей Taint, має "ефект" на будь-який Pod, який не толерує Taint.

    • taints.effect (string), обовʼязково

      Обовʼязково. Ефект taint на Podʼи, які не толерують taint. Допустимі ефекти: NoSchedule, PreferNoSchedule і NoExecute.

    • taints.key (string), обовʼязково

      Обовʼязково. Ключ taint, який буде застосовано до вузла.

    • taints.timeAdded (Time)

      TimeAdded представляє час, коли taint було додано. Записується тільки для taint NoExecute.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • taints.value (string)

      Значення taint, що відповідає ключу taint.

  • unschedulable (boolean)

    Unschedulable контролює можливість планування нових Podʼів на вузлі. Стандартно вузол є доступним для планування. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#manual-node-administration

NodeStatus

NodeStatus — це інформація про поточний статус вузла.

  • addresses ([]NodeAddress)

    Patch strategy: merge on key type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Список адрес, доступних вузлу. Запитується у постачальника хмарних послуг, якщо доступно. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#addresses Примітка: Це поле визначено як доступне для злиття, але ключ злиття не є достатньо унікальним, що може призвести до пошкодження даних при злитті. Абоненти повинні використовувати патч для повної заміни. Див. приклад на https://pr.k8s.io/79391. Споживачі повинні припускати, що адреси можуть змінюватися протягом усього життя вузла. Однак є деякі винятки, коли це може бути неможливо, наприклад, Podʼи, які наслідують адресу вузла у своєму статусі, або споживачі API (status.hostIP).

    NodeAddress містить інформацію про адресу вузла.

    • addresses.address (string), обовʼязково

      Адреса вузла.

    • addresses.type (string), обовʼязково

      Тип адреси вузла, один із Hostname, ExternalIP або InternalIP.

  • allocatable (map[string]Quantity)

    Allocatable представляє ресурси вузла, доступні для планування. Стандартне значення — Capacity.

  • capacity (map[string]Quantity)

    Capacity представляє загальні ресурси вузла. Докладніше: https://kubernetes.io/docs/reference/node/node-status/#capacity

  • conditions ([]NodeCondition)

    Patch strategy: merge on key type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Conditions — це масив поточних спостережуваних станів вузла. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#condition

    NodeCondition містить інформацію про стан вузла.

    • conditions.status (string), обовʼязково

      Статус стану, один із True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану вузла.

    • conditions.lastHeartbeatTime (Time)

      Останній час отримання оновлення про певний стан.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastTransitionTime (Time)

      Останній час переходу стану від одного статусу до іншого.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, що вказує на деталі останнього переходу.

    • conditions.reason (string)

      (коротко) причина останнього переходу стану.

  • config (NodeConfigStatus)

    Статус конфігурації, призначеної вузлу через функцію динамічної конфігурації Kubelet.

    NodeConfigStatus описує статус конфігурації, призначеної Node.Spec.ConfigSource.

    • config.active (NodeConfigSource)

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

      NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих), має бути не нульовим. Цей API є застарілим з версії 1.22

      • config.active.configMap (ConfigMapNodeConfigSource)

        ConfigMap є посиланням на ConfigMap вузла.

        ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

        • config.active.configMap.kubeletConfigKey (string), обовʼязково

          KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

        • config.active.configMap.name (string), обовʼязково

          Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.active.configMap.namespace (string), обовʼязково

          Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.active.configMap.resourceVersion (string)

          ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

        • config.active.configMap.uid (string)

          UID — metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

    • config.assigned (NodeConfigSource)

      Assigned повідомляє про контрольовану конфігурацію, яку вузол спробує використовувати. Коли Node.Spec.ConfigSource оновлюється, вузол зберігає асоційоване конфігураційне навантаження на локальний диск разом із записом, що вказує на призначену конфігурацію. Вузол звертається до цього запису, щоб вибрати свою контрольовану конфігурацію, і повідомляє про цей запис в Assigned. Assigned оновлюється в статусі лише після того, як запис збережено на диск. Коли Kubelet перезавантажується, він намагається зробити призначену конфігурацію активною конфігурацією, завантажуючи та перевіряючи контрольоване навантаження, ідентифіковане Assigned.

      NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих), має бути не нульовим. Цей API є застарілим з версії 1.22

      • config.assigned.configMap (ConfigMapNodeConfigSource)

        ConfigMap є посиланням на ConfigMap вузла

        ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

        • config.assigned.configMap.kubeletConfigKey (string), обовʼязково

          KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

        • config.assigned.configMap.name (string), обовʼязково

          Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.assigned.configMap.namespace (string), обовʼязково

          Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.assigned.configMap.resourceVersion (string)

          ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

        • config.assigned.configMap.uid (string)

          UID — metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

    • config.error (string)

      Error описує будь-які проблеми під час узгодження Spec.ConfigSource з Active конфігурацією. Помилки можуть виникати, наприклад, при спробі зберегти Spec.ConfigSource у локальний запис Assigned, при спробі зберегти повʼязане конфігураційне навантаження, при спробі завантажити або перевірити Assigned конфігурацію тощо. Помилки можуть виникати на різних етапах синхронізації конфігурації. Ранні помилки (наприклад, помилки завантаження або збереження) не призведуть до повернення до LastKnownGood і можуть бути виправлені під час повторних спроб Kubelet. Пізні помилки (наприклад, помилки завантаження або перевірки збереженої конфігурації) призведуть до повернення до LastKnownGood. У останньому випадку зазвичай можна вирішити помилку, виправивши конфігурацію, призначену в Spec.ConfigSource. Додаткову інформацію для налагодження можна знайти, шукаючи повідомлення про помилку в лозі Kubelet. Error є описом стану помилки, зрозумілим людині; машини можуть перевірити, чи порожній Error, але не повинні покладатися на стабільність тексту Error у різних версіях Kubelet.

    • config.lastKnownGood (NodeConfigSource)

      LastKnownGood повідомляє про контрольовану конфігурацію, до якої вузол повернеться при виникненні помилки під час спроби використати Assigned конфігурацію. Assigned конфігурація стає LastKnownGood, коли вузол визначає, що Assigned конфігурація стабільна і правильна. Це наразі реалізовано як 10-хвилинний період перевірки, що починається, коли локальний запис Assigned конфігурації оновлюється. Якщо Assigned конфігурація є Active наприкінці цього періоду, вона стає LastKnownGood. Зазначте, що якщо Spec.ConfigSource скидається до nil (використовуйте стандартні локальні налаштування), LastKnownGood також негайно скидається до nil, оскільки локальна стандартна конфігурація завжди вважається правильною. Ви не повинні робити припущення про метод вузла щодо визначення стабільності та правильності конфігурації, оскільки це може змінюватися або ставати налаштовуваним у майбутньому.

      NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих), має бути не нульовим. Цей API є застарілим з версії 1.22

      • config.lastKnownGood.configMap (ConfigMapNodeConfigSource)

        ConfigMap є посиланням на ConfigMap вузла.

        ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

        • config.lastKnownGood.configMap.kubeletConfigKey (string), обовʼязково

          KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

        • config.lastKnownGood.configMap.name (string), обовʼязково

          Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.lastKnownGood.configMap.namespace (string), обовʼязково

          Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.lastKnownGood.configMap.resourceVersion (string)

          ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

        • config.lastKnownGood.configMap.uid (string)

          UID — metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

  • daemonEndpoints (NodeDaemonEndpoints)

    Endpoints демонів, що працюють на вузлі.

    NodeDaemonEndpoints містить порти, відкриті демонами, що працюють на вузлі.

    • daemonEndpoints.kubeletEndpoint (DaemonEndpoint)

      Endpoint, на якому слухає Kubelet.

      DaemonEndpoint містить інформацію про один Endpoint демона.

      • daemonEndpoints.kubeletEndpoint.Port (int32), обовʼязково

        Номер порту даного Endpoint.

  • features (NodeFeatures)

    Features описує набір функцій, реалізованих реалізацією CRI.

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

    • features.supplementalGroupsPolicy (boolean)

      SupplementalGroupsPolicy встановлюється в true, якщо середовище виконання підтримує SupplementalGroupsPolicy та ContainerUser.

  • images ([]ContainerImage)

    Atomic: буде замінено під час злиття

    Список контейнерних образів на цьому вузлі.

    Опис контейнерного образу

    • images.names ([]string)

      Atomic: буде замінено під час злиття

      Імена, відомі для образу. Наприклад, ["kubernetes.example/hyperkube:v1.0.7", "cloud-vendor.registry.example/cloud-vendor/hyperkube:v1.0.7"]

    • images.sizeBytes (int64)

      Розмір образу у байтах.

  • nodeInfo (NodeSystemInfo)

    Набір id/uuid для унікальної ідентифікації вузла. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#info

    NodeSystemInfo є набором id/uuid для унікальної ідентифікації вузла.

    • nodeInfo.architecture (string), обовʼязково

      Архітектура, повідомлена вузлом.

    • nodeInfo.bootID (string), обовʼязково

      Boot ID, повідомлений вузлом.

    • nodeInfo.containerRuntimeVersion (string), обовʼязково

      Версія контейнерного середовища, повідомлена вузлом через віддалений API середовища (наприклад, containerd://1.4.2).

    • nodeInfo.kernelVersion (string), обовʼязково

      Версія ядра, повідомлена вузлом з 'uname -r' (наприклад, 3.16.0-0.bpo.4-amd64).

    • nodeInfo.kubeProxyVersion (string), обовʼязково

      Застаріле: Версія KubeProxy, повідомлена вузлом.

    • nodeInfo.kubeletVersion (string), обовʼязково

      Версія Kubelet, повідомлена вузлом.

    • nodeInfo.machineID (string), обовʼязково

      MachineID, повідомлений вузлом. Для унікальної ідентифікації машини в кластері це поле є переважним. Докладніше у man(5) machine-id: http://man7.org/linux/man-pages/man5/machine-id.5.html

    • nodeInfo.operatingSystem (string), обовʼязково

      Операційна система, повідомлена вузлом.

    • nodeInfo.osImage (string), обовʼязково

      Образ ОС, повідомлений вузлом з /etc/os-release (наприклад, Debian GNU/Linux 7 (wheezy)).

    • nodeInfo.systemUUID (string), обовʼязково

      SystemUUID, повідомлений вузлом. Для унікальної ідентифікації машини переважним є MachineID. Це поле специфічне для хостів Red Hat https://access.redhat.com/documentation/en-us/red_hat_subscription_management/1/html/rhsm/uuid

  • phase (string)

    NodePhase є недавно спостережуваною фазою життєвого циклу вузла. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#phase. Поле ніколи не заповнюється і тепер є застарілим.

  • runtimeHandlers ([]NodeRuntimeHandler)

    Atomic: буде замінено під час злиття

    Доступні обробники середовища виконання.

    NodeRuntimeHandler — це набір інформації про обробники середовища виконання.

    • runtimeHandlers.features (NodeRuntimeHandlerFeatures)

      Підтримувані функції.

      NodeRuntimeHandlerFeatures — це набір функцій, реалізованих обробником середовища виконання.

      • runtimeHandlers.features.recursiveReadOnlyMounts (boolean)

        RecursiveReadOnlyMounts встановлюється в true, якщо обробник середовища виконання підтримує RecursiveReadOnlyMounts.

      • runtimeHandlers.features.userNamespaces (boolean)

        UserNamespaces встановлюється в true, якщо обробник середовища виконання підтримує UserNamespaces, включаючи підтримку для томів.

    • runtimeHandlers.name (string)

      Назва обробника середовища виконання. Порожнє для стандартного обробника середовища виконання.

  • volumesAttached ([]AttachedVolume)

    Atomic: буде замінено під час злиття

    Список томів, підключених до вузла.

    AttachedVolume описує том, підключений до вузла

    • volumesAttached.devicePath (string), обовʼязково

      DevicePath представляє шлях пристрою, де том має бути доступний.

    • volumesAttached.name (string), обовʼязково

      Імʼя підключеного тому.

  • volumesInUse ([]string)

    Atomic: буде замінено під час злиття

    Список підключених томів, що використовуються (змонтовані) вузлом.

NodeList

NodeList є повним списком усіх вузлів, які зареєстровані у панелі управління.

Операції

get отримати вказаний Node

HTTP запит

GET /api/v1/nodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

401: Unauthorized

get отримати статус вказаного Node

HTTP запит

GET /api/v1/nodes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Node

HTTP запит

GET /api/v1/nodes

Параметри

Відповідь

200 (NodeList): OK

401: Unauthorized

create створення Node

HTTP запит

POST /api/v1/nodes

Параметри

  • body: Node, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

202 (Node): Accepted

401: Unauthorized

update заміна вказаного Node

HTTP запит

PUT /api/v1/nodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Node, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

update заміна статусу вказаного Node

HTTP запит

PUT /api/v1/nodes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Node, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

patch часткове оновлення вказаного Node

HTTP запит

PATCH /api/v1/nodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Node

HTTP запит

PATCH /api/v1/nodes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

delete видалення Node

HTTP запит

DELETE /api/v1/nodes/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Node

HTTP запит

DELETE /api/v1/nodes

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8.9 - RuntimeClass

RuntimeClass визначає клас середовища виконання контейнерів, підтримуваних у кластері.

apiVersion: node.k8s.io/v1

import "k8s.io/api/node/v1"

RuntimeClass

RuntimeClass визначає клас середовища виконання контейнерів, підтримуваних у кластері. RuntimeClass використовується для визначення, яке середовище виконання контейнерів використовується для запуску всіх контейнерів у Podʼі. RuntimeClass визначаються вручну користувачем або провайдером кластера і посилаються в PodSpec. Kubelet відповідає за розвʼязання посилання RuntimeClassName перед запуском Podʼа. Для отримання додаткової інформації дивіться: https://kubernetes.io/docs/concepts/containers/runtime-class/

  • apiVersion: node.k8s.io/v1

  • kind: RuntimeClass

  • metadata (ObjectMeta)

    Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • handler (string), обовʼязково

    handler визначає базове середовище виконання та конфігурацію, яку реалізація CRI буде використовувати для обробки Podʼів цього класу. Можливі значення специфічні для конфігурації вузла та CRI. Припускається, що всі обробники доступні на кожному вузлі, і обробники з однаковими назвами еквівалентні на кожному вузлі. Наприклад, обробник з назвою "runc" може вказувати, що для запуску контейнерів у Podʼі буде використовуватися середовище виконання runc OCI (з використанням нативних Linux контейнерів). Handler повинен бути у нижньому регістрі, відповідати вимогам мітки DNS (RFC 1123) і бути незмінним.

  • overhead (Overhead)

    overhead представляє накладні витрати ресурсів, повʼязані з запуском Podʼа для даного RuntimeClass. Для отримання додаткової інформації дивіться https://kubernetes.io/docs/concepts/scheduling-eviction/pod-overhead/

    Структура Overhead представляє накладні витрати ресурсів, повʼязані з запуском Podʼа.

    • overhead.podFixed (map[string]Quantity)

      podFixed представляє фіксовані накладні витрати ресурсів, повʼязані з запуском Podʼа.

  • scheduling (Scheduling)

    scheduling містить обмеження планування, щоб забезпечити розміщення Podʼів, які працюють з цим RuntimeClass, на вузлах, які його підтримують. Якщо scheduling дорівнює nil, передбачається, що цей RuntimeClass підтримується всіма вузлами.

    Scheduling визначає обмеження планування для вузлів, які підтримують RuntimeClass.

    • scheduling.nodeSelector (map[string]string)

      nodeSelector перераховує мітки, які повинні бути присутніми на вузлах, що підтримують цей RuntimeClass. Podʼи, що використовують цей RuntimeClass, можуть бути розміщені тільки на вузлах, що відповідають цьому селектору. Селектор вузла RuntimeClass обʼєднується з наявним селектором вузла Podʼа. Будь-які конфлікти призведуть до відхилення Podʼа на етапі допуску.

    • scheduling.tolerations ([]Toleration)

      Atomic: буде замінено під час злиття

      tolerations додаються (за винятком дублікатів) до Podʼів, що працюють з цим RuntimeClass під час допуску, ефективно обʼєднуючи набір вузлів, які Pod та RuntimeClass можуть толерувати.

      Pod, до якого привʼязаний цей Toleration, толерує будь-який taint, що відповідає трійці <key,value,effect> за допомогою оператора порівняння .

      • scheduling.tolerations.key (string)

        Key — це ключ taint, до якого застосовується toleration. Порожній ключ означає відповідність всім ключам taint. Якщо ключ порожній, оператор повинен бути Exists; ця комбінація означає відповідність усім значенням та всім ключам.

      • scheduling.tolerations.operator (string)

        Operator представляє відношення ключа до значення. Допустимі оператори: Exists і Equal. Стандартне значення — Equal. Exists еквівалентно шаблону для значення, так що Pod може толерувати всі taints певної категорії.

      • scheduling.tolerations.value (string)

        Value — це значення taint, з яким збігається toleration. Якщо оператор Exists, значення повинно бути порожнім, інакше — це просто звичайний рядок.

      • scheduling.tolerations.effect (string)

        Effect вказує ефект taint для порівняння. Порожній означає відповідність всім ефектам taint. Якщо вказано, допустимі значення — NoSchedule, PreferNoSchedule та NoExecute.

      • scheduling.tolerations.tolerationSeconds (int64)

        TolerationSeconds представляє період часу, протягом якого toleration (який повинен мати ефект NoExecute, інакше це поле ігнорується) толерує taint. Стандартне значення — не встановлено, що означає толерування taint назавжди (не виселяти). Нульові та відʼємні значення будуть розглядатися системою як 0 (негайне виселення).

RuntimeClassList

RuntimeClassList — це список обʼєктів RuntimeClass.

Операції

get отримати вказаний RuntimeClass

HTTP запит

GET /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RuntimeClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (RuntimeClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу RuntimeClass

HTTP запит

GET /apis/node.k8s.io/v1/runtimeclasses

Параметри

Відповідь

200 (RuntimeClassList): OK

401: Unauthorized

create створення RuntimeClass

HTTP запит

POST /apis/node.k8s.io/v1/runtimeclasses

Параметри

Відповідь

200 (RuntimeClass): OK

201 (RuntimeClass): Created

202 (RuntimeClass): Accepted

401: Unauthorized

update заміна вказаного RuntimeClass

HTTP запит

PUT /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RuntimeClass

  • body: RuntimeClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (RuntimeClass): OK

201 (RuntimeClass): Created

401: Unauthorized

patch часткове оновлення вказаного RuntimeClass

HTTP запит

PATCH /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RuntimeClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (RuntimeClass): OK

201 (RuntimeClass): Created

401: Unauthorized

delete видалення RuntimeClass

HTTP запит

DELETE /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції RuntimeClass

HTTP запит

DELETE /apis/node.k8s.io/v1/runtimeclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.8.10 - ServiceCIDR v1beta1

ServiceCIDR визначає діапазон IP-адрес у форматі CIDR (наприклад, 192.168.0.0/24 або 2001:db2::/64).

apiVersion: networking.k8s.io/v1beta1

import "k8s.io/api/networking/v1beta1"

ServiceCIDR

ServiceCIDR визначає діапазон IP-адрес у форматі CIDR (наприклад, 192.168.0.0/24 або 2001:db2::/64). Цей діапазон використовується для виділення ClusterIP для обʼєктів Service.

ServiceCIDRSpec

ServiceCIDRSpec визначає CIDR, які користувач хоче використовувати для виділення ClusterIP для Services.

  • cidrs ([]string)

    Atomic: буде замінено під час злиття

    CIDRs визначає IP-блоки у нотації CIDR (наприклад, "192.168.0.0/24" або "2001:db8::/64"), з яких призначаються IP-адреси для сервісів кластера. Дозволено не більше двох CIDR, по одному для кожного сімейства IP. Це поле є незмінним.

ServiceCIDRStatus

ServiceCIDRStatus описує поточний стан ServiceCIDR.

  • conditions ([]Condition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    conditions містить масив metav1.Condition, який описує стан ServiceCIDR. Поточний стан сервісу.

    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, стан застарів щодо поточного стану екземпляра.

ServiceCIDRList

ServiceCIDRList містить список об'єктів ServiceCIDR.

Операції

get Отримати вказаний ServiceCIDR

HTTP запит

GET /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

401: Unauthorized

get отримати статус вказаного ServiceCIDR

HTTP запит

GET /apis/networking.k8s.io/v1beta1/servicecidrs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ServiceCIDR

HTTP запит

GET /apis/networking.k8s.io/v1beta1/servicecidrs

Параметри

Відповідь

200 (ServiceCIDRList): OK

401: Unauthorized

create створення ServiceCIDR

HTTP запит

POST /apis/networking.k8s.io/v1beta1/servicecidrs

Параметри

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

202 (ServiceCIDR): Accepted

401: Unauthorized

update заміна вказаного ServiceCIDR

HTTP запит

PUT /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: ServiceCIDR, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

update заміна статусу вказаного ServiceCIDR

HTTP запит

PUT /apis/networking.k8s.io/v1beta1/servicecidrs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: ServiceCIDR, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

patch часткове оновлення вказаного ServiceCIDR

HTTP запит

PATCH /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ServiceCIDR

HTTP запит

PATCH /apis/networking.k8s.io/v1beta1/servicecidrs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

delete видалення ServiceCIDR

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ServiceCIDR

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/servicecidrs

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

5.9 - Загальні визначення

5.9.1 - DeleteOptions

DeleteOptions можуть бути надані при видаленні обʼєкта API.

import "k8s.io/apimachinery/pkg/apis/meta/v1"

DeleteOptions можуть бути надані при видаленні обʼєкта API.

  • apiVersion (string)

    APIVersion визначає версійовану схему цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення, і можуть відхилити невизнані значення. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  • dryRun ([]string)

    Atomic: буде замінено під час злиття

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

  • gracePeriodSeconds (int64)

    Тривалість в секундах до видалення обʼєкта. Значення повинно бути не відʼємним цілим числом. Значення нуль означає видалення без затримки. Якщо це значення є nil, буде використовуватися стандартне значення для вказаних типів. Стандартно буде використовуватися значення для обʼєкта, якщо не вказано. Нуль означає видалення без затримки.

  • kind (string)

    Kind — це рядкове значення, що представляє ресурс REST, який представляє цей обʼєкт. Сервери можуть отримати це з точки доступу, на яку клієнт надсилає запити. Не може бути оновлено. У форматі CamelCase. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • orphanDependents (boolean)

    Застаріле: будь ласка, використовуйте 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)

    Atomic: буде замінено під час злиття

    matchExpressions — це список вимог селектора міток. Вимоги зʼєднуються логічною операцією І (AND).

    Вимоги селектора міток — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.

    • matchExpressions.key (string), обовʼязково

      key — це ключ мітки, до якого застосовується селектор.

    • matchExpressions.operator (string), обовʼязково

      operator представляє стосунок ключа до набору значень. Допустимі оператори: In, NotIn, Exists та DoesNotExist.

    • matchExpressions.values ([]string)

      Atomic: буде замінено під час злиття

      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.

  • resourceVersion (string)

    Рядок, який ідентифікує внутрішню версію цього обʼєкта на сервері, яку можуть використовувати клієнти для визначення, коли обʼєкти змінилися. Значення повинно бути розглянуте клієнтами як непрозоре і передане незміненим назад на сервер. Заповнюється системою. Тільки для читання. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency

  • selfLink (string)

    Застаріле: selfLink — це застаріле поле тільки для читання, яке більше не заповнюється системою.

5.9.4 - LocalObjectReference.

LocalObjectReference містить достатньо інформації, щоб дозволити вам знайти вказаний обʼєкт всередині того самого простору імен.

import "k8s.io/api/core/v1"

LocalObjectReference містить достатньо інформації, щоб дозволити вам знайти вказаний обʼєкт всередині того самого простору імен." title: "LocalObjectReference

  • name (string)

    Назва обʼєкта, на який ви посилаєтеся. Це поле є фактично обов'язковим, але через зворотну сумісність дозволено залишати його порожнім. Екземпляри цього типу з порожнім значенням тут, як правило, є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

5.9.5 - NodeSelectorRequirement

Вимоги селектора вузлів — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.

import "k8s.io/api/core/v1"

Вимоги селектора вузлів — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.

  • key (string), обовʼязково

    key — це ключ мітки, до якого застосовується селектор.

  • operator (string), обовʼязково

    operator представляє стосунок ключа до набору значень. Допустимі оператори: In, NotIn, Exists, DoesNotExist, Gt та Lt.

  • values ([]string)

    Atomic: буде замінено під час злиття

    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.

    Застосовується, лише якщо ім’я не вказано. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency

  • namespace (string)

    Простір імен визначає простір, у якому кожне ім’я має бути унікальним. Порожній простір імен еквівалентний простору імен "default", але "default" є канонічним представленням. Не всі об’єкти повинні мати область імен — значення цього поля для цих об’єктів буде порожнім.

    Має бути DNS_LABEL. Не може бути змінене. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces

  • labels (map[string]string)

    Масив (map) рядків ключів і значень, які можна використовувати для організації та категоризації (охоплення та вибору) обʼєктів. Може відповідати селекторам контролерів реплікації та сервісів. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels

  • annotations (map[string]string)

    Анотації — це неструктурований масив (map) значень ключів, що зберігається з ресурсом, який може бути заданий зовнішніми інструментами для зберігання та отримання довільних метаданих. Вони не є запитуваними та повинні зберігатися при модифікації обʼєктів. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations

System

  • finalizers ([]string)

    Set: унікальні значення будуть збережені під час злиття

    Це поле повинно бути порожнім перед тим, як обʼєкт буде видалено з реєстру. Кожен запис є ідентифікатором відповідального компонента, який видалить цей запис зі списку. Якщо deletionTimestamp обʼєкта не є nil, записи у цьому списку можуть бути лише видалені. Завершувачі можуть оброблятися та видалятися у будь-якому порядку. Порядок НЕ є обовʼязковим, оскільки це створює значний ризик зависання завершувачів. Поле finalizers є спільним, будь-який актор з відповідними дозволами може змінити його порядок. Якщо список завершувачів обробляється у порядку, це може призвести до ситуації, коли компонент, відповідальний за перший завершувач у списку, чекає сигналу (значення поля, зовнішньої системи або іншого), що виробляється компонентом, відповідальним за завершувача, який знаходиться далі у списку, що призводить до тупикової ситуації. Без обовʼязкового порядку завершувачі можуть впорядковуватися самостійно та не вразливі до змін порядку у списку.

  • managedFields ([]ManagedFieldsEntry)

    Atomic: буде замінено під час злиття

    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

      Map: унікальні значення ключа 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.

    Заповнюється системою. Тільки для читання. Null для списків. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • deletionGracePeriodSeconds (int64)

    Кількість секунд, які дозволяють цьому обʼєкту завершити роботу належним чином перед тим, як він буде видалений з системи. Встановлюється лише тоді, коли також встановлено deletionTimestamp. Може бути скорочено тільки в меншу сторону. Тільки для читання.

  • deletionTimestamp (Time)

    Час видалення (DeletionTimestamp) — це дата та час у форматі RFC 3339, коли цей ресурс буде видалено. Це поле встановлюється сервером, коли користувач запитує належне видалення, і не може бути прямо встановлене клієнтом. Ресурс очікується бути видаленим (більше не видимий у списку ресурсів та недосяжний за іменем) після часу, вказаного у цьому полі, як тільки список завершувачів (finalizers) буде порожнім. Поки список завершувачів містить елементи, видалення заблоковане. Як тільки встановлюється час видалення, це значення не можна скасувати або встановити далі в майбутнє, хоча його можна скоротити або ресурс може бути видалений раніше цього часу. Наприклад, користувач може запросити видалення Podʼа через 30 секунд. Kubelet відреагує, надіславши сигнал належного завершення роботи контейнерам у Podʼі. Після цих 30 секунд Kubelet надішле сигнал примусового завершення (SIGKILL) контейнеру й після очищення видалить Pod з API. У випадку мережевих розділень цей обʼєкт може існувати після цієї позначки часу, доки адміністратор або автоматизований процес не визначить, що ресурс повністю завершив роботу. Якщо не встановлено, належне видалення обʼєкта не було запитано.

    Заповнюється системою, коли запитано належне видалення. Тільки для читання. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • generation (int64)

    Послідовний номер, що представляє конкретну генерацію бажаного стану. Заповнюється системою. Тільки для читання.

  • resourceVersion (string)

    Непрозоре (opaque) значення, яке представляє внутрішню версію цього обʼєкта, яке може бути використано клієнтами для визначення змін в обʼєктах. Це може використовуватися для оптимістичного одночасного виконання, виявлення змін та операції спостереження над ресурсом або набором ресурсів. Клієнти повинні розглядати ці значення як непрозорі та передавати їх незмінними назад на сервер. Вони можуть бути дійсними тільки для певного ресурсу або набору ресурсів.

    Заповнюється системою. Тільки для читання. Значення повинно бути розглянуте клієнтами як непрозоре. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency

  • selfLink (string)

    Застаріле: selfLink — це застаріле поле, призначене лише для читання, яке більше не заповнюється системою.

  • uid (string)

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

    Заповнюється системою. Лише для читання. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#uids

5.9.8 - ObjectReference

ObjectReference містить достатньо інформації для того, щоб дозволити вам переглядати або змінювати зазначений обʼєкт.

import "k8s.io/api/core/v1"

ObjectReference містить достатньо інформації для того, щоб дозволити вам переглядати або змінювати зазначений обʼєкт.

5.9.9 - Patch

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)

    Назва контейнера: обовʼязково для томів, необовʼязково для змінних середовища.

  • divisor (Quantity)

    Вказує формат виводу відображених ресурсів, стандартне значення — "1".

5.9.12 - Status

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

import "k8s.io/apimachinery/pkg/apis/meta/v1"

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

  • apiVersion (string)

    APIVersion визначає версійну схему цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення, і можуть відхиляти невизнані значення. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  • code (int32)

    Рекомендований HTTP-код відповіді для цього статусу, 0, якщо не встановлено.

  • details (StatusDetails)

    Atommic: буде замінено під час злиття

    Розширені дані, повʼязані з причиною. Кожна причина може визначити свої власні розширені деталі. Це поле є необовʼязковим, і дані, що повертаються, не гарантовано відповідають будь-якій схемі, крім тієї, що визначена типом причини.

    StatusDetails — це набір додаткових властивостей, які МОЖУТЬ бути встановлені сервером для надання додаткової інформації про відповідь. Поле Reason обʼєкта Status визначає, які атрибути будуть встановлені. Клієнти повинні ігнорувати поля, які не відповідають визначеному типу кожного атрибута, і повинні припускати, що будь-який атрибут може бути порожнім, недійсним або невизначеним.

    • details.causes ([]StatusCause)

      Atommic: буде замінено під час злиття

      Масив 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.

      • details.kind (string)

        Атрибут kind ресурсу, повʼязаний зі статусом StatusReason. У деяких операціях він може відрізнятися від запитаного типу ресурсу. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

      • details.name (string)

        Атрибут name ресурсу, повʼязаний зі статусом StatusReason (коли є одне імʼя, яке можна описати).

      • details.retryAfterSeconds (int32)

        Якщо вказано, час у секундах до повторного виконання операції. Деякі помилки можуть вказувати, що клієнт повинен виконати альтернативну дію — для цих помилок це поле може показати, як довго чекати перед виконанням альтернативної дії.

      • details.uid (string)

        UID ресурсу. (коли є один ресурс, який можна описати). Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#uids

  • kind (string)

    Kind — це рядкове значення, що представляє обʼєкт REST, який цей обʼєкт представляє. Сервери можуть виводити це з точки доступу, на який клієнт надсилає запити. Не може бути оновлено. У форматі CamelCase. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • message (string)

    Зрозумілий для людини опис статусу цієї операції.

  • metadata (ListMeta)

    Стандартні метадані списку. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • reason (string)

    Машинозчитуваний опис того, чому ця операція має статус "Failure". Якщо це значення порожнє, немає доступної інформації. Причина уточнює HTTP-код стану, але не перевизначає його.

  • status (string)

    Статус операції. Один із: "Success" або "Failure". Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

5.9.13 - TypedLocalObjectReference

TypedLocalObjectReference містить достатньо інформації, щоб дозволити вам знаходити типізований згаданий обʼєкт всередині того ж простору імен.

import "k8s.io/api/core/v1"

TypedLocalObjectReference містить достатньо інформації, щоб дозволити вам знаходити типізований згаданий обʼєкт всередині того ж простору імен.

  • kind (string), обовʼязково

    Kind — це тип ресурсу, на який посилаються.

  • name (string), обовʼязково

    Name — це назва ресурсу, на який посилаються.

  • apiGroup (string)

    APIGroup — це група для ресурсу, на який посилаються. Якщо APIGroup не вказано, вказаний Kind повинен бути в основній групі API. Для будь-яких інших сторонніх типів APIGroup є обовʼязковим.

5.10 - Загальні параметри

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://golang.org/pkg/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', вивід буде відформатовано з відступами. Стандартне значення 'false', якщо user-agent не вказує вебоглядач або інструмент командного рядка HTTP (curl та wget).

propagationPolicy

Чи буде виконуватися і як буде виконуватися збір сміття. Можна встановити це поле або OrphanDependents, але не обидва. Стандартна політика визначається наявним набором завершувачів у metadata.finalizers і стандартною політикою для конкретного ресурсу. Прийнятні значення: 'Orphan' — зробити залежні обʼєкти сиротами; 'Background' — дозволити збирачу сміття видаляти залежні обʼєкти у фоновому режимі; 'Foreground' — політика каскаду, яка видаляє всі залежні обʼєкти явно.

resourceVersion

resourceVersion встановлює обмеження на те, з яких версій ресурсів може обслуговуватися запит. Докладніше див. https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions.

Стандартне значення не встановлено

resourceVersionMatch

resourceVersionMatch визначає, як resourceVersion застосовується до викликів списку. Наполегливо рекомендується встановлювати resourceVersionMatch для викликів списку, де встановлено resourceVersion. Докладніше див. https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions.

Стандартне значення не встановлено

sendInitialEvents

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 - Інструментування

6.1 - Метрики SLI компонентів Kubernetes

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [stable]

Типово Kubernetes 1.31 публікує метрики Індикаторів Рівня Обслуговування (SLI) для кожного компонентного бінарного файлу Kubernetes. Ця точка доступу метрики відкривається на порту HTTPS кожного компонента за шляхом /metrics/slis. Функціональна можливість ComponentSLIs типово увімкнена для кожного компонента Kubernetes починаючи з версії v1.27.

Метрики SLI

З увімкненими метриками SLI кожен компонент Kubernetes відкриває дві метрики, позначені для кожної перевірки стану:

  • вимірювач (gauge, який представляє поточний стан перевірки стану)
  • лічильник (counter, який записує накопичувальні підрахунки, спостережені для кожного стану перевірки стану)

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

Дані вимірювача Prometheus виглядають так:

# HELP kubernetes_healthcheck [ALPHA] Ця метрика записує результат однієї перевірки стану.
# TYPE kubernetes_healthcheck gauge
kubernetes_healthcheck{name="autoregister-completion",type="healthz"} 1
kubernetes_healthcheck{name="autoregister-completion",type="readyz"} 1
kubernetes_healthcheck{name="etcd",type="healthz"} 1
kubernetes_healthcheck{name="etcd",type="readyz"} 1
kubernetes_healthcheck{name="etcd-readiness",type="readyz"} 1
kubernetes_healthcheck{name="informer-sync",type="readyz"} 1
kubernetes_healthcheck{name="log",type="healthz"} 1
kubernetes_healthcheck{name="log",type="readyz"} 1
kubernetes_healthcheck{name="ping",type="healthz"} 1
kubernetes_healthcheck{name="ping",type="readyz"} 1

Дані лічильника виглядають так:

# HELP kubernetes_healthchecks_total [ALPHA] Ця метрика записує результати всіх перевірок стану.
# TYPE kubernetes_healthchecks_total counter
kubernetes_healthchecks_total{name="autoregister-completion",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="etcd",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="etcd",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="etcd-readiness",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="informer-sync",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="informer-sync",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="log",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="log",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="readyz"} 15

Використання цих даних

Точка доступу метрик компонентів SLI призначена для збору даних з високою частотою. Збір даних з високою частотою означає, що ви отримуєте більш точний сигнал вимірювача, який можна потім використовувати для розрахунку SLO. Точка доступу /metrics/slis надає необроблені дані, необхідні для розрахунку SLO доступності для відповідного компонента Kubernetes.

6.2 - Дані метрик вузла

Механізми доступу до метрик на рівні вузла, томів, Pod та контейнерів, як їх бачить kubelet.

kubelet збирає статистичні дані метрик на рівні вузла, томів, pod та контейнерів, і надає цю інформацію через Summary API.

Ви можете надіслати запит з проксі до Summary API через сервер API Kubernetes.

Ось приклад запиту до Summary API для вузла з іменем minikube:

kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary"

Ось той самий виклик API за допомогою curl:

# Спочатку потрібно запустити "kubectl proxy"
# Змініть 8080 на порт, який призначає "kubectl proxy"
curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary

Джерело метрик Summary API

Стандартно, Kubernetes отримує дані метрик вузлів, використовуючи вбудований cAdvisor, який працює в kubelet. Якщо ви увімкнете функціональну можливість PodAndContainerStatsFromCRI у вашому кластері та використовуєте середовище виконання контейнерів, яке підтримує доступ до статистики через Інтерфейс Виконання Контейнерів (CRI), тоді kubelet отримує дані метрик на рівні Pod та контейнерів за допомогою CRI, а не через cAdvisor.

Що далі

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

6.3 - Метрики Pod та Контейнерів CRI

Збір метрик Pod та контейнерів через CRI.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [alpha]

kubelet збирає метрики Pod та контейнерів через cAdvisor. Як альфа-функція, Kubernetes дозволяє налаштувати збір метрик Pod та контейнерів через Інтерфейс Виконання Контейнерів (CRI). Ви повинні увімкнути функціональну можливість PodAndContainerStatsFromCRI та використовувати сумісну реалізацію CRI (containerd >= 1.6.0, CRI-O >= 1.23.0), щоб використовувати механізм збору через CRI.

Метрики Pod та Контейнерів CRI

З увімкненим PodAndContainerStatsFromCRI, kubelet опитує підлегле середовище виконання контейнерів для отримання статистики Pod та контейнерів замість того, щоб безпосередньо перевіряти хост-систему за допомогою cAdvisor. Переваги використання середовища виконання контейнерів для цієї інформації, на відміну від прямого збору за допомогою cAdvisor, включають:

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

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

6.4 - Довідник Метрик Kubernetes

Деталі щодо метрик, які експортують компоненти Kubernetes.

Метрики (v1.30)

Ця сторінка містить деталі метрик, які експортують різні компоненти Kubernetes. Ви можете запитувати точки доступу метрик для цих компонентів за допомогою HTTP-запиту та отримувати поточні дані метрик у форматі Prometheus.

Список стабільних метрик Kubernetes

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

apiserver_admission_controller_admission_duration_seconds
Гістограма затримки контролера допуску в секундах, визначена за назвою та розподілена для кожної операції та ресурсу API і типу (перевірка або допуск).
  • STABLE
  • Histogram
  • nameoperationrejectedtype
apiserver_admission_step_admission_duration_seconds
Гістограма затримки підетапу допуску в секундах для кожної операції, ресурсу API та типу етапу (валідація або допуск).
  • STABLE
  • Histogram
  • operationrejectedtype
apiserver_admission_webhook_admission_duration_seconds
Гістограма затримки вебхука в секундах, ідентифікована за назвою та розбита за кожною операцією, ресурсом API та типом (валідація або допуск).
  • STABLE
  • Histogram
  • nameoperationrejectedtype
apiserver_current_inflight_requests
Максимальна кількість поточних використаних запитів цього apiserver на тип запиту за останню секунду.
  • STABLE
  • Gauge
  • request_kind
apiserver_longrunning_requests
Вимірювач усіх активних тривалих запитів apiserver, розділених за дієсловом, групою, версією, ресурсом, областю та компонентом. Не всі запити відстежуються таким чином.
  • STABLE
  • Gauge
  • componentgroupresourcescopesubresourceverbversion
apiserver_request_duration_seconds
Розподіл затримки відповіді в секундах для кожного дієслова, значення dry run, групи, версії, ресурсу, субресурсу, області застосування та компонента.
  • Histogram
  • componentdry_rungroupresourcescopesubresourceverbversion
apiserver_request_total
Лічильник запитів apiserver з розбивкою по кожному дієслову, dry run, групі, версії, ресурсу, області застосування, компоненту і коду HTTP-відповіді.
  • Counter
  • codecomponentdry_rungroupresourcescopesubresourceverbversion
apiserver_requested_deprecated_apis
Вимірювач запитуваних застарілих API, розподілених за групами API, версією, ресурсом, субресурсом і видаленим_випуском.
  • STABLE
  • Gauge
  • groupremoved_releaseresourcesubresourceversion
apiserver_response_sizes
Розподіл розміру відповіді в байтах для кожної групи, версії, дієслова, ресурсу, субресурсу, області дії та компонента.
  • STABLE
  • Histogram
  • componentgroupresourcescopesubresourceverbversion
apiserver_storage_objects
Кількість збережених обʼєктів на момент останньої перевірки з розподілом за типом. У разі помилки вибірки значення буде -1.
  • STABLE
  • Gauge
  • resource
apiserver_storage_size_bytes
Розмір сховища для файлу бази даних, фізично виділеного в байтах.
  • STABLE
  • Custom
  • storage_cluster_id
container_cpu_usage_seconds_total
Сукупний час процесора, який споживає контейнер, у секундах ядра
  • STABLE
  • Custom
  • containerpodnamespace
container_memory_working_set_bytes
Поточний робочий набір контейнера в байтах
  • STABLE
  • Custom
  • containerpodnamespace
container_start_time_seconds
Час запуску контейнера в секундах епохи Unix
  • STABLE
  • Custom
  • containerpodnamespace
cronjob_controller_job_creation_skew_duration_seconds
Час між запланованим запуском cronjob і створенням відповідного завдання
  • STABLE
  • Histogram
job_controller_job_pods_finished_total
Кількість завершених Podʼів, які повністю відстежуються
  • STABLE
  • Counter
  • completion_moderesult
job_controller_job_sync_duration_seconds
Час, необхідний для синхронізації завдання
  • STABLE
  • Histogram
  • actioncompletion_moderesult
job_controller_job_syncs_total
Кількість синхронізацій завдання
  • STABLE
  • Counter
  • actioncompletion_moderesult
job_controller_jobs_finished_total
Кількість завершених завдань
  • STABLE
  • Counter
  • completion_modereasonresult
kube_pod_resource_limit
Ліміт ресурсів для робочих навантажень в кластері, з розбивкою за Podʼами. Це показує використання ресурсів, яке планувальник і kubelet очікують на кожен Pod для ресурсів, а також одиницю виміру для ресурсу, якщо така є.
  • STABLE
  • Custom
  • namespacepodnodeschedulerpriorityresourceunit
kube_pod_resource_request
Ресурси, запитувані робочими навантаженнями в кластері, з розбивкою за Podʼами. Це показує використання ресурсів, яке планувальник і kubelet очікують на кожен Pod для ресурсів, а також одиницю виміру для ресурсу, якщо така є.
  • STABLE
  • Custom
  • namespacepodnodeschedulerpriorityresourceunit
kubernetes_healthcheck
Ця метрика фіксує результат однієї перевірки справності.
  • STABLE
  • Gauge
  • nametype
kubernetes_healthchecks_total
Ця метрика фіксує результати всіх перевірок справності.
  • STABLE
  • Counter
  • namestatustype
node_collector_evictions_total
Кількість виселень Node, що відбулися з моменту запуску поточного екземпляра NodeController.
  • STABLE
  • Counter
  • zone
node_cpu_usage_seconds_total
Сукупний час процесора, споживаний вузлом у секундах ядра
  • STABLE
  • Custom
node_memory_working_set_bytes
Поточний робочий набір вузла в байтах
  • STABLE
  • Custom
pod_cpu_usage_seconds_total
Сукупний час процесора, споживаний Podʼом у секундах ядра
  • STABLE
  • Custom
  • podnamespace
pod_memory_working_set_bytes
Поточний робочий набір Podʼа в байтах
  • STABLE
  • Custom
  • podnamespace
resource_scrape_error
1, якщо сталася помилка під час отримання метрик контейнера, 0 в іншому випадку
  • STABLE
  • Custom
scheduler_framework_extension_point_duration_seconds
Затримка для запуску всіх втулків певної точки розширення.
  • STABLE
  • Histogram
  • extension_pointprofilestatus
scheduler_pending_pods
Кількість відкладених Podʼів за типом черги. 'active' означає кількість Podʼів в activeQ; 'backoff' означає кількість Pods у backoffQ; 'unschedulable' означає кількість Podʼів в unschedulablePods, які планувальник намагався запланувати, але не зміг; 'gated' означає кількість незапланованих Podʼів, які планувальник ніколи не намагався запланувати, тому що вони є gated.
  • STABLE
  • Gauge
  • queue
scheduler_pod_scheduling_attempts
Кількість спроб успішно запланувати Pod.
  • STABLE
  • Histogram
scheduler_pod_scheduling_duration_seconds
E2e затримка для Podʼа, що планується, яка може включати кілька спроб планування.
  • STABLE
  • Histogram
  • attempts
  • 1.29.0
scheduler_preemption_attempts_total
Загальна кількість спроб випередження в кластері до цього часу
  • STABLE
  • Counter
scheduler_preemption_victims
Кількість обраних жертв випередження
  • STABLE
  • Histogram
scheduler_queue_incoming_pods_total
Кількість Podʼів, доданих до черг планування за подіями та типами черг.
  • STABLE
  • Counter
  • eventqueue
scheduler_schedule_attempts_total
Кількість спроб запланувати Podʼи, за результатом. "unscheduled" означає, що Pod не вдалося запланувати, тоді як "error" означає внутрішню проблему планувальника.
  • STABLE
  • Counter
  • profileresult
scheduler_scheduling_attempt_duration_seconds
Затримка спроби планування в секундах (алгоритм планування + привʼязка)
  • STABLE
  • Histogram
  • profileresult

Список бета-метрик Kubernetes

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

apiserver_flowcontrol_current_executing_requests
Кількість запитів на початковій (для WATCH) або будь-якій (для не-WATCH) стадії виконання в підсистемі API Priority and Fairness
  • BETA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_current_executing_seats
Паралельність (кількість місць), яку займають поточні запити, що виконуються (початкова стадія для WATCH, будь-яка інша стадія) у підсистемі API Priority and Fairness
  • BETA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_current_inqueue_requests
Кількість запитів, що перебувають у чергах підсистеми API Priority and Fairness
  • BETA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_dispatched_requests_total
Кількість виконаних запитів в підсистемі API Priority and Fairness
  • BETA
  • Counter
  • flow_schemapriority_level
apiserver_flowcontrol_nominal_limit_seats
Номінальна кількість місць виконання, налаштована для кожного рівня пріоритету
  • BETA
  • Gauge
  • priority_level
apiserver_flowcontrol_rejected_requests_total
Кількість запитів, відхилених підсистемою API Priority and Fairness
  • BETA
  • Counter
  • flow_schemapriority_levelreason
apiserver_flowcontrol_request_wait_duration_seconds
Час очікування запиту в черзі
  • BETA
  • Histogram
  • executeflow_schemapriority_level
disabled_metrics_total
Кількість вимкнених метрик.
  • BETA
  • Counter
hidden_metrics_total
Кількість прихованих метрик.
  • BETA
  • Counter
kubernetes_feature_enabled
Ця метрика фіксує дані про стадію та ввімкнення функції k8s.
  • BETA
  • Gauge
  • namestage
registered_metrics_total
Кількість зареєстрованих метрик з розбивкою за рівнем стабільності та версією застарівння.
  • BETA
  • Counter
  • deprecated_versionstability_level
scheduler_pod_scheduling_sli_duration_seconds
E2e затримка для пакета, що планується, з моменту потрапляння пакета в чергу на планування і може включати декілька спроб планування.
  • BETA
  • Histogram
  • attempts

Список альфа-метрик Kubernetes

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

aggregator_discovery_aggregation_count_total
Лічильник кількості разів, коли виявлення (discovery) було агреговано
  • ALPHA
  • Counter
aggregator_openapi_v2_regeneration_count
Лічильник кількості регенерацій специфікації OpenAPI v2 розбито за назвою APIService та причиною.
  • ALPHA
  • Counter
  • apiservicereason
aggregator_openapi_v2_regeneration_duration
Показник тривалості регенерації специфікації OpenAPI v2 у секундах.
  • ALPHA
  • Gauge
  • reason
aggregator_unavailable_apiservice
Кількість APIService, які позначені як недоступні, з розбивкою за назвою APIService.
  • ALPHA
  • Custom
  • name
aggregator_unavailable_apiservice_total
Лічильник APIServices, які позначені як недоступні, з розбивкою за назвою APIService та причиною.
  • ALPHA
  • Counter
  • namereason
apiextensions_apiserver_validation_ratcheting_seconds
Час для порівняння старого з новим для цілей CRDValidationRatcheting під час UPDATE в секундах.
  • ALPHA
  • Histogram
apiextensions_openapi_v2_regeneration_count
Лічильник кількості регенерацій специфікації OpenAPI v2, розбитий за назвою та причиною виклику CRD.
  • ALPHA
  • Counter
  • crdreason
apiextensions_openapi_v3_regeneration_count
Лічильник кількості регенерацій специфікації OpenAPI v3 з розбивкою за групами, версіями, джерелом CRD та причиною.
  • ALPHA
  • Counter
  • crdgroupreasonversion
apiserver_admission_match_condition_evaluation_errors_total
Кількість помилок оцінки умов допуску, ідентифікованих за назвою ресурсу, що містить умову допуску, з розбивкою для кожного типу, що містить matchConditions ("вебхук" або "політика"), операцію та тип допуску (валідація або допуск).
  • ALPHA
  • Counter
  • kindnameoperationtype
apiserver_admission_match_condition_evaluation_seconds
Час оцінки відповідності умов допуску в секундах, ідентифікований за назвою і розбитий для кожного типу, що містить matchConditions ("вебхук" або "політика"), операцію і тип (валідація або допуск).
  • ALPHA
  • Histogram
  • kindnameoperationtype
apiserver_admission_match_condition_exclusions_total
Кількість виключень для оцінки відповідності умов допуску, ідентифікована за назвою ресурсу, що містить умову відповідності, і розбита для кожного типу, що містить matchConditions ("вебхук" або "політика"), операцію і тип допуску (валідація або допуск).
  • ALPHA
  • Counter
  • kindnameoperationtype
apiserver_admission_step_admission_duration_seconds_summary
Зведення затримок на підетапах допуску в секундах для кожної операції, ресурсу API та типу етапу (валідація або допуск) для кожної операції та ресурсу API.
  • ALPHA
  • Summary
  • operationrejectedtype
apiserver_admission_webhook_fail_open_count
Кількість відкритих помилок вебхука допуску, ідентифікованих за іменами та розбитих за кожним типом допуску (валідація або мутація).
  • ALPHA
  • Counter
  • nametype
apiserver_admission_webhook_rejection_count
Кількість відмов від вебхуків допуску, ідентифікованих за іменами та розбитих за кожним типом допуску (валідація або допуск) та операцією. Додаткові мітки вказують на тип помилки (error_webhook_error або apiserver_internal_error, якщо сталася помилка; no_error в іншому випадку) і необовʼязково ненульовий код відмови, якщо вебхук відхиляє запит з кодом HTTP-статусу (обробляється apiserver, коли код більше або дорівнює 400). Коди, більші за 600, усікаються до 600, щоб обмежити кардинальність метрики.
  • ALPHA
  • Counter
  • error_typenameoperationrejection_codetype
apiserver_admission_webhook_request_total
Загальна кількість запитів на вебхук, ідентифікована за назвою та розбита за типом допуску (валідація чи модифікація) та операцією. Додаткові мітки вказують, чи був запит відхилений, і код статусу HTTP. Коди, що перевищують 600, усікаються до 600, щоб обмежити кардинальність метрики.
  • ALPHA
  • Counter
  • codenameoperationrejectedtype
apiserver_audit_error_total
Лічильник подій аудиту, які не були перевірені належним чином. Мітка plugin визначає втулок, на який вплинула помилка.
  • ALPHA
  • Counter
  • plugin
apiserver_audit_event_total
Лічильник подій аудиту, що генеруються та надсилаються до бекенду аудиту.
  • ALPHA
  • Counter
apiserver_audit_level_total
Лічильник рівнів політики для подій аудиту (1 на запит).
  • ALPHA
  • Counter
  • level
apiserver_audit_requests_rejected_total
Лічильник запитів apiserver, відхилених через помилку в логах аудиту в бекенді.
  • ALPHA
  • Counter
apiserver_authentication_config_controller_automatic_reload_last_timestamp_seconds
Мітка часу останнього автоматичного перезавантаження конфігурації автентифікації з розподілом за статусом та ідентифікатором apiserver.
  • ALPHA
  • Gauge
  • apiserver_id_hashstatus
apiserver_authentication_config_controller_automatic_reloads_total
Загальна кількість автоматичних перезавантажень конфігурації автентифікації з розподілом за статусом та ідентифікацією apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hashstatus
apiserver_authentication_jwt_authenticator_latency_seconds
Латентність операцій автентифікації jwt у секундах. Це час, витрачений на автентифікацію токена лише у випадку пропуску в кеші (тобто коли токен не знайдено в кеші).
  • ALPHA
  • Histogram
  • jwt_issuer_hashresult
apiserver_authorization_decisions_total
Загальна кількість кінцевих рішень, прийнятих авторизатором, з розбивкою за типом авторизатора, імʼям та рішенням.
  • ALPHA
  • Counter
  • decisionnametype
apiserver_authorization_match_condition_evaluation_errors_total
Загальна кількість помилок, коли вебхук авторизації стикається з помилкою умови збігу, з розбивкою за типом та іменем авторизації.
  • ALPHA
  • Counter
  • nametype
apiserver_authorization_match_condition_evaluation_seconds
Час оцінки умови збігу авторизації в секундах, з розбивкою за типом та іменем авторизатора.
  • ALPHA
  • Histogram
  • nametype
apiserver_authorization_match_condition_exclusions_total
Загальна кількість винятків, коли вебхук авторизації пропускається, оскільки умови збігу виключають його.
  • ALPHA
  • Counter
  • nametype
apiserver_authorization_webhook_duration_seconds
Затримка запиту в секундах.
  • ALPHA
  • Histogram
  • nameresult
apiserver_authorization_webhook_evaluations_fail_open_total
Результат NoOpinion через тайм-аут вебхуку або помилку.
  • ALPHA
  • Counter
  • nameresult
apiserver_authorization_webhook_evaluations_total
Перехід туди-назад до вебхуків авторизації.
  • ALPHA
  • Counter
  • nameresult
apiserver_cache_list_fetched_objects_total
Кількість об’єктів, зчитаних із кешу спостереження під час обслуговування запиту LIST
  • ALPHA
  • Counter
  • indexresource_prefix
apiserver_cache_list_returned_objects_total
Кількість об’єктів, повернутих за запитом LIST із кешу спостереження
  • ALPHA
  • Counter
  • resource_prefix
apiserver_cache_list_total
Кількість запитів LIST, наданих із кешу спостереження
  • ALPHA
  • Counter
  • indexresource_prefix
apiserver_cel_compilation_duration_seconds
Час компіляції CEL у секундах.
  • ALPHA
  • Histogram
apiserver_cel_evaluation_duration_seconds
Час оцінки CEL у секундах.
  • ALPHA
  • Histogram
apiserver_certificates_registry_csr_honored_duration_total
Загальна кількість виданих CSR із запитаною тривалістю, яка була виконана, розділена за підписувачами (лише імена підписувачів kubernetes.io визначено окремо)
  • ALPHA
  • Counter
  • signerName
apiserver_certificates_registry_csr_requested_duration_total
Загальна кількість виданих CSR із запитаною тривалістю, розділена за підписувачами (лише імена підписантів kubernetes.io визначено конкретно)
  • ALPHA
  • Counter
  • signerName
apiserver_client_certificate_expiration_seconds
Розподіл залишкового терміну служби сертифіката, який використовується для автентифікації запиту.
  • ALPHA
  • Histogram
apiserver_clusterip_repair_ip_errors_total
Кількість помилок, виявлених в clusterips циклом ремонту, за типами: leak, repair, full, outOfRange, duplicate, unknown, invalid
  • ALPHA
  • Counter
  • type
apiserver_clusterip_repair_reconcile_errors_total
Кількість збоїв узгодження в циклі узгодження ремонту clusterip
  • ALPHA
  • Counter
apiserver_conversion_webhook_duration_seconds
Затримка запиту конверсії вубхука
  • ALPHA
  • Histogram
  • failure_typeresult
apiserver_conversion_webhook_request_total
Лічильник конверсійних запитів вубхук з успішністю/неуспішністю та типом помилки
  • ALPHA
  • Counter
  • failure_typeresult
apiserver_crd_conversion_webhook_duration_seconds
Тривалість конверсії CRD вебхука в секундах
  • ALPHA
  • Histogram
  • crd_namefrom_versionsucceededto_version
apiserver_current_inqueue_requests
Максимальна кількість запитів у черзі в цьому apiserver для кожного типу запитів за останню секунду.
  • ALPHA
  • Gauge
  • request_kind
apiserver_delegated_authn_request_duration_seconds
Затримка запиту в секундах. Розбито за кодом статусу.
  • ALPHA
  • Histogram
  • code
apiserver_delegated_authn_request_total
Кількість HTTP-запитів, розділених за кодом статусу.
  • ALPHA
  • Counter
  • code
apiserver_delegated_authz_request_duration_seconds
Затримка запиту в секундах. Розбито за кодом статусу.
  • ALPHA
  • Histogram
  • code
apiserver_delegated_authz_request_total
Кількість HTTP-запитів, розділених за кодом статусу.
  • ALPHA
  • Counter
  • code
apiserver_egress_dialer_dial_duration_seconds
Гістограма затримки набору в секундах, позначена протоколом (http-connect або grpc), транспортом (tcp або uds)
  • ALPHA
  • Histogram
  • protocoltransport
apiserver_egress_dialer_dial_failure_count
Кількість невдалих спроб зʼєднання, позначених протоколом (http-connect або grpc), транспортом (tcp або uds) та стадією (зʼєднання або проксі). Етап вказує на те, на якому етапі сталася помилка зʼєднання
  • ALPHA
  • Counter
  • protocolstagetransport
apiserver_egress_dialer_dial_start_total
Стартує зʼєднання, позначене протоколом (http-connect або grpc) і транспортом (tcp або uds).
  • ALPHA
  • Counter
  • protocoltransport
apiserver_encryption_config_controller_automatic_reload_failures_total
Загальна кількість невдалих автоматичних перезавантажень конфігурації шифрування з розподілом за ідентичністю apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hash
  • 1.30.0
apiserver_encryption_config_controller_automatic_reload_success_total
Загальна кількість успішних автоматичних перезавантажень конфігурації шифрування з розподілом за ідентичністю apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hash
  • 1.30.0
apiserver_envelope_encryption_dek_cache_fill_percent
Відсоток слотів кешу, які наразі зайняті кешованими DEK.
  • ALPHA
  • Gauge
apiserver_envelope_encryption_dek_cache_inter_arrival_time_seconds
Час (у секундах) між надходженням запитів на трансформацію.
  • ALPHA
  • Histogram
  • transformation_type
apiserver_envelope_encryption_dek_source_cache_size
Кількість записів у вихідному кеші ключа шифрування даних (DEK). При перезапуску це значення є наближеним значенням кількості розшифрованих RPC-викликів, які сервер зробить до втулка KMS.
  • ALPHA
  • Gauge
  • provider_name
apiserver_envelope_encryption_invalid_key_id_from_status_total
Кількість разів, коли невірний keyID повертається викликом Status RPC з розбивкою по помилках.
  • ALPHA
  • Counter
  • errorprovider_name
apiserver_envelope_encryption_key_id_hash_last_timestamp_seconds
Останній раз в секундах, коли було використано keyID.
  • ALPHA
  • Gauge
  • apiserver_id_hashkey_id_hashprovider_nametransformation_type
apiserver_envelope_encryption_key_id_hash_status_last_timestamp_seconds
Останній час у секундах, коли ідентифікатор ключа було повернуто викликом Status RPC.
  • ALPHA
  • Gauge
  • apiserver_id_hashkey_id_hashprovider_name
apiserver_envelope_encryption_key_id_hash_total
Кількість разів використання keyID з розподілом за типом перетворення, провайдером та ідентичністю apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hashkey_id_hashprovider_nametransformation_type
apiserver_envelope_encryption_kms_operations_latency_seconds
Загальна тривалість роботи KMS зі статусом коду помилки gRPC.
  • ALPHA
  • Histogram
  • grpc_status_codemethod_nameprovider_name
apiserver_flowcontrol_current_inqueue_seats
Кількість місць у чергах підсистеми API Priority and Fairness, що перебувають на розгляді в даний момент
  • ALPHA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_current_limit_seats
Поточна похідна кількість місць виконання, доступних для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_current_r
R(час останньої зміни)
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats
Спостереження, в кінці кожної наносекунди, за (кількістю місць, які може використати кожен рівень пріоритету) / (номінальна кількість місць для цього рівня)
  • ALPHA
  • TimingRatioHistogram
  • priority_level
apiserver_flowcontrol_demand_seats_average
Середньозважене за часом значення demand_seats за останній період коригування
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats_high_watermark
Найвищий показник, за останній період коригування, для demand_seats
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats_smoothed
Згладжені вимоги до місць
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats_stdev
Середньозважене за часом стандартне відхилення, за останній період коригування, demand_seats
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_dispatch_r
R(час останньої диспетчеризації)
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_epoch_advance_total
Кількість разів, коли лічильник прогресу набору черг стрибнув назад
  • ALPHA
  • Counter
  • priority_levelsuccess
apiserver_flowcontrol_latest_s
S(останній відправлений запит)
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_lower_limit_seats
Налаштовано нижню межу кількості місць виконання, доступних для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_next_discounted_s_bounds
min і max, за чергою, для S (найстаріша заявка в черзі) — оціночне значення незавершеної роботи
  • ALPHA
  • Gauge
  • boundpriority_level
apiserver_flowcontrol_next_s_bounds
min і max, за чергами, для S (найстаріша заявка в черзі)
  • ALPHA
  • Gauge
  • boundpriority_level
apiserver_flowcontrol_priority_level_request_utilization
Спостереження наприкінці кожної наносекунди кількості запитів (у частках від відповідного ліміту), що очікують або перебувають на будь-якій стадії виконання (але тільки на початковій стадії для WATCH)
  • ALPHA
  • TimingRatioHistogram
  • phasepriority_level
apiserver_flowcontrol_priority_level_seat_utilization
Спостереження наприкінці кожної наносекунди за використанням місць на будь-якій стадії виконання (але тільки на початковій стадії для WATCH)
  • ALPHA
  • TimingRatioHistogram
  • priority_level
  • phase:executing
apiserver_flowcontrol_read_vs_write_current_requests
Спостереження наприкінці кожної наносекунди за кількістю запитів (у частках від відповідного ліміту), які очікують на виконання або перебувають на стадії виконання
  • ALPHA
  • TimingRatioHistogram
  • phaserequest_kind
apiserver_flowcontrol_request_concurrency_in_use
Паралельність (кількість місць), яку займають поточні запити, що виконуються (початкова стадія для WATCH, будь-яка інша стадія) у підсистемі API Priority and Fairness
  • ALPHA
  • Gauge
  • flow_schemapriority_level
  • 1.31.0
apiserver_flowcontrol_request_concurrency_limit
Номінальна кількість місць виконання, налаштована для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
  • 1.30.0
apiserver_flowcontrol_request_dispatch_no_accommodation_total
Кількість випадків, коли спроба диспетчеризації призвела до відмови у розміщенні через відсутність вільних місць
  • ALPHA
  • Counter
  • flow_schemapriority_level
apiserver_flowcontrol_request_execution_seconds
Тривалість початкового (для WATCH) або будь-якого (для не-WATCH) етапу виконання запиту в підсистемі API Priority and Fairness
  • ALPHA
  • Histogram
  • flow_schemapriority_leveltype
apiserver_flowcontrol_request_queue_length_after_enqueue
Довжина черги в підсистемі API Priority and Fairness, яку бачить кожен запит після того, як його поставлено в чергу
  • ALPHA
  • Histogram
  • flow_schemapriority_level
apiserver_flowcontrol_seat_fair_frac
Справедлива частка паралелізму сервера для виділення кожному рівню пріоритету, який може його використовувати
  • ALPHA
  • Gauge
apiserver_flowcontrol_target_seats
Цілі розподілу місць
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_upper_limit_seats
Налаштована верхня межа кількості місць виконання, доступних для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_watch_count_samples
Кількість спостерігачів для запитів, що змінюються, в API Priority and Fairness
  • ALPHA
  • Histogram
  • flow_schemapriority_level
apiserver_flowcontrol_work_estimated_seats
Кількість розрахункових місць (максимум початкових і кінцевих місць), повʼязаних із запитами в API Priority and Fairness
  • ALPHA
  • Histogram
  • flow_schemapriority_level
apiserver_init_events_total
Лічильник подій init, оброблених у watch кеші, з розбивкою за типами ресурсів.
  • ALPHA
  • Counter
  • resource
apiserver_kube_aggregator_x509_insecure_sha1_total
Підраховує кількість запитів до серверів з незахищеними SHA1-підписами в обслуговуючому сертифікаті АБО кількість збоїв зʼєднання через незахищені SHA1-підписи (або/або, залежно від середовища виконання)
  • ALPHA
  • Counter
apiserver_kube_aggregator_x509_missing_san_total
Підраховує кількість запитів до серверів, у яких відсутнє розширення SAN в обслуговуючому сертифікаті, АБО кількість збоїв зʼєднання через відсутність x509 сертифіката, у якому відсутнє розширення SAN (або, залежно від середовища виконання)
  • ALPHA
  • Counter
apiserver_nodeport_repair_port_errors_total
Кількість помилок, виявлених на портах циклом виправлення, з розбивкою за типом помилки: leak, repair, full, outOfRange, duplicate, unknown
  • ALPHA
  • Counter
  • type
apiserver_request_aborts_total
Кількість запитів, які apiserver перервав, можливо, через таймаут, для кожної групи, версії, дієслова, ресурсу, субресурсу та області дії
  • ALPHA
  • Counter
  • groupresourcescopesubresourceverbversion
apiserver_request_body_size_bytes
Розмір тіла запиту Apiserver в байтах з розбивкою за ресурсами та дієсловами.
  • ALPHA
  • Histogram
  • resourceverb
apiserver_request_filter_duration_seconds
Розподіл затримки фільтрації запитів у секундах для кожного типу фільтрів
  • ALPHA
  • Histogram
  • filter
apiserver_request_post_timeout_total
Відстежує активність обробників запитів після того, як повʼязані з ними запити були вичерпані apiserverʼом
  • ALPHA
  • Counter
  • sourcestatus
apiserver_request_sli_duration_seconds
Розподіл затримок відповіді (не враховуючи тривалості вебхука та часу очікування в черзі пріоритету і справедливості) в секундах для кожного дієслова, групи, версії, ресурсу, субресурсу, області дії та компонента.
  • ALPHA
  • Histogram
  • componentgroupresourcescopesubresourceverbversion
apiserver_request_slo_duration_seconds
Розподіл затримок відповіді (не враховуючи тривалості вебхука та часу очікування в черзі пріоритету і справедливості) в секундах для кожного дієслова, групи, версії, ресурсу, субресурсу, області дії та компонента.
  • ALPHA
  • Histogram
  • componentgroupresourcescopesubresourceverbversion
  • 1.27.0
apiserver_request_terminations_total
Кількість запитів, які apiserver припинив з метою самозахисту.
  • ALPHA
  • Counter
  • codecomponentgroupresourcescopesubresourceverbversion
apiserver_request_timestamp_comparison_time
Час, витрачений на порівняння старих і нових обʼєктів у запитах UPDATE або PATCH
  • ALPHA
  • Histogram
  • code_path
apiserver_rerouted_request_total
Загальна кількість запитів, які були перенаправлені на рівноправний kube apiserver через те, що локальний apiserver не зміг їх обслужити
  • ALPHA
  • Counter
  • code
apiserver_selfrequest_total
Лічильник самозвернень apiserver, розбитий для кожного дієслова, ресурсу API та субресурсу.
  • ALPHA
  • Counter
  • resourcesubresourceverb
apiserver_storage_data_key_generation_duration_seconds
Затримки в секундах операцій генерації ключів шифрування даних (DEK).
  • ALPHA
  • Histogram
apiserver_storage_data_key_generation_failures_total
Загальна кількість невдалих операцій генерації ключів шифрування даних (DEK).
  • ALPHA
  • Counter
apiserver_storage_db_total_size_in_bytes
Загальний розмір файлу бази даних, фізично виділений в байтах.
  • ALPHA
  • Gauge
  • endpoint
  • 1.28.0
apiserver_storage_decode_errors_total
Кількість збережених помилок декодування обʼєктів з розподілом за типами обʼєктів
  • ALPHA
  • Counter
  • resource
apiserver_storage_envelope_transformation_cache_misses_total
Загальна кількість пропусків кешу при доступі до ключа дешифрування (KEK).
  • ALPHA
  • Counter
apiserver_storage_events_received_total
Кількість отриманих подій etcd з розбивкою за типами.
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_evaluated_objects_total
Кількість протестованих обʼєктів під час обслуговування LIST-запиту зі сховища
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_fetched_objects_total
Кількість обʼєктів, прочитаних зі сховища під час обслуговування LIST-запиту
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_returned_objects_total
Кількість обʼєктів, що повертаються на запит LIST зі сховища
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_total
Кількість запитів LIST, виконаних зі сховища
  • ALPHA
  • Counter
  • resource
apiserver_storage_transformation_duration_seconds
Затримки в секундах операцій перетворення значень.
  • ALPHA
  • Histogram
  • transformation_typetransformer_prefix
apiserver_storage_transformation_operations_total
Загальна кількість перетворень. Успішне перетворення матиме статус "OK", а у випадку невдалого перетворення — інший рядок статусу. Цей статус і поле типу перетворення можуть бути використані для сповіщення про невдале шифрування/розшифрування з використанням типу перетворення transformation_type from_storage для розшифрування і to_storage для шифрування.
  • ALPHA
  • Counter
  • statustransformation_typetransformer_prefix
apiserver_stream_translator_requests_total
Загальна кількість запитів, які були оброблені проксі StreamTranslatorProxy, що обробляє потокове відтворення RemoteCommand/V5
  • ALPHA
  • Counter
  • code
apiserver_terminated_watchers_total
Лічильник спостерігачів закрито через відсутність реакції за типом ресурсу.
  • ALPHA
  • Counter
  • resource
apiserver_tls_handshake_errors_total
Кількість запитів, відхилених з помилкою 'TLS handshake error from'
  • ALPHA
  • Counter
apiserver_validating_admission_policy_check_duration_seconds
Затримка допуску валідації для окремих виразів валідації в секундах, позначена політикою, а також вказівкою на звʼязаність, стан та вжиті заходи примусового виконання.
  • ALPHA
  • Histogram
  • enforcement_actionpolicypolicy_bindingstate
apiserver_validating_admission_policy_check_total
Перевірка політики допуску перевіряє загальну кількість, позначену політикою, з подальшою ідентифікацією за обовʼязковістю, вжитими заходами примусового виконання та станом.
  • ALPHA
  • Counter
  • enforcement_actionpolicypolicy_bindingstate
apiserver_validating_admission_policy_definition_total
Валідація політики допуску підраховує загальну кількість, позначену станом та заходами примусового виконання.
  • ALPHA
  • Counter
  • enforcement_actionstate
apiserver_watch_cache_events_dispatched_total
Лічильник подій, відправлених у кеш watch, розбитий за типами ресурсів.
  • ALPHA
  • Counter
  • resource
apiserver_watch_cache_events_received_total
Лічильник подій, отриманих у кеші watch, розбитий за типом ресурсу.
  • ALPHA
  • Counter
  • resource
apiserver_watch_cache_initializations_total
Лічильник ініціалізацій кешу watch, розбитий за типами ресурсів.
  • ALPHA
  • Counter
  • resource
apiserver_watch_cache_read_wait_seconds
Гістограма часу, витраченого на очікування оновлення кешу watch.
  • ALPHA
  • Histogram
  • resource
apiserver_watch_events_sizes
Перегляд розподілу розміру події в байтах
  • ALPHA
  • Histogram
  • groupkindversion
apiserver_watch_events_total
Кількість подій, надісланих клієнтам watch
  • ALPHA
  • Counter
  • groupkindversion
apiserver_watch_list_duration_seconds
Розподіл затримки відповіді в секундах для запитів до списків спостереження за групами, версіями, ресурсами та сферами застосування.
  • ALPHA
  • Histogram
  • groupresourcescopeversion
apiserver_webhooks_x509_insecure_sha1_total
Підраховує кількість запитів до серверів з незахищеними SHA1-підписами в обслуговуючому сертифікаті АБО кількість збоїв зʼєднання через незахищені SHA1-підписи (або/або, залежно від середовища виконання)
  • ALPHA
  • Counter
apiserver_webhooks_x509_missing_san_total
Підраховує кількість запитів до серверів, у яких відсутнє розширення SAN в обслуговуючому сертифікаті, АБО кількість збоїв зʼєднання через відсутність x509 сертифіката, у якому відсутнє розширення SAN (або/або, залежно від середовища виконання)
  • ALPHA
  • Counter
attach_detach_controller_attachdetach_controller_forced_detaches
Кількість разів, коли контролер A/D виконував примусове відʼєднання
  • ALPHA
  • Counter
  • reason
attachdetach_controller_total_volumes
Кількість томів в A/D контролері
  • ALPHA
  • Custom
  • plugin_namestate
authenticated_user_requests
Лічильник автентифікованих запитів, розбитий за іменами користувачів.
  • ALPHA
  • Counter
  • username
authentication_attempts
Лічильник автентифікованих спроб.
  • ALPHA
  • Counter
  • result
authentication_duration_seconds
Тривалість автентифікації в секундах з розбивкою за результатами.
  • ALPHA
  • Histogram
  • result
authentication_token_cache_active_fetch_count
  • ALPHA
  • Gauge
  • status
authentication_token_cache_fetch_total
  • ALPHA
  • Counter
  • status
authentication_token_cache_request_duration_seconds
  • ALPHA
  • Histogram
  • status
authentication_token_cache_request_total
  • ALPHA
  • Counter
  • status
authorization_attempts_total
Лічильник спроб авторизації з розбивкою за результатом. Це може бути "allowed", "denied", "no-opinion" або "error".
  • ALPHA
  • Counter
  • result
authorization_duration_seconds
Тривалість авторизації в секундах з розбивкою за результатами.
  • ALPHA
  • Histogram
  • result
cloud_provider_webhook_request_duration_seconds
Затримка запиту в секундах. З розбивкою по коду статусу.
  • ALPHA
  • Histogram
  • codewebhook
cloud_provider_webhook_request_total
Кількість HTTP-запитів, розділених за кодом статусу.
  • ALPHA
  • Counter
  • codewebhook
cloudprovider_gce_api_request_duration_seconds
Затримка виклику API GCE
  • ALPHA
  • Histogram
  • regionrequestversionzone
cloudprovider_gce_api_request_errors
Кількість помилок виклику API
  • ALPHA
  • Counter
  • regionrequestversionzone
container_swap_usage_bytes
Поточний обсяг використання свопу контейнера у байтах. Відображається лише на системах, відмінних від Windows
  • ALPHA
  • Custom
  • containerpodnamespace
csi_operations_seconds
Тривалість роботи інтерфейсу Container Storage Interface з кодом помилки gRPC усього
  • ALPHA
  • Histogram
  • driver_namegrpc_status_codemethod_namemigrated
endpoint_slice_controller_changes
Кількість змін EndpointSlice
  • ALPHA
  • Counter
  • operation
endpoint_slice_controller_desired_endpoint_slices
Кількість EndpointSlices, які могли б існувати при ідеальному розподілі точок доступу
  • ALPHA
  • Gauge
endpoint_slice_controller_endpoints_added_per_sync
Кількість точок доступу, доданих під час кожної синхронізації Service
  • ALPHA
  • Histogram
endpoint_slice_controller_endpoints_desired
Кількість бажаних точок доступу
  • ALPHA
  • Gauge
endpoint_slice_controller_endpoints_removed_per_sync
Кількість видалених точок доступу під час кожної синхронізації Service
  • ALPHA
  • Histogram
endpoint_slice_controller_endpointslices_changed_per_sync
Кількість EndpointSlices, змінених під час кожної синхронізації Service
  • ALPHA
  • Histogram
  • topologytraffic_distribution
endpoint_slice_controller_num_endpoint_slices
Кілкість EndpointSlices
  • ALPHA
  • Gauge
endpoint_slice_controller_services_count_by_traffic_distribution
Кількість Services, що використовують певний trafficDistribution
  • ALPHA
  • Gauge
  • traffic_distribution
endpoint_slice_controller_syncs
Кількість синхронізацій EndpointSlice
  • ALPHA
  • Counter
  • result
endpoint_slice_mirroring_controller_addresses_skipped_per_sync
Кількість адрес, пропущених під час кожної синхронізації точок доступу через те, що вони недійсні або перевищують MaxEndpointsPerSubset
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_changes
Кількість змін EndpointSlice
  • ALPHA
  • Counter
  • operation
endpoint_slice_mirroring_controller_desired_endpoint_slices
Кількість EndpointSlices, які могли б існувати при ідеальному розподілі точок доступу
  • ALPHA
  • Gauge
endpoint_slice_mirroring_controller_endpoints_added_per_sync
Кількість точок доступу, доданих під час кожної синхронізації Endpoints
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_endpoints_desired
Кількість бажаних точок доступу
  • ALPHA
  • Gauge
endpoint_slice_mirroring_controller_endpoints_removed_per_sync
Кількість видалених точок доступу під час кожної синхронізації Endpoints
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_endpoints_sync_duration
Тривалість syncEndpoints() у секундах
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_endpoints_updated_per_sync
Кількість точок доступу, оновлених під час кожної синхронізації Endpoints
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_num_endpoint_slices
Кількість EndpointSlices
  • ALPHA
  • Gauge
ephemeral_volume_controller_create_failures_total
Кількість запитів на створення PersistenVolumeClaims
  • ALPHA
  • Counter
ephemeral_volume_controller_create_total
Кількість запитів на створення PersistenVolumeClaims
  • ALPHA
  • Counter
etcd_bookmark_counts
Кількість закладок etcd (подій, що сповіщають про хід виконання) з розподілом за типами.
  • ALPHA
  • Gauge
  • resource
etcd_lease_object_counts
Кількість обʼєктів, закріплених за одним lease etcd.
  • ALPHA
  • Histogram
etcd_request_duration_seconds
Затримка запиту etcd в секундах для кожної операції та типу обʼєкта.
  • ALPHA
  • Histogram
  • operationtype
etcd_request_errors_total
Etcd підраховує кількість невдалих запитів для кожної операції та типу обʼєкта.
  • ALPHA
  • Counter
  • operationtype
etcd_requests_total
Підрахунок запитів etcd здійснюється для кожної операції та типу обʼєкта.
  • ALPHA
  • Counter
  • operationtype
etcd_version_info
Версія сервера etcd
  • ALPHA
  • Gauge
  • binary_version
field_validation_request_duration_seconds
Розподіл затримки відповіді в секундах для кожного значення валідації поля
  • ALPHA
  • Histogram
  • field_validation
force_cleaned_failed_volume_operation_errors_total
Кількість томів, які не пройшли примусове очищення після реконструкції, не пройшли примусового очищення під час запуску kubelet.
  • ALPHA
  • Counter
force_cleaned_failed_volume_operations_total
Кількість томів, які були примусово очищені після невдалої реконструкції під час запуску kubelet. Сюди входять як успішні, так і невдалі очищення.
  • ALPHA
  • Counter
garbagecollector_controller_resources_sync_error_total
Кількість помилок синхронізації ресурсів збирача сміття
  • ALPHA
  • Counter
get_token_count
Лічильник загальної кількості запитів Token() до альтернативного джерела токенів
  • ALPHA
  • Counter
get_token_fail_count
Лічильник невдалих запитів Token() до альтернативного джерела токенів
  • ALPHA
  • Counter
horizontal_pod_autoscaler_controller_metric_computation_duration_seconds
Час (у секундах), який контролер HPA витрачає на обчислення однієї метрики. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Мітка 'error' повинна мати значення 'spec', 'internal' або 'none'. Мітка 'metric_type' відповідає HPA.spec.metrics[*].type
  • ALPHA
  • Histogram
  • actionerrormetric_type
horizontal_pod_autoscaler_controller_metric_computation_total
Кількість обчислень метрики. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Також мітка 'error' повинна мати значення 'spec', 'internal' або 'none'. Мітка 'metric_type' відповідає HPA.spec.metrics[*].type
  • ALPHA
  • Counter
  • actionerrormetric_type
horizontal_pod_autoscaler_controller_reconciliation_duration_seconds
Час (у секундах), який потрібен контролеру HPA для одноразового узгодження. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Також мітка 'error' має бути або 'spec', або 'internal', або 'none'. Зауважте, що якщо під час звірки виникають і специфічні, і внутрішні помилки, то в мітці `error` відображається перша з них.
  • ALPHA
  • Histogram
  • actionerror
horizontal_pod_autoscaler_controller_reconciliations_total
Кількість коригувань контролера HPA. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Також мітка 'error' має бути або 'spec', або 'internal', або 'none'. Зверніть увагу, що якщо під час узгодження виникають як специфічні, так і внутрішні помилки, то в мітці `error` відображається перша з них.
  • ALPHA
  • Counter
  • actionerror
job_controller_job_finished_indexes_total
`Кількість готових індексів. Можливі значення для мітки статусу: "successed", "failed". Можливі значення для мітки backoffLimit: "perIndex" та "global"`.
  • ALPHA
  • Counter
  • backoffLimitstatus
job_controller_job_pods_creation_total
`Кількість Podʼів, створених контролером Job, позначених причиною створення Podʼа. Ця метрика також розрізняє Podʼи, створені з використанням різних налаштувань PodReplacementPolicy. Можливі значення мітки "reason": "new", "recreate_terminating_or_failed", "recreate_failed", "recreate_failed". Можливі значення мітки "status": "succeeded", "failed".`
  • ALPHA
  • Counter
  • reasonstatus
job_controller_jobs_by_external_controller_total
Кількість Job, якими керує зовнішній контролер
  • ALPHA
  • Counter
  • controller_name
job_controller_pod_failures_handled_by_failure_policy_total
`Кількість збійних Podʼів, оброблених політикою збоїв, відносно дії політики збоїв, застосованої на основі відповідного правила. Можливі значення мітки дії відповідають можливим значенням дії правила політики відмов, а саме: "FailJob", "Ignore" та "Count".`
  • ALPHA
  • Counter
  • action
job_controller_terminated_pods_tracking_finalizer_total
`Кількість завершених Podʼів (phase=Failed|Successed), які мають завершувач batch.kubernetes.io/job-tracking, Мітка події може бути "add" або "delete".`
  • ALPHA
  • Counter
  • event
kube_apiserver_clusterip_allocator_allocated_ips
Показник, що вимірює кількість виділених IP-адрес для Services
  • ALPHA
  • Gauge
  • cidr
kube_apiserver_clusterip_allocator_allocation_errors_total
Кількість помилок при виділенні кластерних IP-адрес
  • ALPHA
  • Counter
  • cidrscope
kube_apiserver_clusterip_allocator_allocation_total
Кількість розподілених кластерних IP-адрес
  • ALPHA
  • Counter
  • cidrscope
kube_apiserver_clusterip_allocator_available_ips
Показник, що вимірює кількість доступних IP-адрес для Services
  • ALPHA
  • Gauge
  • cidr
kube_apiserver_nodeport_allocator_allocated_ports
Вимірювання кількості виділених NodePorts для Service
  • ALPHA
  • Gauge
kube_apiserver_nodeport_allocator_available_ports
Вимірювання кількості доступних NodePorts для Services
  • ALPHA
  • Gauge
kube_apiserver_pod_logs_backend_tls_failure_total
Загальна кількість запитів до Podʼів/логів, які завершилися невдало через перевірку TLS сервером kubelet
  • ALPHA
  • Counter
kube_apiserver_pod_logs_insecure_backend_total
Загальна кількість запитів до Podʼів/логів за типом використання: enforce_tls, skip_tls_allowed, skip_tls_denied
  • ALPHA
  • Counter
  • usage
kube_apiserver_pod_logs_pods_logs_backend_tls_failure_total
Загальна кількість запитів до Podʼів/логів, які завершилися невдало через перевірку TLS сервера kubelet
  • ALPHA
  • Counter
  • 1.27.0
kube_apiserver_pod_logs_pods_logs_insecure_backend_total
Загальна кількість запитів до Podʼів/логів за типом використання: enforce_tls, skip_tls_allowed, skip_tls_denied
  • ALPHA
  • Counter
  • usage
  • 1.27.0
kubelet_active_pods
Кількість Podʼів, які kubelet вважає активними і які розглядаються при прийнятті нових Podʼів. статичне значення істинне, якщо Pod не від apiserver'а.
  • ALPHA
  • Gauge
  • static
kubelet_certificate_manager_client_expiration_renew_errors
Лічильник помилок поновлення сертифікатів.
  • ALPHA
  • Counter
kubelet_certificate_manager_client_ttl_seconds
Показник TTL (час життя) клієнтського сертифіката Kubelet. Значення в секундах до закінчення терміну дії сертифіката (відʼємне, якщо термін дії вже закінчився). Якщо клієнтський сертифікат недійсний або невикористаний, значення буде +INF.
  • ALPHA
  • Gauge
kubelet_certificate_manager_server_rotation_seconds
Гістограма кількості секунд, які проіснував попередній сертифікат перед ротацією.
  • ALPHA
  • Histogram
kubelet_certificate_manager_server_ttl_seconds
Показник найкоротшого TTL (time-to-live) сертифікату обслуговування Kubelet. Значення в секундах до закінчення терміну дії сертифіката (відʼємне, якщо термін дії вже закінчився). Якщо обслуговуючий сертифікат недійсний або невикористаний, значення буде +INF.
  • ALPHA
  • Gauge
kubelet_cgroup_manager_duration_seconds
Тривалість у секундах для операцій cgroup manager. Розбито за методами.
  • ALPHA
  • Histogram
  • operation_type
kubelet_container_log_filesystem_used_bytes
Байти, що використовуються логами контейнера у файловій системі.
  • ALPHA
  • Custom
  • uidnamespacepodcontainer
kubelet_containers_per_pod_count
Кількість контейнерів на один Pod.
  • ALPHA
  • Histogram
kubelet_cpu_manager_pinning_errors_total
Кількість розподілів ядер процесора, які потребували pinning, зазнали невдачі.
  • ALPHA
  • Counter
kubelet_cpu_manager_pinning_requests_total
Кількість розподілів ядер процесора, які потребували pinning.
  • ALPHA
  • Counter
kubelet_credential_provider_plugin_duration
Тривалість виконання в секундах для втулка постачальника облікових даних
  • ALPHA
  • Histogram
  • plugin_name
kubelet_credential_provider_plugin_errors
Кількість помилок від втулка постачальника облікових даних
  • ALPHA
  • Counter
  • plugin_name
kubelet_desired_pods
Кількість Podʼів, які kubelet має запустити. static має значення true, якщо pod не від apiserverʼа.
  • ALPHA
  • Gauge
  • static
kubelet_device_plugin_alloc_duration_seconds
Тривалість у секундах обслуговування запиту на виділення втулка пристрою. Розбито за назвою ресурсу.
  • ALPHA
  • Histogram
  • resource_name
kubelet_device_plugin_registration_total
Загальна кількість реєстрацій втулків для пристроїв. Розбито за назвою ресурсу.
  • ALPHA
  • Counter
  • resource_name
kubelet_evented_pleg_connection_error_count
Кількість помилок, що виникли під час встановлення потокового зʼєднання з середовищем виконання CRI.
  • ALPHA
  • Counter
kubelet_evented_pleg_connection_latency_seconds
Затримка потокового зʼєднання з процесом виконання CRI, вимірюється в секундах.
  • ALPHA
  • Histogram
kubelet_evented_pleg_connection_success_count
Кількість разів, коли потоковий клієнт отримував події CRI.
  • ALPHA
  • Counter
kubelet_eviction_stats_age_seconds
Час між збором статистики та виселенням Pod на основі цієї статистики за сигналом про виселення
  • ALPHA
  • Histogram
  • eviction_signal
kubelet_evictions
Сумарна кількість виселень Podʼів за сигналом про виселення
  • ALPHA
  • Counter
  • eviction_signal
kubelet_graceful_shutdown_end_time_seconds
Останній час запуску належного припинення роботи програмного забезпечення в секундах unix
  • ALPHA
  • Gauge
kubelet_graceful_shutdown_start_time_seconds
Останній час запуску належного припинення роботи програмного забезпечення в секундах unix
  • ALPHA
  • Gauge
kubelet_http_inflight_requests
Кількість запитів http під час польоту
  • ALPHA
  • Gauge
  • long_runningmethodpathserver_type
kubelet_http_requests_duration_seconds
Тривалість обслуговування http-запитів у секундах
  • ALPHA
  • Histogram
  • long_runningmethodpathserver_type
kubelet_http_requests_total
Кількість http запитів, отриманих з моменту запуску сервера
  • ALPHA
  • Counter
  • long_runningmethodpathserver_type
kubelet_image_garbage_collected_total
Загальна кількість образів, зібраних системою збирання сміття kubelet, незалежно від використання диска або віку образів.
  • ALPHA
  • Counter
  • reason
kubelet_image_pull_duration_seconds
Тривалість у секундах для отримання образу.
  • ALPHA
  • Histogram
  • image_size_in_bytes
kubelet_lifecycle_handler_http_fallbacks_total
The number of times lifecycle handlers successfully fell back to http from https.
  • ALPHA
  • Counter
kubelet_managed_ephemeral_containers
Поточна кількість ефемерних контейнерів у Podʼах, якими керує цей kubelet.
  • ALPHA
  • Gauge
kubelet_memory_manager_pinning_errors_total
Кількість розподілів сторінок памʼяті, які потребували закріплення, що не вдалося.
  • ALPHA
  • Counter
kubelet_memory_manager_pinning_requests_total
Кількість розподілів сторінок памʼяті, які потребували закріплення.
  • ALPHA
  • Counter
kubelet_mirror_pods
Кількість дзеркальних Podʼів, які спробує створити kubelet (по одному на кожен допустимий статичний Pod)
  • ALPHA
  • Gauge
kubelet_node_name
Імʼя вузла. Кількість завжди дорівнює 1.
  • ALPHA
  • Gauge
  • node
kubelet_node_startup_duration_seconds
Тривалість у секундах запуску вузла в цілому.
  • ALPHA
  • Gauge
kubelet_node_startup_post_registration_duration_seconds
Тривалість у секундах запуску вузла після реєстрації.
  • ALPHA
  • Gauge
kubelet_node_startup_pre_kubelet_duration_seconds
Тривалість у секундах запуску вузла до запуску kubelet.
  • ALPHA
  • Gauge
kubelet_node_startup_pre_registration_duration_seconds
Тривалість у секундах запуску вузла перед реєстрацією.
  • ALPHA
  • Gauge
kubelet_node_startup_registration_duration_seconds
Тривалість у секундах запуску вузла під час реєстрації.
  • ALPHA
  • Gauge
kubelet_orphan_pod_cleaned_volumes
Загальна кількість осиротілих Pod, чиї томи були очищені під час останнього періодичного обстеження.
  • ALPHA
  • Gauge
kubelet_orphan_pod_cleaned_volumes_errors
Кількість осиротілих Pod, чиї томи не вдалося очистити під час останнього періодичного обстеження.
  • ALPHA
  • Gauge
kubelet_orphaned_runtime_pods_total
Кількість Podʼів, які були виявлені в середовищі виконання контейнерів, які невідомі для pod worker. Це зазвичай вказує на те, що kubelet був перезапущений під час примусового видалення Pod в API або в локальній конфігурації, що є незвичним.
  • ALPHA
  • Counter
kubelet_pleg_discard_events
Кількість подій відхилення в PLEG (Pod Lifecycle Event Generator).
  • ALPHA
  • Counter
kubelet_pleg_last_seen_seconds
Позначка часу в секундах, коли PLEG востаннє був активний.
  • ALPHA
  • Gauge
kubelet_pleg_relist_duration_seconds
Тривалість у секундах для повторного переліку Podʼів в PLEG.
  • ALPHA
  • Histogram
kubelet_pleg_relist_interval_seconds
Інтервал у секундах між повторними переліками в PLEG.
  • ALPHA
  • Histogram
kubelet_pod_resources_endpoint_errors_get
Кількість запитів до точки доступу PodResource Get, які повернули помилку. Розбито за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_errors_get_allocatable
Кількість запитів до точки доступу PodResource GetAllocatableResources, які повернули помилку. Розбито за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_errors_list
Кількість запитів до точки доступу PodResource List, які повернули помилку. Розбито за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_get
Кількість запитів до точки доступу PodResource Get, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_get_allocatable
Кількість запитів до точки доступу PodResource GetAllocatableResources, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_list
Кількість запитів до точки доступу PodResource List, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_total
Загальна кількість запитів до точки доступу PodResource, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_start_duration_seconds
Тривалість у секундах від першого виявлення kubelet'ом Podʼа до початку його запуску.
  • ALPHA
  • Histogram
kubelet_pod_start_sli_duration_seconds
Тривалість у секундах для запуску Pod, за виключенням часу на завантаження образів та виконання init-контейнерів, виміряна з моменту позначки часу створення Pod до того, як всі його контейнери будуть відзначені як запущені та доступні для спостереження через watch.
  • ALPHA
  • Histogram
kubelet_pod_start_total_duration_seconds
Тривалість у секундах для запуску Pod з моменту створення, включаючи час на завантаження образів та виконання init-контейнерів, виміряна з позначки часу створення Pod до того моменту, коли всі його контейнери будуть відзначені як запущені та доступні для спостережені через watch.
  • ALPHA
  • Histogram
kubelet_pod_status_sync_duration_seconds
Тривалість у секундах синхронізації оновлення статусу Pod. Вимірює час від виявлення зміни статусу Pod до успішного оновлення API для цього Pod, навіть якщо відбулося кілька проміжних змін статусу Pod.
  • ALPHA
  • Histogram
kubelet_pod_worker_duration_seconds
Тривалість у секундах синхронізації одного Pod, розбита за операціями: create, update або sync.
  • ALPHA
  • Histogram
  • operation_type
kubelet_pod_worker_start_duration_seconds
Тривалість у секундах від моменту, коли kubelet виявляє Pod до початку запуску виконавця робочого навантаження.
  • ALPHA
  • Histogram
kubelet_preemptions
Загальна кількість передчасних випереджень Podʼів за ресурсом випередження.
  • ALPHA
  • Counter
  • preemption_signal
kubelet_restarted_pods_total
Кількість Podʼів, які були перезапущені через те, що вони були видалені та створені знову з тим самим UID, поки kubelet відстежував їх (звично для статичних Podʼів, надзвичайно рідко для pod API).
  • ALPHA
  • Counter
  • static
kubelet_run_podsandbox_duration_seconds
Тривалість у секундах операцій run_podsandbox. Розбито за RuntimeClass.Handler.
  • ALPHA
  • Histogram
  • runtime_handler
kubelet_run_podsandbox_errors_total
Загальна кількість помилок операцій run_podsandbox в розрізі RuntimeClass.Handler.
  • ALPHA
  • Counter
  • runtime_handler
kubelet_running_containers
Кількість контейнерів, що зараз працюють.
  • ALPHA
  • Gauge
  • container_state
kubelet_running_pods
Кількість Podʼів, які мають працюючий pod sandbox
  • ALPHA
  • Gauge
kubelet_runtime_operations_duration_seconds
Тривалість у секундах операцій середовища виконання. Розбито за типом операції.
  • ALPHA
  • Histogram
  • operation_type
kubelet_runtime_operations_errors_total
Загальна кількість помилок операцій середовища виконання за типом операції.
  • ALPHA
  • Counter
  • operation_type
kubelet_runtime_operations_total
Загальна кількість операцій середовища виконання за типом операції.
  • ALPHA
  • Counter
  • operation_type
kubelet_server_expiration_renew_errors
Лічильник помилок оновлення сертифікатів.
  • ALPHA
  • Counter
kubelet_sleep_action_terminated_early_total
Кількість разів, коли обробник сну життєвого циклу був завершений до завершення його роботи.
  • ALPHA
  • Counter
kubelet_started_containers_errors_total
Загальна кількість помилок під час запуску контейнерів.
  • ALPHA
  • Counter
  • codecontainer_type
kubelet_started_containers_total
Загальна кількість запущених контейнерів.
  • ALPHA
  • Counter
  • container_type
kubelet_started_host_process_containers_errors_total
Сукупна кількість помилок при запуску контейнерів hostprocess. Ця метрика буде збиратися тільки у Windows.
  • ALPHA
  • Counter
  • codecontainer_type
kubelet_started_host_process_containers_total
Сукупна кількість запущених контейнерів hostprocess. Ця метрика буде збиратися лише у Windows.
  • ALPHA
  • Counter
  • container_type
kubelet_started_pods_errors_total
Сукупна кількість помилок під час запуску Podʼів
  • ALPHA
  • Counter
kubelet_started_pods_total
Сукупна кількість запущених Podʼів
  • ALPHA
  • Counter
kubelet_topology_manager_admission_duration_ms
Тривалість у мілісекундах для обслуговування запиту на допуск Podʼа.
  • ALPHA
  • Histogram
kubelet_topology_manager_admission_errors_total
Кількість відмов запитів допуску, коли не вдалося виділити ресурси.
  • ALPHA
  • Counter
kubelet_topology_manager_admission_requests_total
Кількістьт заявок допуску, для яких потрібне вирівнювання ресурсів.
  • ALPHA
  • Counter
kubelet_volume_metric_collection_duration_seconds
Тривалість у секундах для розрахунку статистики тому
  • ALPHA
  • Histogram
  • metric_source
kubelet_volume_stats_available_bytes
Кількість доступних байт в томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_capacity_bytes
Місткість тому у байтах
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_health_status_abnormal
Статус справності аномального тому. Значення 1 або 0. 1 — означає, що том н є справним, 0 — говорить про справність тому
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_inodes
Максимальна кількість inode в томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_inodes_free
Кількість вільних inode в томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_inodes_used
Кількість використаних inode у томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_used_bytes
Кількість використаних байт у томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_working_pods
Кількість Podʼів, які фактично виконує kubelet, з розбивкою за фазами життєвого циклу, чи є Pod бажаним, осиротілим або тільки для виконання (також осиротілим), а також чи є Pod статичним. Осиротілий Pod був видалений з локальної конфігурації або примусово видалений в API та споживає ресурси, які не є видимими в інших випадках.
  • ALPHA
  • Gauge
  • configlifecyclestatic
kubeproxy_network_programming_duration_seconds
В Cluster Network Programming Latency затримка в секундах
  • ALPHA
  • Histogram
kubeproxy_proxy_healthz_total
Сукупний стан справності проксі-сервера HTTP
  • ALPHA
  • Counter
  • code
kubeproxy_proxy_livez_total
Сукупний стан життєздатності проксі-сервера HTTP
  • ALPHA
  • Counter
  • code
kubeproxy_sync_full_proxy_rules_duration_seconds
Затримка SyncProxyRules у секундах для повних повторних синхронізацій
  • ALPHA
  • Histogram
kubeproxy_sync_partial_proxy_rules_duration_seconds
Затримка SyncProxyRules у секундах для часткових повторних синхронізацій
  • ALPHA
  • Histogram
kubeproxy_sync_proxy_rules_duration_seconds
SyncProxyRules затримка в секундах
  • ALPHA
  • Histogram
kubeproxy_sync_proxy_rules_endpoint_changes_pending
Правила проксі, що очікують на розгляд зміни Endpoint
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_endpoint_changes_total
Кумулятивні проксі-правила зміни Endpoint
  • ALPHA
  • Counter
kubeproxy_sync_proxy_rules_iptables_last
Кількість правил iptables, записаних kube-proxy під час останньої синхронізації
  • ALPHA
  • Gauge
  • table
kubeproxy_sync_proxy_rules_iptables_partial_restore_failures_total
Сукупні помилки часткового відновлення iptables проксі-сервера
  • ALPHA
  • Counter
kubeproxy_sync_proxy_rules_iptables_restore_failures_total
Сукупні помилки відновлення iptables проксі-сервера
  • ALPHA
  • Counter
kubeproxy_sync_proxy_rules_iptables_total
Загальна кількість правил iptables, якими володіє kube-proxy
  • ALPHA
  • Gauge
  • table
kubeproxy_sync_proxy_rules_last_queued_timestamp_seconds
Останній раз, коли синхронізація правил проксі була поставлена в чергу
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_last_timestamp_seconds
Останній раз, коли правила проксі були успішно синхронізовані
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_no_local_endpoints_total
Кількість сервісів з політикою локального трафіку без точок доступу
  • ALPHA
  • Gauge
  • traffic_policy
kubeproxy_sync_proxy_rules_service_changes_pending
Правила проксі в очікувані, що змінюють Service
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_service_changes_total
Сукупні правила проксі в очікувані, що змінюють Service
  • ALPHA
  • Counter
kubernetes_build_info
Метрика з постійним значенням '1', позначена як major, minor, версія git, коміт git, стан дерева git, дата збірки, версія Go, компілятор, з якого було зібрано Kubernetes, та платформа, на якій він працює.
  • ALPHA
  • Gauge
  • build_datecompilergit_commitgit_tree_stategit_versiongo_versionmajorminorplatform
leader_election_master_status
Ознака того, чи є система звітності головною для відповідного lease, 0 вказує на резервну копію, 1 — на головну. "name" — це рядок, який використовується для ідентифікації lease. Будь ласка, згрупуйте за назвою.
  • ALPHA
  • Gauge
  • name
leader_election_slowpath_total
Загальна кількість повільних шляхів, використаних при поновленні leases лідера. 'name' — це рядок, який використовується для ідентифікації lease. Будь ласка, згрупуйте за іменами.
  • ALPHA
  • Counter
  • name
node_authorizer_graph_actions_duration_seconds
Гістограма тривалості дій з графом в авторизаторі вузла.
  • ALPHA
  • Histogram
  • operation
node_collector_unhealthy_nodes_in_zone
Вимірювання кількості не готових вузлів за зонами.
  • ALPHA
  • Gauge
  • zone
node_collector_update_all_nodes_health_duration_seconds
Час у секундах, протягом якого NodeController оновлює стан справності усіх вузлів.
  • ALPHA
  • Histogram
node_collector_update_node_health_duration_seconds
Тривалість у секундах, протягом якої NodeController оновлює стан справності одного вузла.
  • ALPHA
  • Histogram
node_collector_zone_health
Індикатор, що вимірює відсоток справних вузлів у кожній зоні.
  • ALPHA
  • Gauge
  • zone
node_collector_zone_size
Вимірювання кількості зареєстрованих вузлів за зонами.
  • ALPHA
  • Gauge
  • zone
node_controller_cloud_provider_taint_removal_delay_seconds
Кількість секунд після створення вузла, коли NodeController видалив позначку хмарного провайдера з одного вузла.
  • ALPHA
  • Histogram
node_controller_initial_node_sync_delay_seconds
Кількість секунд після створення вузла, коли NodeController завершив початкову синхронізацію одного вузла.
  • ALPHA
  • Histogram
node_ipam_controller_cidrset_allocation_tries_per_request
Кількість точок доступу, доданих під час кожної синхронізації Service
  • ALPHA
  • Histogram
  • clusterCIDR
node_ipam_controller_cidrset_cidrs_allocations_total
Лічильник, що вимірює загальну кількість розподілів CIDR.
  • ALPHA
  • Counter
  • clusterCIDR
node_ipam_controller_cidrset_cidrs_releases_total
Лічильник, що вимірює загальну кількість оновлень CIDR.
  • ALPHA
  • Counter
  • clusterCIDR
node_ipam_controller_cidrset_usage_cidrs
Індикатор, що вимірює відсоток виділених CIDR.
  • ALPHA
  • Gauge
  • clusterCIDR
node_ipam_controller_cirdset_max_cidrs
Максимальна кількість CIDR, яку можна виділити.
  • ALPHA
  • Gauge
  • clusterCIDR
node_swap_usage_bytes
Поточне використання свопу вузла у байтах. Відображається лише на системах, відмінних від Windows
  • ALPHA
  • Custom
number_of_l4_ilbs
Кількість L4 ILBs
  • ALPHA
  • Gauge
  • feature
plugin_manager_total_plugins
Кількість втулків у Plugin Manager
  • ALPHA
  • Custom
  • socket_pathstate
pod_gc_collector_force_delete_pod_errors_total
Кількість помилок, що виникли при примусовому видаленні Podʼів з моменту запуску Pod GC Controller.
  • ALPHA
  • Counter
  • namespacereason
pod_gc_collector_force_delete_pods_total
Кількість Podʼів, які було примусово видалено з моменту запуску контролера Pod GC Controller.
  • ALPHA
  • Counter
  • namespacereason
pod_security_errors_total
Кількість помилок, що перешкоджають нормальній оцінці. Нефатальні помилки можуть призвести до того, що для оцінювання буде використано останній обмежений профіль.
  • ALPHA
  • Counter
  • fatalrequest_operationresourcesubresource
pod_security_evaluations_total
Кількість оцінок політики, що відбулися, не враховуючи проігнорованих або звільнених від розгляду запитів.
  • ALPHA
  • Counter
  • decisionmodepolicy_levelpolicy_versionrequest_operationresourcesubresource
pod_security_exemptions_total
Кількість звільнених запитів, не враховуючи ігнорованих або тих, що виходять за межі області застосування.
  • ALPHA
  • Counter
  • request_operationresourcesubresource
pod_swap_usage_bytes
Поточний обсяг використання підкачки у байтах. Відображається лише на системах, відмінних від Windows
  • ALPHA
  • Custom
  • podnamespace
prober_probe_duration_seconds
Тривалість у секундах для відповіді проби.
  • ALPHA
  • Histogram
  • containernamespacepodprobe_type
prober_probe_total
Сукупна кількість проб життєздатності, готовності або запуску для контейнера в розрізі результатів.
  • ALPHA
  • Counter
  • containernamespacepodpod_uidprobe_typeresult
pv_collector_bound_pv_count
Вимірювач кількості постійного тому, який наразі привʼязаний
  • ALPHA
  • Custom
  • storage_class
pv_collector_bound_pvc_count
Вимірювач кількості поточно привʼязаних persistent volume claim
  • ALPHA
  • Custom
  • namespace
pv_collector_total_pv_count
Вимірювач загальної кількості постійних томів
  • ALPHA
  • Custom
  • plugin_namevolume_mode
pv_collector_unbound_pv_count
Вимірювач кількості постійних томів, що зараз не привʼязані
  • ALPHA
  • Custom
  • storage_class
pv_collector_unbound_pvc_count
Вимірювач кількості не привʼязаних persistent volume claim
  • ALPHA
  • Custom
  • namespace
reconstruct_volume_operations_errors_total
Кількість томів, які не вдалося відновити з операційної системи під час запуску kubelet.
  • ALPHA
  • Counter
reconstruct_volume_operations_total
Кількість томів, які намагалися відновити з операційної системи під час запуску kubelet. Сюди входять як успішні, так і невдалі спроби відновлення.
  • ALPHA
  • Counter
replicaset_controller_sorting_deletion_age_ratio
Відношення віку вибраних видалених Podʼів до поточного наймолодшого віку Podʼів (на даний момент). Має бути менше ніж 2. Мета цієї метрики — виміряти приблизну ефективність впливу функціоналу LogarithmicScaleDown на сортування (і видалення) Podʼів при зменшенні масштабу набору реплік. При обчисленні та створенні звітів враховуються лише готові Podʼи.
  • ALPHA
  • Histogram
resourceclaim_controller_create_attempts_total
Кількість запитів на створення ResourceClaims
  • ALPHA
  • Counter
resourceclaim_controller_create_failures_total
Кількість невдалих запитів на створення ResourceClaims
  • ALPHA
  • Counter
rest_client_dns_resolution_duration_seconds
Затримка DNS-резолвера в секундах. Розбито за хостами.
  • ALPHA
  • Histogram
  • host
rest_client_exec_plugin_call_total
Кількість викликів втулка exec, розділених за типом події, що виникла (no_error, plugin_execution_error, plugin_not_found_error, client_internal_error) та необовʼязковим кодом завершення роботи. Код завершення буде встановлено у 0 тоді і тільки тоді, коли виклик втулка був успішним.
  • ALPHA
  • Counter
  • call_statuscode
rest_client_exec_plugin_certificate_rotation_age
Гістограма кількості секунд, які прожив останній клієнтський сертифікат втулка auth exec до того, як його було ротовано. Якщо клієнтські сертифікати втулка auth exec не використовуються, гістограма не міститиме даних.
  • ALPHA
  • Histogram
rest_client_exec_plugin_ttl_seconds
Показник найкоротшого TTL (часу життя) клієнтських сертифікатів, якими керує втулок auth exec. Значення в секундах до закінчення терміну дії сертифіката (відʼємне, якщо термін дії вже закінчився). Якщо втулки auth exec не використовуються або не керують сертифікатами TLS, значення буде +INF.
  • ALPHA
  • Gauge
rest_client_rate_limiter_duration_seconds
Затримка обмежувача швидкості на стороні клієнта в секундах. Розбито за дієсловами та хостами.
  • ALPHA
  • Histogram
  • hostverb
rest_client_request_duration_seconds
Час затримки запиту в секундах. Розбито за дієсловами та хостами.
  • ALPHA
  • Histogram
  • hostverb
rest_client_request_retries_total
Кількість повторних спроб запиту, з розподілом за кодом статусу, дієсловом та хостом.
  • ALPHA
  • Counter
  • codehostverb
rest_client_request_size_bytes
Розмір запиту в байтах. Розбито за дієсловом та хостом.
  • ALPHA
  • Histogram
  • hostverb
rest_client_requests_total
Кількість HTTP-запитів, розділених за кодом статусу, методом та хостом.
  • ALPHA
  • Counter
  • codehostmethod
rest_client_response_size_bytes
Розмір відповіді в байтах. Розбито за дієсловом та хостом.
  • ALPHA
  • Histogram
  • hostverb
rest_client_transport_cache_entries
Кількість транспортних записів у внутрішньому кеші.
  • ALPHA
  • Gauge
rest_client_transport_create_calls_total
Кількість викликів для отримання нового транспорту, розділена за результатом операції hit: отримано з кешу, miss: створено та додано до кешу, uncacheable: створено та не кешовано
  • ALPHA
  • Counter
  • result
retroactive_storageclass_errors_total
Загальна кількість невдалих ретроактивних присвоєнь StorageClass до persistent volume claim
  • ALPHA
  • Counter
retroactive_storageclass_total
Загальна кількість ретроактивних присвоєнь StorageClass для persistent volume claim
  • ALPHA
  • Counter
root_ca_cert_publisher_sync_duration_seconds
Кількість синхронізацій просторів імен, що відбулися у видавця сертифікатів root ca.
  • ALPHA
  • Histogram
  • code
root_ca_cert_publisher_sync_total
Кількість синхронізацій просторів імен, що відбулися у видавця сертифікатів root ca.
  • ALPHA
  • Counter
  • code
running_managed_controllers
Показує, де зараз запущено екземпляри контролера
  • ALPHA
  • Gauge
  • managername
scheduler_goroutines
Кількість запущених підпрограм, розділених за роботою, яку вони виконують, наприклад, звʼязуванням.
  • ALPHA
  • Gauge
  • operation
scheduler_permit_wait_duration_seconds
Тривалість очікування на отримання дозволу.
  • ALPHA
  • Histogram
  • result
scheduler_plugin_evaluation_total
Кількість спроб запланувати Podʼи для кожного втулка і точки розширення (доступно тільки в PreFilter, Filter, PreScore і Score).
  • ALPHA
  • Counter
  • extension_pointpluginprofile
scheduler_plugin_execution_duration_seconds
Тривалість запуску втулка в певній точці розширення.
  • ALPHA
  • Histogram
  • extension_pointpluginstatus
scheduler_scheduler_cache_size
Кількість вузлів, Podʼів та передбачуваних (звʼязаних) Podʼів у кеші планувальника.
  • ALPHA
  • Gauge
  • type
scheduler_scheduling_algorithm_duration_seconds
Затримка алгоритму планування в секундах
  • ALPHA
  • Histogram
scheduler_unschedulable_pods
Кількість незапланованих Podʼів, розбитих за назвою втулка. Pod збільшує показник для всіх втулків, які спричинили його незапланованість, тому ця метрика має сенс лише у розбивці за втулками.
  • ALPHA
  • Gauge
  • pluginprofile
scheduler_volume_binder_cache_requests_total
Загальна кількість запитів кешу привʼязування томів
  • ALPHA
  • Counter
  • operation
scheduler_volume_scheduling_stage_error_total
Кількість помилок на етапі планування томів
  • ALPHA
  • Counter
  • operation
scrape_error
1, якщо виникла помилка при отриманні метрик контейнера, 0 в іншому випадку
  • ALPHA
  • Custom
  • 1.29.0
service_controller_loadbalancer_sync_total
Метрика, що підраховує кількість разів, коли був налаштований будь-який балансувальник навантаження, як наслідок зміни сервісу/вузла на кластері
  • ALPHA
  • Counter
service_controller_nodesync_error_total
Метрика, яка підраховує кількість разів, коли будь-який балансувальник навантаження був налаштований і помилявся, як наслідок зміни вузлів у кластері
  • ALPHA
  • Counter
service_controller_nodesync_latency_seconds
Метрика, що вимірює затримку синхронізації вузлів, яка оновлює хости балансувальника навантаження при оновленні вузлів кластера.
  • ALPHA
  • Histogram
service_controller_update_loadbalancer_host_latency_seconds
Метрика, що вимірює затримку оновлення кожного з хостів балансувальника навантаження.
  • ALPHA
  • Histogram
serviceaccount_invalid_legacy_auto_token_uses_total
Використання сукупних недійсних автоматично згенерованих застарілих токенів
  • ALPHA
  • Counter
serviceaccount_legacy_auto_token_uses_total
Використання сукупних автоматично згенерованих застарілих токенів
  • ALPHA
  • Counter
serviceaccount_legacy_manual_token_uses_total
Використання сукупних вручну створених застарілих токенів
  • ALPHA
  • Counter
serviceaccount_legacy_tokens_total
Використані токени застарілих службових облікових записів
  • ALPHA
  • Counter
serviceaccount_stale_tokens_total
Використані токени службових облікових записів з простроченим терміном придатності
  • ALPHA
  • Counter
serviceaccount_valid_tokens_total
Використання дійсних токенів проєцьованих службових облікових записів
  • ALPHA
  • Counter
storage_count_attachable_volumes_in_use
Підрахунок кількості використовуваних томів
  • ALPHA
  • Custom
  • nodevolume_plugin
storage_operation_duration_seconds
Тривалість операції зберігання
  • ALPHA
  • Histogram
  • migratedoperation_namestatusvolume_plugin
taint_eviction_controller_pod_deletion_duration_seconds
Затримка, в секундах, між моментом активації ефекту заплямування (taint) для Pod і його видаленням через TaintEvictionController.
  • ALPHA
  • Histogram
taint_eviction_controller_pod_deletions_total
Загальна кількість Podʼів, видалених TaintEvictionController з моменту його запуску.
  • ALPHA
  • Counter
ttl_after_finished_controller_job_deletion_duration_seconds
Час, необхідний для видалення завдання (job) з моменту, коли воно стало доступним для видалення
  • ALPHA
  • Histogram
volume_manager_selinux_container_errors_total
Кількість помилок, коли kubelet не може обчислити контекст SELinux для контейнера. Kubelet не зможе запустити такий Pod і спробує ще раз, тому значення цієї метрики може не відповідати дійсній кількості контейнерів.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_container_warnings_total
Кількість помилок, коли kubelet не може обчислити контекст SELinux для контейнера, які ігноруються. Вони стануть справжніми помилками, коли функцію SELinuxMountReadWriteOncePod буде розширено на всі режими доступу до томів.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_pod_context_mismatch_errors_total
Кількість помилок, коли Pod визначає різні контексти SELinux для своїх контейнерів, які використовують однаковий обʼєм. Kubelet не зможе запустити такий Pod і спробує ще раз, тому значення цієї метрики може не відповідати дійсній кількості Podʼів.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_pod_context_mismatch_warnings_total
Кількість помилок, коли Pod визначає різні контексти SELinux для своїх контейнерів, які використовують той самий том. Це ще не помилки, але вони стануть справжніми помилками, коли можливість SELinuxMountReadWriteOncePod буде розширено на всі режими доступу до тома.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_volume_context_mismatch_errors_total
Кількість помилок, коли Pod використовує том, який вже змонтовано з іншим контекстом SELinux, ніж потрібен Pod. Kubelet не зможе запустити такий Pod і повторити спробу, тому значення цієї метрики може не відповідати дійсній кількості Podʼів.
  • ALPHA
  • Gauge
  • access_modevolume_plugin
volume_manager_selinux_volume_context_mismatch_warnings_total
Кількість помилок, коли Pod використовує том, який вже змонтовано з іншим контекстом SELinux, ніж потрібен Pod. Це ще не помилки, але вони стануть справжніми помилками, коли функцію SELinuxMountReadWriteOncePod буде розширено на всі режими доступу до томів.
  • ALPHA
  • Gauge
  • access_modevolume_plugin
volume_manager_selinux_volumes_admitted_total
Кількість томів, контекст SELinux яких був нормальним і які буде змонтовано за допомогою параметра контексту mount -o.
  • ALPHA
  • Gauge
  • access_modevolume_plugin
volume_manager_total_volumes
Кількість томів у Volume Manager
  • ALPHA
  • Custom
  • plugin_namestate
volume_operation_total_errors
Всього помилок в роботі з томом
  • ALPHA
  • Counter
  • operation_nameplugin_name
volume_operation_total_seconds
Тривалість операції зберігання від початку до кінця в секундах
  • ALPHA
  • Histogram
  • operation_nameplugin_name
watch_cache_capacity
Загальний обсяг кешу watch, розбитий за типами ресурсів.
  • ALPHA
  • Gauge
  • resource
watch_cache_capacity_decrease_total
Загальна кількість подій зменшення ємності кешу watch, з розбивкою за типами ресурсів.
  • ALPHA
  • Counter
  • resource
watch_cache_capacity_increase_total
Загальна кількість подій збільшення ємності кешу watch, з розбивкою за типами ресурсів.
  • ALPHA
  • Counter
  • resource
workqueue_adds_total
Загальна кількість додавань, оброблених робочою чергою
  • ALPHA
  • Counter
  • name
workqueue_depth
Поточна глибина робочої черги
  • ALPHA
  • Gauge
  • name
workqueue_longest_running_processor_seconds
Скільки секунд працював найдовший процесор у черзі.
  • ALPHA
  • Gauge
  • name
workqueue_queue_duration_seconds
Скільки часу в секундах елемент перебуває в черзі до того, як його буде запитано.
  • ALPHA
  • Histogram
  • name
workqueue_retries_total
Загальна кількість повторних спроб, оброблених робочою чергою
  • ALPHA
  • Counter
  • name
workqueue_unfinished_work_seconds
Скільки секунд роботи було виконано, яка виконується і не спостерігається параметром work_duration. Великі значення вказують на застряглі потоки. Про кількість застряглих потоків можна зробити висновок, спостерігаючи за швидкістю, з якою цей показник зростає.
  • ALPHA
  • Gauge
  • name
workqueue_work_duration_seconds
Скільки часу в секундах займає обробка елемента з робочої черги.
  • ALPHA
  • Histogram
  • name

7 - Безпека та проблеми Kubernetes

7.1 - Трекер проблем Kubernetes

Для повідомлення про проблему безпеки використовуйте Процес розкриття інформації про безпеку в Kubernetes.

Робота з кодом Kubernetes та публічними проблемами відстежуватися за допомогою GitHub Issues.

Повідомлення про безпеку надсилаються у список розсилки kubernetes-security-announce@googlegroups.com.

7.2 - Процес розкриття інформації про безпеку в Kubernetes

Ця сторінка описує процес розкриття інформації про безпеку в Kubernetes.

Оголошення з питань безпеки

Приєднуйтесь до групи kubernetes-security-announce, щоб отримувати електронні листи щодо безпеки та основних оголошень API.

Повідомлення про вразливості

Ми дуже вдячні фахівцям з безпеки та користувачам, які повідомляють про вразливості Kubernetes Open Source Community. Всі звіти ретельно розглядаються командою волонтерів спільноти.

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

Ви також можете надіслати електронного листа на приватну адресу security@kubernetes.io з деталями щодо безпеки та необхідними деталями для всіх звітів про помилки Kubernetes.

Ви можете зашифрувати свій лист для цього списку за допомогою GPG-ключів членів комітету з питань реагування на загрози безпеці. Шифрування за допомогою GPG НЕ є обовʼязковим для повідомлення про проблеми з безпекою.

Коли потрібно повідомляти про вразливість?

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

Коли НЕ потрібно повідомляти про вразливість?

  • Вам потрібна допомога у налаштуванні компонентів Kubernetes для безпеки
  • Вам потрібна допомога з застосуванням оновлень, повʼязаних з безпекою
  • Ваша проблема не стосується безпеки

Реагування на вразливості безпеки

Кожне повідомлення отримує відповідь та аналіз від членів комітету з питань реагування на загрози безпеці протягом 3 робочих днів. Це ініціює Security Release Process.

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

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

Терміни оприлюднення інформації

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

7.3 - Офіційний список CVE

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [beta]

Це список офіційних CVE, оголошених Комітетом з питань реагування на загрози безпеці Kubernetes. Детальніше дивіться в Процес розкриття інформації про безпеку в Kubernetes.

Проєкт Kubernetes публікує програмно доступний потік опублікованих проблем безпеки у форматах JSON feed та RSS feed. Ви можете отримати до них доступ, виконавши наступні команди:

Посилання на формат JSON

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Посилання на формат RSS

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml
Офіційний перелік Kubernetes CVE (оновлено: 07 лист. 2024 15:43:14 UTC)
CVE IDОпис проблемиCVE на GitHub
CVE-2024-9594VM images built with Image Builder with some providers use default credentials during builds#128007
CVE-2024-9486VM images built with Image Builder and Proxmox provider use default credentials#128006
CVE-2024-7646Ingress-nginx Annotation Validation Bypass#126744
CVE-2024-5321Incorrect permissions on Windows containers logs#126161
CVE-2024-3744azure-file-csi-driver discloses service account tokens in logs#124759
CVE-2024-3177Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin#124336
CVE-2023-5528Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes#121879
CVE-2023-5044Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation#126817
CVE-2023-5043Ingress nginx annotation injection causes arbitrary command execution#126816
CVE-2022-4886ingress-nginx path sanitization can be bypassed#126815
CVE-2023-3955Insufficient input sanitization on Windows nodes leads to privilege escalation#119595
CVE-2023-3893Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation#119594
CVE-2023-3676Insufficient input sanitization on Windows nodes leads to privilege escalation#119339
CVE-2023-2431Bypass of seccomp profile enforcement#118690
CVE-2023-2728Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin#118640
CVE-2023-2727Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin#118640
CVE-2023-2878secrets-store-csi-driver discloses service account tokens in logs#118419
CVE-2022-3294Node address isn't always verified when proxying#113757
CVE-2022-3162Unauthorized read of Custom Resources#113756
CVE-2022-3172Aggregated API server can cause clients to be redirected (SSRF)#112513
CVE-2021-25749`runAsNonRoot` logic bypass for Windows containers#112192
CVE-2021-25748Ingress-nginx `path` sanitization can be bypassed with newline character#126814
CVE-2021-25746Ingress-nginx directive injection via annotations#126813
CVE-2021-25745Ingress-nginx `path` can be pointed to service account token file#126812
CVE-2021-25742Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces#126811
CVE-2021-25741Symlink Exchange Can Allow Host Filesystem Access#104980
CVE-2021-25737Holes in EndpointSlice Validation Enable Host Network Hijack#102106
CVE-2021-3121Processes may panic upon receipt of malicious protobuf messages#101435
CVE-2021-25735Validating Admission Webhook does not observe some previous fields#100096
CVE-2020-8554Man in the middle using LoadBalancer or ExternalIPs#97076
CVE-2020-8566Ceph RBD adminSecrets exposed in logs when loglevel >= 4#95624
CVE-2020-8565Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9#95623
CVE-2020-8564Docker config secrets leaked when file is malformed and log level >= 4#95622
CVE-2020-8563Secret leaks in kube-controller-manager when using vSphere provider#95621
CVE-2020-8557Node disk DOS by writing to container /etc/hosts#93032
CVE-2020-8559Privilege escalation from compromised node to cluster#92914
CVE-2020-8558Node setting allows for neighboring hosts to bypass localhost boundary#92315
CVE-2020-8555Half-Blind SSRF in kube-controller-manager#91542
CVE-2020-10749IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements#91507
CVE-2019-11254kube-apiserver Denial of Service vulnerability from malicious YAML payloads#89535
CVE-2020-8552apiserver DoS (oom)#89378
CVE-2020-8551Kubelet DoS via API#89377
CVE-2020-8553ingress-nginx auth-type basic annotation vulnerability#126818
CVE-2019-11251kubectl cp symlink vulnerability#87773
CVE-2018-1002102Unvalidated redirect#85867
CVE-2019-11255CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation#85233
CVE-2019-11253Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack#83253
CVE-2019-11250Bearer tokens are revealed in logs#81114
CVE-2019-11248/debug/pprof exposed on kubelet's healthz port#81023
CVE-2019-11249Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal#80984
CVE-2019-11247API server allows access to custom resources via wrong scope#80983
CVE-2019-11245container uid changes to root after first restart or if image is already pulled to the node#78308
CVE-2019-11243rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig()#76797
CVE-2019-11244`kubectl:-http-cache=<world-accessible dir>` creates world-writeable cached schema files#76676
CVE-2019-1002100json-patch requests can exhaust apiserver resources#74534
CVE-2018-1002105proxy request handling in kube-apiserver can leave vulnerable TCP connections#71411
CVE-2018-1002101smb mount security issue#65750
CVE-2018-1002100Kubectl copy doesn't check for paths outside of it's destination directory.#61297
CVE-2017-1002102atomic writer volume handling allows arbitrary file deletion in host filesystem#60814
CVE-2017-1002101subpath volume mount handling allows arbitrary file access in host filesystem#60813
CVE-2017-1002100Azure PV should be Private scope not Container scope#47611
CVE-2017-1000056PodSecurityPolicy admission plugin authorizes incorrectly#43459

Цей потік автоматично оновлюється з помітними, але невеликими затримками (від хвилин до годин) від моменту оголошення CVE до доступу до нього у цьому потоці.

Джерелом інформації для цього потоку є набір GitHub Issues, відфільтрованих за міткою official-cve-feed. Сирі дані зберігаються у сховищі Google Cloud, до якого мають доступ лише декілька довірених членів спільноти.

8 - Довідкова інформація про вузли

У цьому розділі містяться наступні теми про вузли:

Ви також можете ознайомитись з довідкою про вузли в інших розділах документації Kubernetes, зокрема:

8.1 - Kubelet Checkpoint API

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta] (стандартно увімкнено: true)

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

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

Створення копії контейнера зі станом може мати наслідки для безпеки. Зазвичай така копія містить усі сторінки памʼяті всіх процесів у контейнері. Це означає, що все, що колись було в памʼяті, тепер доступне на локальному диску. Це включає всі приватні дані та можливі ключі, які використовувались для шифрування. Реалізації CRI повинні створювати архів копії зі збереженням стану таким чином, щоб до нього міг мати доступ лише користувач root. Важливо памʼятати, що якщо архів копії зі збереженням стану передається в іншу систему, усі сторінки памʼяті будуть доступні власнику архіву копії.

Операції

post створення копії зі збереженням стану вказаного контейнера

Дайте команду kubelet створити копію зі збереженням стану конкретного контейнера з вказаного Pod.

Для отримання додаткової інформації щодо керування доступом до інтерфейсу контролю kubelet дивіться довідку з автентифікації/авторизації kubelet.

Kubelet запитає контрольну точку у відповідного CRI. У запиті до контрольної точки kubelet вкаже імʼя архіву контрольної точки у вигляді checkpoint-<podFullName>-<containerName>-<timestamp>.tar, а також попросить зберігати архів контрольних точок у теці checkpoints в його кореневій теці (як визначено параметром --root-dir). Типово це буде /var/lib/kubelet/checkpoints.

Архів копії зі збереженням стану має формат tar і може бути переглянутий за допомогою реалізації tar. Вміст архіву залежить від реалізації CRI (інтерфейс запуску контейнерів на вузлі).

HTTP-запит

POST /checkpoint/{namespace}/{pod}/{container}

Параметри

  • namespace (в шляху): string, обовʼязково

    Namespace

  • pod (в шляху): string, обовʼязково

    Pod

  • container (в шляху): string, обовʼязково

    Контейнер

  • timeout (в запиті): integer

    Тайм-аут у секундах для очікування завершення створення копії зі збереженням стану. Якщо вказано нуль або тайм-аут не вказано, буде використане стандартне значення тайм-ауту для CRI. Час створення копії зі збереженням стану залежить безпосередньо від використаної памʼяті контейнера. Чим більше памʼяті використовує контейнер, тим більше часу потрібно для створення відповідної копії зі збереженням стану.

Відповідь

200: OK

401: Unauthorized

404: Not Found (якщо функціональні можливості ContainerCheckpoint відключено)

404: Not Found (якщо вказаний namespace, pod або container не може бути знайдено)

500: Internal Server Error (якщо реалізація CRI стикається з помилкою під час створення копії зі збереженням стану (див. повідомлення про помилку для деталей))

500: Internal Server Error (якщо реалізація CRI не реалізує API створення контейнера (див. повідомлення про помилку для деталей))

8.2 - Вимоги до версії ядра Linux

Багато функцій залежать від певних можливостей ядра і мають мінімальні вимоги до версії ядра. Однак покладатися лише на номери версій ядра може бути недостатньо для деяких операційних систем, оскільки підтримувачі дистрибутивів таких як RHEL, Ubuntu та SUSE часто зворотно переносять вибрані функції до старіших версій ядра (залишаючи старішу версію ядра).

Pod sysctls

У Linux системний виклик sysctl() налаштовує параметри ядра під час виконання. Є інструмент командного рядка з назвою sysctl, який можна використовувати для налаштування цих параметрів, і багато з них доступні через файлову систему proc.

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

Наступні sysctls мають мінімальні вимоги до версії ядра і підтримуються в безпечному наборі:

  • net.ipv4.ip_local_reserved_ports (з Kubernetes 1.27, потребує ядро 3.16+);
  • net.ipv4.tcp_keepalive_time (з Kubernetes 1.29, потребує ядро 4.5+);
  • net.ipv4.tcp_fin_timeout (з Kubernetes 1.29, потребує ядро 4.6+);
  • net.ipv4.tcp_keepalive_intvl (з Kubernetes 1.29, потребує ядро 4.5+);
  • net.ipv4.tcp_keepalive_probes (з Kubernetes 1.29, потребує ядро 4.5+);
  • net.ipv4.tcp_syncookies (з ізоляцією в просторі імен з ядра 4.6+);
  • net.ipv4.vs.conn_reuse_mode (використовується в режимі проксі ipvs, потребує ядро 4.1+);

Режим проксі nftables в kube-proxy

Для Kubernetes 1.31, режим nftables у kube-proxy вимагає версії 1.0.1 або новішої версії інструменту командного рядка nft, а також ядра 5.13 або новішого.

Для тестування та розробки можна використовувати старіші ядра, аж до 5.4, якщо встановити опцію nftables.skipKernelVersionCheck у конфігурації kube-proxy. Але це не рекомендується в операційній діяльності, оскільки це може викликати проблеми з іншими користувачами nftables у системі.

Контрольні групи версії 2

Підтримка cgroup v1 у Kubernetes перебуває в режимі супроводу, починаючи з версії Kubernetes v1.31; рекомендовано використовувати cgroup v2. У Linux 5.8, файл системного рівня cpu.stat був доданий до кореневої cgroup для зручності.

У документації runc, ядра старіші за 5.2 не рекомендуються через відсутність підтримки freezer.

Інші вимоги до ядра

Деякі функції можуть залежати від нових можливостей ядра і мати конкретні вимоги до ядра:

  1. Рекурсивне монтування в режимі тільки для читання: Реалізується шляхом застосування атрибута MOUNT_ATTR_RDONLY із прапором AT_RECURSIVE, використовуючи mount_setattr(2), доданий у ядрі Linux v5.12.
  2. Підтримка простору імен користувачів в Pod вимагає мінімальної версії ядра 6.5+, згідно з KEP-127.
  3. Для swap на рівні вузлів не підтримується tmpfs, встановлений як noswap, до версії ядра 6.3.

Довгострокова підтримка ядра Linux

Актуальні випуски ядра можна знайти на kernel.org.

Зазвичай існує кілька випусків ядра з довгостроковою підтримкою, які забезпечують зворотне перенесення виправлень для старіших версій ядра. До таких ядер застосовуються лише важливі виправлення помилок, і вони зазвичай виходять не дуже часто, особливо для старіших версій. Перегляньте список випусків на вебсайті ядра Linux в розділі Longterm.

Що далі

  • Перегляньте sysctls для отримання додаткової інформації.
  • Дозвольте запуск kube-proxy у режимі nftables.
  • Дізнайтесь більше про cgroups v2.

8.3 - Статті про видалення dockershim та використання сумісних з CRI середовищ виконання

Це список статей й інших сторінок, що стосуються видалення dockershim у Kubernetes та використання сумісних з CRI контейнерних середовищ виконання у звʼязку з цим видаленням.

Проєкт Kubernetes

Можна надати відгуки через тікет GitHub Відгуки та проблеми видалення Dockershim (k/kubernetes/#106917).

Зовнішні джерела

8.4 - Мітки вузлів, які заповнює kubelet

Вузли Kubernetes мають попередньо встановлений набір міток.

Ви також можете встановлювати власні мітки на вузлах, як через конфігурацію kubelet, так і використовуючи API Kubernetes.

Попередньо встановлені мітки

Попередньо встановлені мітки, які Kubernetes встановлює на вузли:

Що далі

8.5 - Локальні файли та шляхи, які використовує Kubelet

kubelet — це переважно процес без збереження стану, який працює на вузлі Kubernetes. У цьому документі описані файли, які kubelet читає та записує.

Зазвичай, kubelet використовує панель управління як джерело істини про те, що повинно запускатися на вузлі, і середовище виконання контейнерів для отримання поточного стану контейнерів. За наявності kubeconfig (конфігурації клієнта API), kubelet підключається до панелі управління; інакше вузол працює в автономному режимі.

На Linux-вузлах kubelet також читає cgroups та різні системні файли для збору метрик.

На Windows-вузлах kubelet збирає метрики іншим механізмом, що не спирається на шляхи.

Є також кілька інших файлів, які використовуються kubelet, і kubelet спілкується за допомогою локальних сокетів Unix-домену. Деякі з них — це сокети, на яких слухає kubelet, а інші — сокети, які kubelet виявляє та підключається до них як клієнт.

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

Конфігураційні файли kubelet

Шлях до конфігураційного файлу kubelet можна налаштувати за допомогою командного аргументу --config. Kubelet також підтримує доповнювані конфігураційні файли для розширення налаштувань.

Сертифікати

Сертифікати та приватні ключі зазвичай розташовані в /var/lib/kubelet/pki, але цей шлях можна налаштувати за допомогою командного аргументу kubelet --cert-dir. Імена файлів сертифікатів також можна налаштувати.

Маніфести

Маніфести для статичних Podʼів зазвичай розташовані в /etc/kubernetes/manifests. Місце розташування можна налаштувати за допомогою опції конфігурації kubelet staticPodPath.

Налаштування юнітів systemd

Коли kubelet працює як юніт systemd, деякі налаштування kubelet можуть бути визначені в файлі налаштувань systemd. Зазвичай це включає:

  • командні аргументи для запуску kubelet
  • змінні середовища, що використовуються kubelet або для налаштування середовища golang

Стан

Файли контрольних точок для менеджерів ресурсів

Усі менеджери ресурсів зберігають відповідність між Podʼами та виділеними ресурсами у файлах стану. Ці файли розташовані в базовій теці kubelet, також відомій як root directory (але це не те саме, що /, коренева тека вузла). Ви можете налаштувати базову теку для kubelet за допомогою аргументу командного рядка --root-dir.

Назви файлів:

  • memory_manager_state для менеджера пам’яті
  • cpu_manager_state для менеджера процесорів
  • dra_manager_state для DRA

Файл контрольної точки для менеджера пристроїв

Менеджер пристроїв створює контрольні точки в тій самій теці, що й сокет-файли: /var/lib/kubelet/device-plugins/. Назва файлу контрольної точки — kubelet_internal_checkpoint для менеджера пристроїв.

Збереження стану Podʼів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [alpha] (стандартно увімкнено: false)

Якщо ваш кластер має вертикальне масштабування Podʼа на місці увімкнено (функціональна можливість з назвою InPlacePodVerticalScaling), тоді kubelet зберігає локальний запис про стан Podʼа.

Імʼя файлу — pod_status_manager_state у базовій теці kubelet (/var/lib/kubelet стандартно в Linux; налаштовується за допомогою --root-dir).

Середовище виконання контейнерів

Kubelet спілкується з середовищем виконання контейнерів за допомогою сокета, налаштованого через такі параметри конфігурації:

  • containerRuntimeEndpoint для операцій із середовищем виконання
  • imageServiceEndpoint для операцій з управління образами

Фактичні значення цих точок доступу залежать від середовища виконання контейнерів, яке використовується.

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

Kubelet відкриває сокет за шляхом /var/lib/kubelet/device-plugins/kubelet.sock для різних втулків пристроїв, які реєструються.

Коли втулок пристрою реєструється, він надає шлях до свого сокета, щоб kubelet міг підʼєднатися.

Сокет втулка пристрою повинен знаходитися в теці device-plugins у базовій теці kubelet. На типовому Linux-вузлі це означає /var/lib/kubelet/device-plugins.

API ресурсів Podʼів

API ресурсів Podʼів буде доступний за шляхом /var/lib/kubelet/pod-resources.

DRA, CSI та втулки пристроїв

Kubelet шукає сокет-файли, створені втулками пристроїв, керованими через DRA, менеджер пристроїв або втулки зберігання, а потім намагається приєднатись до цих сокетів. Текою, у якій kubelet шукає, є plugins_registry у базовій теці kubelet, тобто на типовому Linux-вузлі це — /var/lib/kubelet/plugins_registry.

Зверніть увагу, що для втулків пристроїв є два альтернативні механізми реєстрації. Тільки один із них повинен використовуватися для певного втулка.

Типи втулків, які можуть розміщувати сокет-файли в цій теці:

  • втулки CSI
  • втулки DRA
  • втулки менеджера пристроїв

(зазвичай /var/lib/kubelet/plugins_registry).

Профілі безпеки та конфігурація

Seccomp

Файли профілів seccomp, на які посилаються Podʼи, мають бути розміщені стандартно у /var/lib/kubelet/seccomp. Дивіться довідку Seccomp для деталей.

AppArmor

Kubelet не завантажує і не звертається до профілів AppArmor за специфічним для Kubernetes шляхом. Профілі AppArmor завантажуються через операційну систему вузла, а не посилаються за їх шляхом.

Блокування

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.2 [alpha]

Файл блокування для kubelet зазвичай знаходиться за адресою /var/run/kubelet.lock. Kubelet використовує цей файл для того, щоб два різні екземпляри kubelet не намагалися працювати у конфлікті одна одної. Ви можете налаштувати шлях до файлу блокування, використовуючи аргумент командного рядка kubelet --lock-file.

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

Що далі

8.6 - Версії API Kubelet Device Manager

Ця сторінка надає інформацію про сумісність між API втулків пристроїв Kubernetes та різними версіями самого Kubernetes.

Матриця сумісності

v1alpha1v1beta1
Kubernetes 1.21-✓
Kubernetes 1.22-✓
Kubernetes 1.23-✓
Kubernetes 1.24-✓
Kubernetes 1.25-✓
Kubernetes 1.26-✓

Позначення:

  • ✓ Точно такі ж функції / обʼєкти API в обох, API втулка пристроїв та версії Kubernetes.
  • + API втулка пристроїв має функції або обʼєкти API, яких може не бути в кластері Kubernetes, або через те, що API втулка пристроїв додало додаткові нові виклики API, або через те, що сервер видалив старий виклик API. Однак, все, що у них є спільного (більшість інших API), працюватиме. Зверніть увагу, що альфа-версії API можуть зникнути або значно змінитися між незначними релізами.
  • - Кластер Kubernetes має функції, які не може використовувати API втулка пристроїв, або через те, що сервер додав додаткові виклики API, або через те, що API втулка пристроїв видалило старий виклик API. Однак, все, що у них є спільного (більшість API), працюватиме.

8.7 - Обʼєднання конфігураційних тек Kubelet

Коли використовується прапорець kubelet --config-dir для вказівки теки для конфігурації, існує певна специфічна поведінка для обʼєднання різних типів.

Ось кілька прикладів того, як різні типи даних поводяться під час обʼєднання конфігурації:

Поля структур

У YAML структурі є два типи полів структури: одиничні (або скалярні типи) та вбудовані (структури, що містять скалярні типи). Процес обʼєднання конфігурацій обробляє заміну одиничних та вбудованих полів структур для створення кінцевої конфігурації kubelet.

Наприклад, ви можете хотіти мати базову конфігурацію kubelet для всіх вузлів, але налаштувати поля address і authorization. Це можна зробити наступним чином:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: "5m"
    cacheUnauthorizedTTL: "30s"
serializeImagePulls: false
address: "192.168.0.1"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: AlwaysAllow
  webhook:
    cacheAuthorizedTTL: "8m"
    cacheUnauthorizedTTL: "45s"
address: "192.168.0.8"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
authorization:
  mode: AlwaysAllow
  webhook:
    cacheAuthorizedTTL: "8m"
    cacheUnauthorizedTTL: "45s"
address: "192.168.0.8"

Списки

Ви можете замінити значення списків конфігурації kubelet. Однак весь список буде замінений під час процесу обʼєднання. Наприклад, ви можете замінити список clusterDNS наступним чином:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
clusterDNS:
  - "192.168.0.9"
  - "192.168.0.8"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
  - "192.168.0.2"
  - "192.168.0.3"
  - "192.168.0.5"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
clusterDNS:
  - "192.168.0.2"
  - "192.168.0.3"
  - "192.168.0.5"

Map, включаючи вкладені структури

Індивідуальні поля в map, незалежно від їх типів значень (булеві, рядкові тощо), можуть бути вибірково замінені. Однак для map[string][]string весь список, повʼязаний з певним полем, буде замінений. Розглянемо це детальніше на прикладі, зокрема для таких полів, як featureGates і staticPodURLHeader:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
featureGates:
  AllAlpha: false
  MemoryQoS: true
staticPodURLHeader:
  kubelet-api-support:
  - "Authorization: 234APSDFA"
  - "X-Custom-Header: 123"
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 456"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: false
  KubeletTracing: true
  DynamicResourceAllocation: true
staticPodURLHeader:
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 345"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
featureGates:
  AllAlpha: false
  MemoryQoS: false
  KubeletTracing: true
  DynamicResourceAllocation: true
staticPodURLHeader:
  kubelet-api-support:
  - "Authorization: 234APSDFA"
  - "X-Custom-Header: 123"
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 345"

8.8 - Seccomp та Kubernetes

Seccomp (secure computing mode) — це функція ядра Linux, яка існує з версії 2.6.12. Її можна використовувати для обмеження привілеїв процесу шляхом ізоляції, обмежуючи системні виклики, які він може здійснювати з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів і контейнерів.

Поля Seccomp

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

Існує чотири способи вказати профіль seccomp для Podʼа:

pods/security/seccomp/fields.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
  ephemeralContainers:
  - name: ephemeral-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  initContainers:
  - name: init-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  containers:
  - name: container
    image: docker.io/library/debian:stable
    securityContext:
      seccompProfile:
        type: Localhost
        localhostProfile: my-profile.json

Pod у прикладі вище працює як Unconfined, тоді як ephemeral-container та init-container конкретно визначають RuntimeDefault. Якби ефемерний або init-контейнер не встановили явно поле securityContext.seccompProfile, тоді значення успадковується від Pod. Це ж стосується і контейнера, який використовує локальний профіль my-profile.json.

Загалом, поля контейнерів (включаючи ефемерні) мають вищий пріоритет, ніж значення на рівні Pod, а контейнери, які не задають поле seccomp, успадковують профіль від Pod.

Наступні значення можливі для поля seccompProfile.type:

Unconfined
Навантаження працює без будь-яких обмежень seccomp.
RuntimeDefault
Застосовується стандартний профіль seccomp, визначений середовищем виконання контейнерів. Стандартні профілі прагнуть забезпечити надійний набір параметрів безпеки, зберігаючи функціональність навантаження. Можливо, що стандартні профілі відрізняються між різними середовищами виконання контейнерів та їх версіями, наприклад, порівнюючи профілі CRI-O та containerd.
Localhost
Застосовується localhostProfile, який має бути доступний на диску вузла (у Linux це /var/lib/kubelet/seccomp). Доступність профілю seccomp перевіряється середовищем виконання контейнерів під час створення контейнера. Якщо профіль не існує, то створення контейнера завершиться з помилкою CreateContainerError.

Профілі Localhost

Профілі Seccomp — це JSON-файли, що відповідають схемі, визначеній специфікацією середовища виконання OCI. Профіль, як правило, визначає дії на основі відповідних системних викликів, але також дозволяє передавати конкретні значення як аргументи до системних викликів. Наприклад:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 38,
  "syscalls": [
    {
      "names": [
        "adjtimex",
        "alarm",
        "bind",
        "waitid",
        "waitpid",
        "write",
        "writev"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

defaultAction у профілі вище визначено як SCMP_ACT_ERRNO і буде повернуто як резервне для дій, визначених у syscalls. Помилка визначена як код 38 через поле 'defaultErrnoRet'.

Наступні дії зазвичай можливі:

SCMP_ACT_ERRNO
Повернення вказаного коду помилки.
SCMP_ACT_ALLOW
Дозвіл на виконання системного виклику.
SCMP_ACT_KILL_PROCESS
Завершення процесу.
SCMP_ACT_KILL_THREAD і SCMP_ACT_KILL
Завершення тільки потоку.
SCMP_ACT_TRAP
Генерація сигналу SIGSYS.
SCMP_ACT_NOTIFY і SECCOMP_RET_USER_NOTIF
Сповіщення простору користувача.
SCMP_ACT_TRACE
Сповіщення процесу трасування з вказаним значенням.
SCMP_ACT_LOG
Дозвіл на виконання системного виклику після того, як дія була зареєстрована в syslog або auditd.

Деякі дії, такі як SCMP_ACT_NOTIFY або SECCOMP_RET_USER_NOTIF, можуть бути не підтримувані залежно від середовища виконання контейнера, середовища виконання OCI або версії ядра Linux. Можуть бути також додаткові обмеження, наприклад, що SCMP_ACT_NOTIFY не може використовуватися як defaultAction або для певних системних викликів, таких як write. Усі ці обмеження визначаються або середовищем виконання OCI (runc, crun) або libseccomp.

Масив JSON syscalls містить список об’єктів, що посилаються на системні виклики за їхніми відповідними names. Наприклад, дія SCMP_ACT_ALLOW може бути використана для створення білого списку дозволених системних викликів, як показано у прикладі вище. Також можна визначити інший список, використовуючи дію SCMP_ACT_ERRNO, але з іншим значенням повернення (errnoRet).

Також можливо вказати аргументи (args), що передаються до певних системних викликів. Більше інформації про ці розширені випадки використання можна знайти в специфікації середовища виконання OCI та документації ядра Linux щодо Seccomp.

Додаткове читання

8.9 - Стан вузла

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

Поля стану вузла

Стан вузла містить наступну інформацію:

Ви можете використовувати команду kubectl для перегляду стану вузла та інших деталей:

kubectl describe node <insert-node-name-here>

Кожен розділ вихідних даних описано нижче.

Адреси

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

  • HostName: Імʼя хосту, яке повідомляється ядром вузла. Може бути перевизначене за допомогою параметра kubelet --hostname-override.
  • ExternalIP: Як правило, це IP-адреса вузла, яка доступна ззовні кластера.
  • InternalIP: Як правило, це IP-адреса вузла, яка доступна лише всередині кластера.

Стани

Поле conditions описує стан усіх Running вузлів. Прикладами умов є:

Стан вузлів та опис, коли кожен стан застосовується.
Умова вузлаОпис
ReadyTrue, якщо вузол справний та готовий приймати Podʼи, False, якщо вузол не справний і не приймає Podʼи, та Unknown, якщо контролер вузла не отримав інформацію від вузла протягом останнього node-monitor-grace-period (стандартно 40 секунд)
DiskPressureTrue, якщо є тиск на розмір диска, тобто якщо місткість диска низька; інакше False
MemoryPressureTrue, якщо є тиск на памʼять вузла, тобто якщо памʼять вузла низька; інакше False
PIDPressureTrue, якщо є тиск на процеси, тобто якщо на вузлі занадто багато процесів; інакше False
NetworkUnavailableTrue, якщо мережа для вузла неправильно налаштована, інакше False

В API Kubernetes стан вузла представлений як частина .status ресурсу Node. Наприклад, наступна структура JSON описує справний вузол:

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

Коли на вузлах виникають проблеми, панель управління Kubernetes автоматично створює taints, які відповідають станам, що впливають на вузол. Прикладом цього є ситуація, коли status стану Ready залишається Unknown або False довше, ніж налаштований інтервал NodeMonitorGracePeriod у kube-controller-manager, який стандартно становить 40 секунд. Це спричинить додавання на вузол taint node.kubernetes.io/unreachable для статусу Unknown або taint node.kubernetes.io/not-ready для статусу False.

Ці taints впливають на Podʼи, що перебувають в очікуванні, оскільки планувальник враховує taints вузла при призначенні Podʼів на вузол. Наявні Podʼи, заплановані на вузол, можуть бути виселені через застосування taints типу NoExecute. Podʼи також можуть мати tolerations, що дозволяє їм бути запланованими та продовжувати працювати на вузлі, навіть якщо на ньому є певний taint.

Дивіться Виселення на основі taint та Taint вузлів за станами для отримання додаткової інформації.

Місткість та Доступність

Описує ресурси, доступні на вузлі: процесор, памʼять та максимальну кількість Podʼів, які можуть бути заплановані на вузлі.

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

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

Інформація

Описує загальну інформацію про вузол, таку як версія ядра, версія Kubernetes (kubelet і kube-proxy), деталі контейнерного середовища та яка операційна система використовується на вузлі. Kubelet збирає цю інформацію з вузла та публікує її в API Kubernetes.

Пульс

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

Для вузлів існує дві форми пульсу:

  • оновлення .status вузла
  • обʼєкти Lease у просторі імен kube-node-lease. Кожен вузол має повʼязаний обʼєкт Lease.

Порівняно з оновленнями .status вузла, Lease є легким ресурсом. Використання Lease для пульсу знижує вплив цих оновлень на продуктивність для великих кластерів.

Kubelet відповідає за створення та оновлення .status вузлів, а також за оновлення їх повʼязаних Lease.

  • Kubelet оновлює .status вузла або коли стан змінюється, або якщо не було оновлень протягом налаштованого інтервалу. Стандартний інтервал для оновлень .status вузлів становить 5 хвилин, що значно довше, ніж типових 40 секунд для вузлів, що стали недоступними.
  • Kubelet створює та оновлює свій обʼєкт Lease кожні 10 секунд (стандартний інтервал оновлення). Оновлення Lease відбуваються незалежно від оновлень .status вузла. Якщо оновлення Lease не вдається, Kubelet повторює спробу, використовуючи експоненціальне збільшення інтервалу з початкового 200 мілісекунд до максимально 7 секунд.

9 - Довідник з мережі

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

9.1 - Протоколи Service

Якщо ви налаштовуєте Service, ви можете обрати будь-який мережевий протокол, що підтримується Kubernetes.

Kubernetes підтримує наступні протоколи для Service:

Коли ви визначаєте Service, ви також можете вказати протокол застосунку, який він використовує.

Цей документ описує деякі особливі випадки, всі з яких зазвичай використовують TCP як транспортний протокол:

Підтримувані протоколи

Існує 3 допустимі значення для protocol порту Service:

SCTP

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.20 [stable]

При використанні втулка мережі, що підтримує SCTP-трафік, ви можете використовувати SCTP для більшості Service. Для Service типу LoadBalancer підтримка SCTP залежить від можливості постачальника хмарних послуг надавати цю функцію. (Більшість не підтримують).

SCTP не підтримується на вузлах, що працюють під управлінням Windows.

Підтримка багатодомашніх SCTP-асоціацій

Підтримка багатодомашніх SCTP-асоціацій вимагає, щоб втулок CNI міг підтримувати призначення декількох інтерфейсів та IP-адрес для Podʼів.

NAT для багатодомашніх SCTP-асоціацій вимагає спеціальної логіки у відповідних модулях ядра.

TCP

Ви можете використовувати TCP для будь-якого виду Service, і це стандартний протокол.

UDP

Ви можете використовувати UDP для більшості Service. Для Service типу LoadBalancer підтримка UDP залежить від можливості постачальника хмарних послуг надавати цю функцію.

Особливі випадки

HTTP

Якщо ваш постачальник хмарних послуг підтримує це, ви можете використовувати Service у режимі LoadBalancer для налаштування балансувальника навантаження поза межами вашого кластера Kubernetes у спеціальному режимі, де балансувальник навантаження вашого постачальника хмарних послуг реалізує зворотнє проксіювання трафіку HTTP / HTTPS, з перенаправленням трафіку на бекенд-точки доступу для цього Service.

Зазвичай, ви встановлюєте протокол для Service як TCP і додаєте анотацію (зазвичай специфічну для вашого постачальника хмарних послуг), яка налаштовує балансувальник навантаження для обробки трафіку на рівні HTTP. Ця конфігурація може також включати обслуговування HTTPS (HTTP через TLS) та зворотнє проксіювання plain HTTP до вашого навантаження.

Ви можете додатково вказати, що протокол застосунку зʼєднання є http або https. Використовуйте http, якщо сесія від балансувальника навантаження до вашого навантаження є HTTP без TLS, та використовуйте https, якщо сесія від балансувальника навантаження до вашого навантаження використовує TLS-шифрування.

PROXY protocol

Якщо ваш постачальник хмарних послуг підтримує це, ви можете використовувати Service із типом LoadBalancer для налаштування балансувальника навантаження поза межами самого Kubernetes, який буде перенаправляти зʼєднання, обгорнуті у PROXY protocol.

Балансувальник навантаження тоді надсилає початкову серію октетів, що описують вхідне зʼєднання, схоже на цей приклад (PROXY protocol v1):

PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

Дані після проксі-протоколу є оригінальними даними від клієнта. Коли будь-яка сторона закриває зʼєднання, балансувальник навантаження також ініціює закриття зʼєднання та надсилає будь-які залишкові дані, якщо це можливо.

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

TLS

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

Зазвичай, ви встановлюєте протокол як TCP та встановлюєте анотацію (зазвичай специфічну для вашого постачальника хмарних послуг), яка налаштовує балансувальник навантаження виступати як TLS-сервер. Ви б налаштовували TLS-ідентифікацію (як сервер, та можливо також як клієнт, який підключається до вашого навантаження) за допомогою механізмів, специфічних для вашого постачальника хмарних послуг.

9.2 - Порти та Протоколи

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

Панель управління

ПротоколНапрямокДіапазон портівПризначенняВикористовується
TCPВхідний6443Kubernetes API серверУсі
TCPВхідний2379-2380etcd server client APIkube-apiserver, etcd
TCPВхідний10250Kubelet APIВласний, Панель управління
TCPВхідний10259kube-schedulerВласний
TCPВхідний10257kube-controller-managerВласний

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

Робочі вузли

ПротоколНапрямокДіапазон портівПризначенняВикористовується
TCPВхідний10250Kubelet APIВласний, Панель управління
TCPВхідний10256kube-proxyВласний, Балансувальники навантаження
TCPВхідний30000-32767NodePort Сервіси†Усі

† Типовий діапазон портів для NodePort Services.

Усі типові номери портів можуть бути змінені. Коли використовуються власні порти, ці порти повинні бути відкриті замість вказаних тут типових.

Одним із поширених прикладів є порт API сервера, який іноді змінюється на 443. Альтернативно, типовий порт залишається без змін, а API сервер розміщується за балансувальником навантаження, який слухає на 443 та направляє запити до API сервера на типовий порт.

9.3 - Віртуальні IP та Проксі для Service

Кожен вузол у кластері Kubernetes запускає компонент kube-proxy (якщо ви не розгорнули власний альтернативний компонент замість kube-proxy).

Компонент kube-proxy відповідає за реалізацію механізму віртуальних IP для Service типу відмінного від ExternalName. Кожен екземпляр kube-proxy відстежує додавання та видалення обʼєктів Service and EndpointSlice у панелі управління. Для кожного сервісу kube-proxy викликає відповідні API (залежно від режиму kube-proxy) для налаштування вузла для перехоплення трафіку на clusterIP та port сервісу, і перенаправляє цей трафік на одну з точок доступу Service (зазвичай це Pod, але можливо також будь-яка інша IP-адреса, надана користувачем). Цикл керування забезпечує, що правила на кожному вузлі надійно синхронізуються зі станом Service та EndpointSlice, вказаним API сервером.

Механізм віртуальних IP для Service, використовуючи режим iptables

Інколи виникає питання, чому Kubernetes покладається на проксіювання для пересилання вхідного трафіку до бекендів. Що щодо інших підходів? Наприклад, чи можливо налаштувати DNS-записи, які мають кілька A-значень (або AAAA для IPv6), і покладатися на розвʼязання імен по колу?

Є кілька причин для використання проксіювання для Service:

  • Існує довга історія реалізацій DNS, які не дотримуються TTL записів та кешують результати пошуку імен після закінчення терміну їх дії.
  • Деякі програми виконують пошук DNS лише один раз і кешують результати безстроково.
  • Навіть якщо програми та бібліотеки виконували правильне повторне розвʼязування, низькі або нульові TTL для DNS-записів можуть накладати високі навантаження на DNS, якими стає важко керувати.

Далі на цій сторінці ви можете прочитати про те, як працюють різні реалізації kube-proxy. В цілому, слід зазначити, що при запуску kube-proxy можуть бути змінені правила на рівні ядра (наприклад, можуть бути створені правила iptables), які не будуть очищені, в деяких випадках, до перезавантаження. Отже, запуск kube-proxy повинен здійснюватися тільки адміністратором, який розуміє наслідки наявності низькорівневого, привілейованого мережевого проксі-сервісу на компʼютері. Хоча виконуваний файл kube-proxy підтримує функцію cleanup, ця функція не є офіційною і тому доступна лише для використання "як є".

Деякі деталі у цьому довіднику стосуються прикладу: бекенд Pod для stateless навантаження з обробки образів, що працює з трьома репліками. Ці репліки замінні — фронтенди не турбує, який бекенд вони використовують. Хоча фактичні Podʼи, що складають бекенд-набір, можуть змінюватися, клієнти фронтенду не повинні бути обізнані про це і не повинні відстежувати набір бекендів самостійно.

Режими проксі

kube-proxy запускається в різних режимах, які визначаються його конфігурацією.

На Linux вузлах доступні режими для kube-proxy такі:

iptables
Режим, в якому kube-proxy налаштовує правила пересилання пакетів за допомогою iptables.
ipvs
Режим, в якому kube-proxy налаштовує правила пересилання пакетів за допомогою ipvs.
nftables
Режим, в якому kube-proxy налаштовує правила пересилання пакетів за допомогою nftables.

У Windows доступний лише один режим для kube-proxy:

kernelspace
Режим, в якому kube-proxy налаштовує правила пересилання пакетів у ядрі Windows.

Режим проксі iptables

Цей режим проксі доступний лише на вузлах Linux.

У цьому режимі kube-proxy налаштовує правила пересилання пакетів за допомогою API iptables підсистеми netfilter ядра. Для кожної точки доступу він встановлює правила iptables, які типово випадково вибирають бекенд Pod.

Приклад

Як приклад, розглянемо програму обробки образів, описану раніше на сторінці. Коли створюється бекенд Service, панель управління Kubernetes призначає віртуальну IP-адресу, наприклад, 10.0.0.1. Для цього прикладу припустимо, що порт Service — 1234. Усі екземпляри kube-proxy у кластері спостерігають за створенням нового Service.

Коли kube-proxy на вузлі бачить новий Service, він встановлює серію правил iptables, які перенаправляють з віртуальної IP-адреси на додаткові правила iptables, визначені для кожного Service. Правила для кожного Service посилаються на інші правила для кожної точки доступу бекенду, а правила для кожної точки доступу перенаправляють трафік (використовуючи NAT призначення) до бекендів.

Коли клієнт підключається до віртуальної IP-адреси Service, вступає в дію правило iptables. Вибирається бекенд (або на основі спорідненості сесії, або випадково), і пакети перенаправляються до бекенду без переписування IP-адреси клієнта.

Цей самий основний потік виконується, коли трафік надходить через node-port або через балансувальник навантаження, хоча в цих випадках IP-адреса клієнта змінюється.

Оптимізація продуктивності режиму iptables

У режимі iptables, kube-proxy створює кілька правил iptables для кожного Service та кілька правил iptables для кожної IP-адреси точки доступу. У кластерах з десятками тисяч Podʼів та Service це означає десятки тисяч правил iptables, і kube-proxy може потребувати багато часу на оновлення правил у ядрі, коли Service (або їх EndpointSlices) змінюються. Ви можете налаштувати поведінку синхронізації kube-proxy за допомогою параметрів у розділі iptables файлу конфігурації kube-proxy (який ви вказуєте через kube-proxy --config <path>):

...
iptables:
  minSyncPeriod: 1s
  syncPeriod: 30s
minSyncPeriod

Параметр minSyncPeriod встановлює мінімальний інтервал між спробами ресинхронізації правил iptables з ядром. Якщо він дорівнює 0s, то kube-proxy завжди негайно синхронізує правила при зміні будь-якого Service чи Endpoint. Це працює добре в дуже малих кластерах, але призводить до зайвої роботи, коли велика кількість змін відбувається за короткий період часу. Наприклад, якщо у вас є Service, який підтримується Deployment зі 100 Podʼів, і ви видаляєте Deployment, то з minSyncPeriod: 0s, kube-proxy буде по одному видаляти точки доступу Service з правил iptables, загалом 100 оновлень. З більшим значенням minSyncPeriod, події видалення багатьох Podʼів можуть агрегуватися разом, наприклад, kube-proxy може зробити 5 оновлень, кожне з яких видаляє по 20 точок доступу, що значно економить процесорний час і прискорює синхронізацію всіх змін.

Чим більше значення minSyncPeriod, тим більше роботи можна агрегувати, але недолік полягає в тому, що кожна окрема зміна може очікувати до повного minSyncPeriod, перш ніж буде оброблена, що означає, що правила iptables витрачають більше часу несинхронізованими з поточним станом API-сервера.

Стандартне значення 1s працює добре в більшості кластерів, але в дуже великих кластерах може бути необхідно встановити більше значення. Особливо, якщо метрика sync_proxy_rules_duration_seconds kube-proxy показує середній час значно більше 1 секунди, збільшення minSyncPeriod може зробити оновлення ефективнішими.

Оновлення конфігурації старого параметра minSyncPeriod

У попередніх версіях kube-proxy всі правила для всіх Service оновлювалися кожною синхронізацією, що призводило до проблем продуктивності (затримок оновлення) у великих кластерах, і рекомендоване рішення полягало в налаштуванні більшого значення minSyncPeriod. Починаючи з Kubernetes v1.28, режим iptables kube-proxy використовує більш мінімалістичний підхід, здійснюючи оновлення тільки там, де фактично змінилися Service або EndpointSlices.

Якщо ви раніше перевизначали параметр minSyncPeriod, вам слід спробувати видалити це перевизначення і дозволити kube-proxy використовувати стандартні значення (1s) або принаймні менше значення, ніж ви використовували до оновлення.

Якщо ви не запускаєте kube-proxy з Kubernetes 1.31, перевірте поведінку і повʼязані поради для версії, яку ви фактично використовуєте.

syncPeriod

Параметр syncPeriod контролює кілька операцій синхронізації, які не повʼязані безпосередньо зі змінами в окремих Service та EndpointSlices. Зокрема, він визначає, як швидко kube-proxy помічає, якщо зовнішній компонент втрутився в правила iptables kube-proxy. У великих кластерах kube-proxy також виконує певні операції очищення лише один раз протягом syncPeriod, щоб уникнути непотрібної роботи.

Зазвичай збільшення syncPeriod не має значного впливу на продуктивність, але раніше іноді було корисно встановлювати його дуже великим значенням (наприклад, 1h). Проте це більше не рекомендується і, ймовірно, таке налаштування спричинить більше проблем з функціональністю, ніж покращить продуктивність.

Режим проксі IPVS

Цей режим проксі доступний лише на вузлах Linux.

У режимі ipvs kube-proxy використовує ядро IPVS та API iptables для створення правил для перенаправлення трафіку з IP-адрес Service на IP-адреси точок доступу.

Режим проксі IPVS базується на функції перехоплення netfilter, аналогічній режиму iptables, але використовує хеш-таблицю як основну структуру даних та працює в просторі ядра. Це означає, що kube-proxy в режимі IPVS перенаправляє трафік з меншою затримкою порівняно з режимом iptables, зі значно кращою продуктивністю при синхронізації правил проксі. У порівнянні з режимом проксі iptables, режим IPVS також підтримує вищу пропускну здатність мережевого трафіку.

IPVS надає більше опцій для балансування трафіку до бекендів Pods:

  • rr (Round Robin): Трафік рівномірно розподіляється між серверами.

  • wrr (Weighted Round Robin): Трафік маршрутизується до серверів на основі їх ваг. Сервери з вищими вагами отримують нові зʼєднання і більше запитів, ніж сервери з меншими вагами.

  • lc (Least Connection): Більше трафіку призначається серверам з меншою кількістю активних зʼєднань.

  • wlc (Weighted Least Connection): Більше трафіку маршрутизується до серверів з меншою кількістю зʼєднань відносно їх ваг, тобто кількість зʼєднань, поділена на вагу.

  • lblc (Locality based Least Connection): Трафік для тієї ж самої IP-адреси надсилається на той же сервер, якщо він не перевантажений і доступний; в іншому випадку трафік надсилається на сервери з меншою кількістю зʼєднань з можливістю збереження для майбутнього призначення.

  • lblcr (Locality Based Least Connection with Replication): Трафік для тієї ж самої IP-адреси надсилається на сервер з найменшою кількістю зʼєднань. Якщо всі сервери перевантажені, вибирається один із меншою кількістю зʼєднань і додається до множини цільових серверів. Якщо множина цільових серверів не змінюється протягом визначеного часу, то найбільш навантажений сервер вилучається з множини, щоб уникнути високого рівня реплікації.

  • sh (Source Hashing): Трафік відправляється на сервер за допомогою статично призначеної хеш-таблиці на основі джерела IP-адрес.

  • dh (Destination Hashing): Трафік відправляється на сервер за допомогою статично призначеної хеш-таблиці на основі цільових адрес.

  • sed (Shortest Expected Delay): Трафік пересилається на сервер з найменшим очікуваним затримкою. Очікувана затримка обчислюється як (C + 1) / U, де C — кількість зʼєднань на сервері, а U — фіксована сервісна швидкість (вага) сервера.

  • nq (Never Queue): Трафік відправляється на сервер, що простоює, якщо є такий, замість очікування швидкішого; якщо всі сервери зайняті, алгоритм переходить до поведінки sed.

  • mh (Maglev Hashing): Призначає вхідні завдання на основі алгоритму хешування Maglev від Google. Цей планувальник має два прапорці: mh-fallback, який дозволяє перейти на інший сервер, якщо вибраний сервер недоступний, і mh-port, який додає номер порту джерела до обчислення хешу. Використовуючи mh, kube-proxy завжди встановлює прапорець mh-port і не вмикає прапорець mh-fallback. У режимі proxy-mode=ipvs mh працюватиме як source-hashing (sh), але з портами.

Ці алгоритми планування налаштовуються в полі ipvs.scheduler у конфігурації kube-proxy.

Механізм віртуальної IP-адреси для Services, використовуючи режим IPVS

Режим проксі nftables

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta] (стандартно увімкнено: true)

Цей режим проксі доступний лише на вузлах Linux, він потребує ядра версії 5.13 чи новіщої.

У цьому режимі kube-proxy налаштовує правила пересилання пакетів за допомогою API nftables ядра підсистеми netfilter. Для кожної точки доступу встановлюються правила nftables, які стандартно вибирають бекенд Pod випадковим чином.

API nftables є наступником API iptables і призначений для забезпечення кращої продуктивності та масштабованості порівняно з iptables. Режим проксі nftables може обробляти зміни в точках доступу сервісу швидше та ефективніше, ніж режим iptables, і також може ефективніше обробляти пакети в ядрі (хоча це стає помітним лише в кластерах з десятками тисяч сервісів).

В Kubernetes 1.31, режим nftables все ще відносно новий і може бути несумісний з усіма мережевими втулками; ознайомтесь з документацією до вашого мережевого втулка.

Міграція з iptables на nftables

Користувачі, які хочуть перейти зі стандартного режиму iptables на режим nftables, повинні знати, що деякі функції в режимі nftables працюють трохи інакше:

  • Інтерфейси NodePort: У режимі iptables, стандартно, сервіси NodePort доступні на всіх локальних IP-адресах. Це зазвичай не те, чого хочуть користувачі, тому режим nftables стандартно використовує параметр --nodeport-addresses primary, що означає, що сервіси NodePort доступні лише на основних IPv4 та/або IPv6 адресах вузла. Ви можете змінити це, вказавши явне значення для цієї опції: наприклад, --nodeport-addresses 0.0.0.0/0, щоб слухати на всіх (локальних) IP-адресах IPv4.

  • Сервіси NodePort на 127.0.0.1: У режимі iptables, якщо діапазон --nodeport-addresses включає 127.0.0.1 (і не передано опцію --iptables-localhost-nodeports false), тоді сервіси NodePort будуть доступні навіть на "localhost" (127.0.0.1). У режимі nftables (та режимі ipvs) це не працюватиме. Якщо ви не впевнені, чи залежите від цієї функціональності, ви можете перевірити метрику kube-proxy iptables_localhost_nodeports_accepted_packets_total; якщо вона не дорівнює 0, це означає, що якийсь клієнт підключився до сервісу NodePort через 127.0.0.1.

  • Взаємодія NodePort з брандмауерами: Режим iptables kube-proxy намагається бути сумісним із занадто агресивними брандмауерами; для кожного сервісу NodePort він додаватиме правила для прийому вхідного трафіку на цьому порту, на випадок, якщо цей трафік буде заблокований брандмауером. Цей підхід не працює з брандмауерами на основі nftables, тому режим nftables kube-proxy не робить нічого в цьому напрямку; якщо у вас є локальний брандмауер, ви повинні переконатися, що він належним чином налаштований для пропуску трафіку Kubernetes (наприклад, дозволивши вхідний трафік на весь діапазон NodePort).

  • Обхід помилок Conntrack: Ядра Linux версій до 6.1 мають помилку, яка може призвести до закриття довготривалих TCP-зʼєднань до IP-адрес сервісів з помилкою "Connection reset by peer". Режим iptables kube-proxy встановлює обхід для цієї помилки, але пізніше було виявлено, що цей обхід викликає інші проблеми в деяких кластерах. Режим nftables стандартно не встановлює жодного обходу, але ви можете перевірити метрику kube-proxy iptables_ct_state_invalid_dropped_packets_total, щоб зʼясувати, чи залежить ваш кластер від цього обходу, і якщо це так, ви можете запустити kube-proxy з опцією --conntrack-tcp-be-liberal, щоб оминути цю проблему в режимі nftables.

Режим проксі kernelspace

Цей режим проксі доступний лише на вузлах Windows.

kube-proxy налаштовує правила фільтрації пакетів у Windows у віртуальній платформі фільтрації (Virtual Filtering Platform, VFP), яка є розширенням віртуального комутатора Windows (vSwitch). Ці правила обробляють інкапсульовані пакети в межах віртуальних мереж на рівні вузлів і переписують пакети таким чином, щоб IP-адреса призначення (і інформація на рівні 2) була правильною для маршрутизації пакета до вірного призначення. Windows VFP аналогічний інструментам, таким як Linux nftables або iptables. Він розширює Hyper-V Switch, який спочатку був реалізований для підтримки мережевого звʼязку віртуальних машин.

Коли Pod на вузлі надсилає трафік на віртуальну IP-адресу, а kube-proxy вибирає Pod на іншому вузлі як ціль для балансування навантаження, режим проксі kernelspace переписує цей пакет так, щоб він був призначений для цільового бекенд Pod. Служба мережевого хоста Windows (HNS) забезпечує конфігурацію правил переписування пакетів таким чином, щоб зворотній трафік виглядав так, ніби він прийшов від віртуальної IP-адреси, а не конкретного бекенду Pod.

Прямий вивід сервера для режиму kernelspace

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.14 [alpha]

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

Для використання цієї можливості вам необхідно запускати kube-proxy з аргументом командного рядка --enable-dsr і включити функціональних можливостейWinDSR.

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

Сесійна спорідненість

У цих моделях проксі, трафік, що направляється на IP:Port Service, передається до відповідного бекенду без того, щоб клієнти щось знали про Kubernetes, Service або Podʼи.

Якщо ви хочете забезпечити, щоб зʼєднання від певного клієнта завжди передавалися до одного й того ж Podʼа, ви можете вибрати сесійну спорідненість на основі IP-адрес клієнта, встановивши .spec.sessionAffinity в ClientIP для Service (типово None).

Тайм-аут збереження сесії

Ви також можете встановити максимальний час збереження сесії, встановивши .spec.sessionAffinityConfig.clientIP.timeoutSeconds відповідно для Service. (стандартне значення 10800, що відповідає 3 годинам).

Призначення IP-адрес Service

На відміну від IP-адрес Podʼів, які фактично маршрутизуються до фіксованого призначення, IP-адреси Service насправді не відповідають одному окремому хосту. Замість цього, kube-proxy використовує логіку обробки пакетів (наприклад, Linux iptables), щоб визначити віртуальні IP-адреси, які потрібно перенаправляти за потреби.

Коли клієнти підключаються до VIP, їхній трафік автоматично транспортується до відповідної точки доступу. Змінні середовища та DNS для Service насправді заповнюються відносно віртуальної IP-адреси Service (і порту).

Уникнення конфліктів

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

Щоб дозволити вам вибирати IP-адреси для ваших Service, ми повинні забезпечити, що жодні два Service не зможуть конфліктувати. Kubernetes досягає цього, призначаючи кожному Service його власну IP-адресу з діапазону service-cluster-ip-range, який налаштований для API Server.

Відстеження призначення IP-адрес

Для того щоб гарантувати, що кожен Service отримує унікальну IP-адресу, внутрішній розподілювач атомарно оновлює глобальний map призначення в etcd перед створенням кожного Service. Обʼєкт map повинен існувати в реєстрі для того, щоб Service отримували призначення IP-адрес, інакше створення завершиться невдачею з повідомленням про неможливість призначити IP-адресу.

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

Відстеження призначення IP-адрес за допомогою Kubernetes API

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta] (стандартно увімкнено: false)

Якщо ви включите функціональні можливості MultiCIDRServiceAllocator та API-групу networking.k8s.io/v1alpha1, панель управління замінить наявний розподілювач etcd переглянутою реалізацією, яка використовує обʼєкти IPAddress та ServiceCIDR замість внутрішнього глобального map призначення. Кожен IP-адрес кластера, повʼязаний з Service, посилається на обʼєкт IPAddress.

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

Однією з основних переваг переглянутого розподілювача є видалення обмежень розміру для діапазону IP-адрес, який може бути використаний для IP-адрес кластера Service. З увімкненою MultiCIDRServiceAllocator, для IPv4 відсутні обмеження, а для IPv6 ви можете використовувати маски підмереж, що є /64 або менше (на відміну від /108 зі старої реалізації).

Доступ до призначень IP-адрес через API означає, що ви, як адміністратор кластера, можете дозволяти користувачам переглядати призначені їх Service IP-адреси. Розширення Kubernetes, такі як Gateway API, можуть використовувати IPAddress API для розширення вбудованих мережевих можливостей Kubernetes.

Нижче наведений короткий приклад того, як користувач може запитувати IP-адреси:

kubectl get services

NAME         TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   2001:db8:1:2::1   <none>        443/TCP   3d1h

kubectl get ipaddresses

NAME              PARENTREF
2001:db8:1:2::1   services/default/kubernetes
2001:db8:1:2::a   services/kube-system/kube-dns

Kubernetes також дозволяє користувачам динамічно визначати доступні діапазони IP для Service за допомогою обʼєктів ServiceCIDR. Під час початкового налаштування, обʼєкт ServiceCIDR зі стандартним іменем kubernetes створюється зі значенням аргументу командного рядка --service-cluster-ip-range для kube-apiserver:

kubectl get servicecidrs

NAME         CIDRS         AGE
kubernetes   10.96.0.0/28  17m

Користувачі можуть створювати або видаляти нові обʼєкти ServiceCIDR для управління доступними діапазонами IP для Service:

cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: ServiceCIDR
metadata:
  name: newservicecidr
spec:
  cidrs:
  - 10.96.0.0/24
EOF

servicecidr.networking.k8s.io/newcidr1 created

kubectl get servicecidrs

NAME             CIDRS         AGE
kubernetes       10.96.0.0/28  17m
newservicecidr   10.96.0.0/24  7m

Діапазони IP-адрес для віртуальних IP-адрес Service

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Kubernetes розділяє діапазон ClusterIP на дві групи, в залежності від розміру налаштованого service-cluster-ip-range, використовуючи таку формулу: min(max(16, cidrSize / 16), 256). Ця формула означає ніколи менше 16 або більше 256, з поступовим збільшенням між ними.

Kubernetes віддає перевагу виділенню динамічних IP-адрес для Service, вибираючи з верхньої групи. Це означає, що якщо ви хочете призначити конкретну IP-адресу для Service з типом ClusterIP, ви повинні вручну призначити IP-адресу з нижньої групи. Цей підхід зменшує ризик конфлікту при виділенні IP-адрес.

Політики трафіку

Ви можете встановити поля .spec.internalTrafficPolicy і .spec.externalTrafficPolicy, щоб контролювати, як Kubernetes маршрутизує трафік до справних ("готових") бекендів.

Політика втурішнього трафіку

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Ви можете встановити поле .spec.internalTrafficPolicy, щоб контролювати маршрутизацію трафіку від внутрішніх джерел. Допустимі значення: Cluster і Local. Встановіть поле в Cluster, щоб маршрутизувати внутрішній трафік до всіх готових точок доступу і в Local, щоб маршрутизувати тільки до готових точок доступу, що знаходяться на вузлі. Якщо політика трафіку встановлена в Local, а на вузлі відсутні локальні точки доступу, kube-proxy відкидає трафік.

Політика зовнішнього трафіку

Ви можете налаштувати поле .spec.externalTrafficPolicy для контролю напрямку трафіку зовнішніх джерел. Допустимі значення: Cluster і Local. Встановіть поле на значення Cluster, щоб направляти зовнішній трафік до всіх готових точок доступу, і Local, щоб направляти тільки до готових локальних точок доступу на вузлі. Якщо політика трафіку встановлена на Local і відсутні локальні точки доступу, kube-proxy не передає жодного трафіку для відповідного Service.

Якщо вибрано Cluster, всі вузли є потенційними цілями балансування навантаження, поки вузол не видаляється і kube-proxy працює коректно. У цьому режимі: перевірки стану балансувальника навантаження налаштовані на доступність порту та шляху готовності проксі сервісу. Для kube-proxy це оцінюється як: ${NODE_IP}:10256/healthz. kube-proxy повертає HTTP-код 200 або 503. Точка доступу перевірки стану балансувальника навантаження kube-proxy повертає 200 у випадку:

  1. kube-proxy працює коректно, що означає:
    • він може успішно просувати програмування мережі і не має проблем з таймаутом (таймаут визначається як: 2 × iptables.syncPeriod); і
  2. вузол не видаляється (не встановлено мітки видалення для вузла).

Причина того, що kube-proxy повертає 503 і позначає вузол як непридатний, коли він видаляється, полягає в тому, що kube-proxy підтримує очищення зʼєднання для вузлів, що припиняють роботу. З точки зору управління Kubernetes керування навантаженням при видаленні вузла відбувається декілька важливих аспектів.

Під час видалення:

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

Після видалення:

  • Контролер сервісу в менеджері хмарних контролерів Kubernetes видаляє вузол зі згаданого набору потенційних цілей. Видалення будь-якого екземпляра зі списку бекендів балансувальника навантаження миттєво припиняє всі зʼєднання. Це також причина того, що kube-proxy спочатку не проходить перевірку стану, коли вузол видаляється.

Для вендорів Kubernetes важливо враховувати, що якщо будь-який вендор налаштовує перевірку готовності kube-proxy як перевірку життєздатності, kube-proxy почне постійно перезапускатися при видаленні вузла до його повного видалення. kube-proxy використовує шлях /livez, який, на відміну від /healthz, не враховує стан видалення вузла, але лише прогрес програмування мережі. /livez є рекомендованим шляхом для визначення перевірки життєздатності kube-proxy.

Користувачі, які використовують kube-proxy, можуть перевірити стан готовності/життєздатності, оцінюючи метрики: proxy_livez_total/proxy_healthz_total. Обидві метрики публікують дві серії: одна з міткою 200 і одна з міткою 503.

Для Local Services: kube-proxy повертає 200, якщо

  1. kube-proxy працює коректно/готовий, і
  2. є локальна точка доступу на вузлі, який розглядається.

Видалення вузла не впливає на код відповіді kube-proxy щодо перевірки стану балансувальника навантаження. Причина полягає в тому, що видалення вузлів може призвести до відключення входу в мережу, якщо всі точки доступу одночасно працюють на таких вузлах.

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

Трафік до термінальних точок доступу доступу

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Якщо в kube-proxy включений функціоналу ProxyTerminatingEndpoints і політика трафіку встановлена на Local, kube-proxy на даному вузлі використовує більш складний алгоритм для вибору точок доступу доступу Service. З цим включеним функціоналом, kube-proxy перевіряє наявність локальних точок доступу доступу і те, чи всі локальні кінцеві точки позначені як термінальні. Якщо всі локальні кінцеві точки позначені як термінальні, тоді kube-proxy направлятиме трафік на ці термінальні кінцеві точки. В іншому випадку kube-proxy завжди віддає перевагу направленню трафіку на кінцеві точки, які не є термінальними.

Це поведінка направлення для терміналних точок доступу доступу існує для того, щоб NodePort і LoadBalancer сервіси могли відповідно завершувати зʼєднання при використанні externalTrafficPolicy: Local.

Під час виконання постійного (rolling) оновлення, вузли, які підтримують балансувальник навантаження, можуть переходити від N до 0 реплік цього розгортання. У деяких випадках зовнішні балансувальники навантаження можуть надсилати трафік на вузол з 0 репліками між перевірками готовності. Направлення трафіку на термінальні точки доступу забезпечує, що вузли, які зменшують кількість точок доступу, можуть відповідним чином приймати та відводити трафік на ці термінальні точки доступу. До моменту завершення видалення точки доступу, зовнішній балансувальник навантаження має побачити, що перевірка готовності вузла не вдалася і повністю видалить вузол зі списку бекендів.

Розподіл трафіку

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta] (стандартно увімкнено: true)

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

PreferClose з kube-proxy
Для kube-proxy це означає, що пріоритет в надсиланні трафіку надається точкам доступу в тій самій зоні, що й клієнт. Контролер EndpointSlice оновлює EndpointSlice з підказками для комунікації цього уподобання, яке kube-proxy використовує для прийняття рішень щодо маршрутизації. Якщо в зоні клієнта відсутні будь-які доступні точки доступу, трафік буде маршрутизовано на рівні всього кластера для цього клієнта.

У відсутність будь-якого значення для trafficDistribution, стандартна стратегія для kube-proxy полягає в розподілі трафіку до будь-якої точки доступу в кластері.

Порівняння з service.kubernetes.io/topology-mode: Auto

Поле trafficDistribution зі значенням PreferClose і анотація service.kubernetes.io/topology-mode: Auto спрямовані на пріоритет маршрутизації трафіку в межах однієї зони. Однак, є ключові відмінності у їхніх підходах:

  • service.kubernetes.io/topology-mode: Auto: Спробує розподілити трафік пропорціонально між зонами на основі ресурсів CPU, які можна виділити. Цей евристичний метод включає захисні заходи (такі як поведінка відкату для малих кількостей точок доступу) і може призвести до вимкнення функціоналу в певних сценаріях з причин навантаження балансування. Цей підхід жертвує деякою передбачуваністю на користь можливості балансування навантаження.

  • trafficDistribution: PreferClose: Цей підхід спрямований на більш простоту і передбачуваність: "Якщо є точки доступу в зоні, вони отримають весь трафік для цієї зони; якщо точок доступу у зоні немає, трафік буде розподілено на інші зони". Хоча цей підхід може пропонувати більшу передбачуваність, він означає, що вам потрібно керувати можливим перевантаженням.

Якщо встановлено анотацію service.kubernetes.io/topology-mode зі значенням Auto, вона матиме пріоритет перед полем trafficDistribution. (У майбутньому анотація може бути застарілою на користь поля trafficDistribution).

Взаємодія з політиками трафіку

Порівняно з полем trafficDistribution, поля політики трафіку (externalTrafficPolicy і internalTrafficPolicy) призначені для обовʼязкового дотримання локальних вимог до трафіку. Ось як поле trafficDistribution взаємодіє з ними:

  • Пріоритет політик трафіку: Для заданого Service, якщо політика трафіку (externalTrafficPolicy або internalTrafficPolicy) встановлена на Local, вона має пріоритет перед trafficDistribution: PreferClose для відповідного типу трафіку (зовнішнього або внутрішнього відповідно).

  • Вплив trafficDistribution: Для заданого Service, якщо політика трафіку (externalTrafficPolicy або internalTrafficPolicy) встановлена на Cluster (стандартне значення), або якщо поля не встановлені, тоді trafficDistribution: PreferClose керує поведінкою маршрутизації для відповідного типу трафіку (зовнішнього або внутрішнього відповідно). Це означає, що буде здійснена спроба направити трафік на точку доступу, яка знаходиться в тій же зоні, що й клієнт.

Міркування щодо використання управління розподілом трафіку

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

    • Обмеження розподілу топології Pod: Використовуйте обмеження розподілу топології Pod для рівномірнішого розподілу ваших Podʼів по зонам.

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

  • Реалізація залежно від імплементації: Кожна реалізація панелі даних може трохи по-різному обробляти це поле. Якщо ви використовуєте імплементацію, відмінну від kube-proxy, зверніться до документації саме цієї імплементації, щоб зрозуміти, як це поле обробляється.

Що далі

Щоб дізнатися більше про Service, читайте Підключення застосунків до Service.

Також ви можете:

10 - Інструменти встановлення

10.1 - Kubeadm

Kubeadm — це інструмент, створений для надання команд kubeadm init та kubeadm join як "швидкі" практичні шляхи для створення кластерів Kubernetes.

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

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

Як встановити

Для встановлення kubeadm, див. посібник з встановлення.

Що далі

  • kubeadm init — для створення вузла панелі управління Kubernetes
  • kubeadm join — для додавання робочого вузла Kubernetes до кластера
  • kubeadm upgrade — для оновлення кластера Kubernetes до нової версії
  • kubeadm config — якщо ви ініціалізували свій кластер за допомогою kubeadm версії 1.7.x або нижче, для налаштування кластера для kubeadm upgrade
  • kubeadm token — для управління токенами для kubeadm join
  • kubeadm reset — для скасування будь-яких змін, внесених цим хостом за допомогою kubeadm init або kubeadm join
  • kubeadm certs — для управління сертифікатами Kubernetes
  • kubeadm kubeconfig — для управління файлами kubeconfig
  • kubeadm version — для виводу версії kubeadm
  • kubeadm alpha — для попереднього перегляду набору функцій, що стануть доступними для збору відгуків від спільноти

10.1.1 - Kubeadm Generated

10.1.1.1 -

kubeadm: легке розгортання захищеного кластера Kubernetes

Опис

┌──────────────────────────────────────────────────────────┐
│ KUBEADM                                                  │
│ Easily bootstrap a secure Kubernetes cluster             │
│                                                          │
│ Please give us feedback at:                              │
│ https://github.com/kubernetes/kubeadm/issues             │
└──────────────────────────────────────────────────────────┘

Приклад використання:

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

┌──────────────────────────────────────────────────────────┐
│ На першій машині:                                        │
├──────────────────────────────────────────────────────────┤
│ control-plane# kubeadm init                              │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│ На другій машині:                                        │
├──────────────────────────────────────────────────────────┤
│ worker# kubeadm join &lt;arguments-returned-from-init&gt;      │
└──────────────────────────────────────────────────────────┘

Повторіть другий крок на стількох інших машинах, скільки потрібно.
-h, --help

Довідка kubeadm

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.2 -

Команди, повʼязані з обробкою сертифікатів kubernetes

Опис

Команди, повʼязані з обробкою сертифікатів kubernetes

kubeadm certs [command]

Параметри

-h, --help

довідка certs

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.3 -

Генерує ключів сертифікатів

Опис

Ця команда виведе захищений випадково згенерований ключ сертифіката, який можна використовувати з командою "init".

Ви також можете скористатися командою "kubeadm init --upload-certs" без зазначення ключа сертифіката, і вона згенерує і виведе його для вас.

kubeadm certs certificate-key [flags]

Параметри

-h, --help

Довідка certificate-key

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.4 -

Перевіряє термін дії сертифікатів для кластера Kubernetes

Опис

Перевіряє термін дії сертифікатів у локальному PKI, яким керує kubeadm.

kubeadm certs check-expiration [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується тільки до форматів виведення golang і jsonpath.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка check-expiration

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залишати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.5 -

Генерує ключі та запити на підписання сертифікатів

Опис

Генерує ключі та запити на підписування сертифікатів (CSRs) для всіх сертифікатів, необхідних для роботи панелі управління. Ця команда також генерує часткові файли kubeconfig з даними приватного ключа в полі "users > user > client-key-data", і для кожного файлу kubeconfig створюється супутній файл ".csr".

Ця команда призначена для використання в Режимі Kubeadm з зовнішнім CA Kubeadm. Вона генерує CSRs, які ви можете подати на підписання до вашого зовнішнього центру сертифікації.

Закодовані в PEM підписані сертифікати повинні бути збережені поруч з файлами ключів, використовуючи ".crt" як розширення файлу, або, у випадку з файлами kubeconfig, закодований в PEM підписаний сертифікат повинен бути закодований у base64 і доданий до файлу kubeconfig в полі "users > user > client-certificate-data".

kubeadm certs generate-csr [flags]

Приклади

# Наступна команда згенерує ключі та CSRs для всіх сертифікатів панелі управління та файлів kubeconfig:
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Параметри

--cert-dir string

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка generate-csr

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.6 -

Поновлення сертифікатів для кластера Kubernetes

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm certs renew [flags]

Параметри

-h, --help

довідка renew

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.7 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на поточних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.8 -

Поновлення всіх доступних сертифікатів

Опис

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

kubeadm certs renew all [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.9 -

Поновлює сертифікат, який apiserver використовує для доступу до etcd

Опис

Поновлює сертифікат, який apiserver використовує для доступу до etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR запит.

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

kubeadm certs renew apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-etcd-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.10 -

Поновлює сертифікат для сервера API для підключення до kubelet

Опис

Поновлює сертифікат для сервера API для підключення до kubelet.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-kubelet-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.11 -

Поновлює сертифікат для обслуговування API Kubernetes

Синопсис

Поновлює сертифікат для обслуговування API Kubernetes.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew apiserver [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.12 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew controller-manager.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка controller-manager.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.13 -

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd

Опис

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-healthcheck-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.14 -

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним

Опис

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-peer

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.15 -

Поновлює сертифікат для обслуговування etcd

Опис

Поновлює сертифікат для обслуговування etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-server

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.16 -

Поновлення сертифіката клієнта front proxy

Опис

Поновлення сертифіката клієнта front proxy.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка front-proxy-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.17 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew scheduler.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка scheduler.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.18 -

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew super-admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка super-admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.19 -

Генерує ключів сертифікатів

Опис

Ця команда виведе захищений випадково згенерований ключ сертифіката, який можна використовувати з командою "init".

Ви також можете скористатися командою "kubeadm init --upload-certs" без зазначення ключа сертифіката, і вона згенерує і виведе його для вас.

kubeadm certs certificate-key [flags]

Параметри

-h, --help

Довідка certificate-key

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.20 -

Перевіряє термін дії сертифікатів для кластера Kubernetes

Опис

Перевіряє термін дії сертифікатів у локальному PKI, яким керує kubeadm.

kubeadm certs check-expiration [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується тільки до форматів виведення golang і jsonpath.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

-h, --help

Довідка check-expiration

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--show-managed-fields

Якщо true, залишати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.21 -

Генерує ключі та запити на підписання сертифікатів

Опис

Генерує ключі та запити на підписування сертифікатів (CSRs) для всіх сертифікатів, необхідних для роботи панелі управління. Ця команда також генерує часткові файли kubeconfig з даними приватного ключа в полі "users > user > client-key-data", і для кожного файлу kubeconfig створюється супутній файл ".csr".

Ця команда призначена для використання в Режимі Kubeadm з зовнішнім CA Kubeadm. Вона генерує CSRs, які ви можете подати на підписання до вашого зовнішнього центру сертифікації.

Закодовані в PEM підписані сертифікати повинні бути збережені поруч з файлами ключів, використовуючи ".crt" як розширення файлу, або, у випадку з файлами kubeconfig, закодований в PEM підписаний сертифікат повинен бути закодований у base64 і доданий до файлу kubeconfig в полі "users > user > client-certificate-data".

kubeadm certs generate-csr [flags]

Приклади

# Наступна команда згенерує ключі та CSRs для всіх сертифікатів панелі управління та файлів kubeconfig:
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Параметри

--cert-dir string

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка generate-csr

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.22 -

Поновлення сертифікатів для кластера Kubernetes

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm certs renew [flags]

Параметри

-h, --help

довідка renew

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.23 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на поточних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.24 -

Поновлення всіх доступних сертифікатів

Опис

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

kubeadm certs renew all [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.25 -

Поновлює сертифікат, який apiserver використовує для доступу до etcd

Опис

Поновлює сертифікат, який apiserver використовує для доступу до etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR запит.

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

kubeadm certs renew apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-etcd-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.26 -

Поновлює сертифікат для сервера API для підключення до kubelet

Опис

Поновлює сертифікат для сервера API для підключення до kubelet.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-kubelet-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.27 -

Поновлює сертифікат для обслуговування API Kubernetes

Синопсис

Поновлює сертифікат для обслуговування API Kubernetes.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew apiserver [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.28 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew controller-manager.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка controller-manager.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.29 -

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd

Опис

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-healthcheck-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.30 -

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним

Опис

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-peer

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.31 -

Поновлює сертифікат для обслуговування etcd

Опис

Поновлює сертифікат для обслуговування etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-server

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.32 -

Поновлення сертифіката клієнта front proxy

Опис

Поновлення сертифіката клієнта front proxy.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка front-proxy-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.33 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew scheduler.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка scheduler.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.34 -

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew super-admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка super-admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.35 -

Виводить код завершення командного рядка для вказаного командного рядка (bash або zsh)

Опис

Виводить код завершення команд для вказаного командного інтерпретатора (bash або zsh). Код оболонки має бути використаний, щоб забезпечити інтерактивне завершення команд kubeadm. Це можна зробити, отримавши його з .bash_profile.

Примітка: Ця команда вимагає наявності пакету bash-completion.

Для встановлення на macOS використовуйте brew:

brew install bash-completion

Після встановлення bash-completion, вам потрібно додати наступний код у ваш файл .bash_profile:

source $(brew --prefix)/etc/bash_completion

Якщо bash-completion не встановлено у Linux, встановіть його за допомогою пакетного менеджера вашої системи.

Примітка для користувачів zsh: [1] zsh completion підтримується тількіи для версій zsh >= 5.2.

kubeadm completion SHELL [flags]

Приклади

# Встановлення bash completion на Mac за допомогою homebrew
brew install bash-completion
printf "\n# Bash completion support\nsource $(brew --prefix)/etc/bash_completion\n" >> $HOME/.bash_profile
source $HOME/.bash_profile

# Завантаження коду completion kubeadm для bash у поточну оболонку
source <(kubeadm completion bash)

# Запишіть код завершення bash у файл і викличте його з .bash_profile
kubeadm completion bash > ~/.kube/kubeadm_completion.bash.inc
printf "\n# Kubeadm shell completion\nsource '$HOME/.kube/kubeadm_completion.bash.inc'\n" >> $HOME/.bash_profile
source $HOME/.bash_profile

# Завантажте код завершення kubeadm для zsh[1] у поточну оболонку
source <(kubeadm completion zsh)

Параметри

-h, --help

Довідка completion

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36 -

Керування конфігурацією для кластера kubeadm, збереженою у ConfigMap у кластері

Опис

У просторі імен kube-system є ConfigMap з назвою "kubeadm-config", яку kubeadm використовує для зберігання внутрішньої конфігурації кластера. kubeadm CLI v1.8.0+ автоматично створює ConfigMap з конфігурацією, що використовується командою 'kubeadm init', але якщо ви ініціалізували кластер за допомогою kubeadm v1.7.x або нижчої версії, вам слід скористатися командою 'kubeadm init phase upload-config', щоб створити ConfigMap. Це необхідно для того, щоб команда 'kubeadm upgrade' могла правильно налаштувати ваш оновлений кластер.

kubeadm config [flags]

Параметри

-h, --help

Довідка config

--kubeconfig string     Default: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.1 -

Взаємодія з зображеннями контейнерів, які використовує kubeadm

Опис

Взаємодія з зображеннями контейнерів, які використовує kubeadm

kubeadm config images [flags]

Параметри

-h, --help

Доввідка images

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.2 -

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів

Опис

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів.

kubeadm config images list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли у шаблоні відсутнє поле або ключ мапи. Застосовується тільки до форматів виводу golang і jsonpath.

--config string

Шлях до файлу конфігурації kubeadm.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка list

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, зберігати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.3 -

Витягує образи які використовує kubeadm з реєстру

Опис

Витягує образи які використовує kubeadm з реєстру

kubeadm config images pull [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

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

--feature-gates string

Набір пар ключ=значення, що описують ворота функцій для різних можливостей. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка pull

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.4 -

Зчитує стару версію типів конфігураційного API kubeadm з файлу і виводе аналогічний обʼєкт конфігурації для нової версії

Опис

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

  • kubeadm.k8s.io/v1beta4

Крім того, kubeadm може записувати конфігурацію лише версії "kubeadm.k8s.io/v1beta4", але читати обидві версії. Отже, незалежно від того, яку версію ви передаєте параметру --old-config, API обʼєкт буде прочитано, десеріалізовано, встановлено стандартні значення, конвертовано, валідовано та повторно серіалізовано під час запису у stdout або --new-config, якщо вказано.

Іншими словами, вихід цієї команди є тим, що kubeadm фактично читав би внутрішньо, якщо ви надіслали б цей файл команді "kubeadm init".

kubeadm config migrate [flags]

Параметри

--allow-experimental-api

Дозволити міграцію на експериментальні, невипущені API

-h, --help

довідка migrate

--new-config string

Шлях до отриманого еквівалентного конфігураційного файлу kubeadm з використанням нової версії API. Необовʼязково, якщо не вказано, вивід буде надіслано у STDOUT.

--old-config string

Шлях до конфігураційного файлу kubeadm, який використовує стару версію API і який має бути конвертований. Цей прапорець є обовʼязковим.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.5 -

Вивід конфігурації

Опис

Ця команда виводить конфігурацію вказаних субкоманд. Докладніше: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Параметри

-h, --help

довідка print

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.6 -

Вивід стандартної конфігурації ініціалізації, яка може використовуватись у kubeadm init.

Опис

Ця команда виводить обʼєкти, такі як стандартну конфігурацію ініціалізації, які можуть бути використані у kubeadm init.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print init-defaults [flags]

Параметри

--component-configs strings

Список обʼєктів API конфігурації компонентів через кому для виводу типових значень. Доступні значення: [KubeProxyConfiguration KubeletConfiguration]. Якщо цей прапорець не встановлено, конфігурації компонентів не буде надруковано.

-h, --help

довідка init-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.7 -

Вивід стандартної конфігурації для команди kubeadm join.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди join, яка використовується для 'kubeadm join'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print join-defaults [flags]

Параметри

-h, --help

довідка join-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.8 -

Виводить стандартну конфігурацію для команди kubeadm reset.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди reset, яка використовується для 'kubeadm reset'.

Зауважте, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як "abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print reset-defaults [flags]

Параметри

-h, --help

Довідка reset-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.9 -

Виводить стандартну конфігурацію для оновлення, яка може бути використана для 'kubeadm upgrade'

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди upgrade, яка використовується для 'kubeadm upgrade'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print upgrade-defaults [flags]

Параметри

-h, --help

Довідка upgrade-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.36.10 -

Зчитує файл, що містить конфігураційний API kubeadm, і повідомляє про будь-які проблеми під час валідації

Опис

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

У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta4
kubeadm config validate [flags]

Параметри

--allow-experimental-api

Дозволяє валідацію експериментальних, невипущених API.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка validate

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.37 -

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів

Опис

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів.

kubeadm config images list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли у шаблоні відсутнє поле або ключ мапи. Застосовується тільки до форматів виводу golang і jsonpath.

--config string

Шлях до файлу конфігурації kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка list

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--show-managed-fields

Якщо true, зберігати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.38 -

Витягує образи які використовує kubeadm з реєстру

Опис

Витягує образи які використовує kubeadm з реєстру

kubeadm config images pull [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

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

--feature-gates string

Набір пар ключ=значення, що описують ворота функцій для різних можливостей. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка pull

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.39 -

Зчитує стару версію типів конфігураційного API kubeadm з файлу і виводе аналогічний обʼєкт конфігурації для нової версії

Опис

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

  • kubeadm.k8s.io/v1beta3

Крім того, kubeadm може записувати конфігурацію лише версії "kubeadm.k8s.io/v1beta3", але читати обидві версії. Отже, незалежно від того, яку версію ви передаєте параметру --old-config, API обʼєкт буде прочитано, десеріалізовано, встановлено стандартні значення, конвертовано, валідовано та повторно серіалізовано під час запису у stdout або --new-config, якщо вказано.

Іншими словами, вихід цієї команди є тим, що kubeadm фактично читав би внутрішньо, якщо ви надіслали б цей файл команді "kubeadm init".

kubeadm config migrate [flags]

Параметри

--allow-experimental-api

Дозволити міграцію на експериментальні, невипущені API

-h, --help

довідка migrate

--new-config string

Шлях до отриманого еквівалентного конфігураційного файлу kubeadm з використанням нової версії API. Необовʼязково, якщо не вказано, вивід буде надіслано у STDOUT.

--old-config string

Шлях до конфігураційного файлу kubeadm, який використовує стару версію API і який має бути конвертований. Цей прапорець є обовʼязковим.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.40 -

Вивід конфігурації

Опис

Ця команда виводить конфігурацію вказаних субкоманд. Докладніше: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Параметри

-h, --help

довідка print

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.41 -

Вивід стандартної конфігурації ініціалізації, яка може використовуватись у kubeadm init.

Опис

Ця команда виводить обʼєкти, такі як стандартну конфігурацію ініціалізації, які можуть бути використані у kubeadm init.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print init-defaults [flags]

Параметри

--component-configs strings

Список обʼєктів API конфігурації компонентів через кому для виводу типових значень. Доступні значення: [KubeProxyConfiguration KubeletConfiguration]. Якщо цей прапорець не встановлено, конфігурації компонентів не буде надруковано.

-h, --help

довідка init-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.42 -

Вивід стандартної конфігурації для команди kubeadm join.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди join, яка використовується для 'kubeadm join'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print join-defaults [flags]

Параметри

-h, --help

довідка join-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.43 -

Зчитує файл, що містить конфігураційний API kubeadm, і повідомляє про будь-які проблеми під час валідації

Опис

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

У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta3
kubeadm config validate [flags]

Параметри

--allow-experimental-api

Дозволяє валідацію експериментальних, невипущених API.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка validate

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.44 -

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Опис

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Команда "init" виконує наступні етапи:

preflight                     Виконання перевірок перед запуском
certs                         Генерація сертифікатів
  /ca                           Генерація самопідписаного CA Kubernetes для забезпечення ідентифікації інших компонентів Kubernetes
  /apiserver                    Генерація сертифіката для обслуговування Kubernetes API
  /apiserver-kubelet-client     Генерація сертифіката для зʼєднання API server з kubelet
  /front-proxy-ca               Генерація самопідписаного CA для забезпечення ідентифікації front proxy
  /front-proxy-client           Генерація сертифіката для клієнта front proxy
  /etcd-ca                      Генерація самопідписаного CA для забезпечення ідентифікації etcd
  /etcd-server                  Генерація сертифіката для обслуговування etcd
  /etcd-peer                    Генерація сертифіката для звʼязку між вузлами etcd
  /etcd-healthcheck-client      Генерація сертифіката для перевірки живучості etcd
  /apiserver-etcd-client        Генерація сертифіката, який використовується apiserver для доступу до etcd
  /sa                           Генерація приватного ключа для підписання токенів службових облікових записів разом з його відкритим ключем
kubeconfig                    Генерація всіх kubeconfig файлів, необхідних для створення панелі управління, та kubeconfig файлу адміністратора
  /admin                        Генерація kubeconfig файлу для використання адміністратором та самим kubeadm
  /super-admin                  Генерація kubeconfig файлу для супер-адміністратора
  /kubelet                      Генерація kubeconfig файлу для використання kubelet *лише* для завантаження кластера
  /controller-manager           Генерація kubeconfig файлу для використання контролер-менеджером
  /scheduler                    Генерація kubeconfig файлу для використання планувальником
etcd                          Генерація маніфесту статичного Pod для локального etcd
  /local                        Генерація маніфесту статичного Pod для локального, одновузлового локального etcd
control-plane                 Генерація всіх маніфестів статичних Podʼів, необхідних для створення панелі управління
  /apiserver                    Генерація маніфесту статичного Pod для kube-apiserver
  /controller-manager           Генерація маніфесту статичного Pod для kube-controller-manager
  /scheduler                    Генерація маніфесту статичного Pod для kube-scheduler
kubelet-start                 Запис налаштувань kubelet та (перезавантаження) kubelet
upload-config                 Завантаження конфігурації kubeadm та kubelet у ConfigMap
  /kubeadm                      Завантаження конфігурації кластера kubeadm у ConfigMap
  /kubelet                      Завантаження конфігурації компоненту kubelet у ConfigMap
upload-certs                  Завантаження сертифікатів у kubeadm-certs
mark-control-plane            Маркування вузла як вузла панелі управління
bootstrap-token               Генерація bootstrap токенів, які використовуються для приєднання вузла до кластера
kubelet-finalize             Оновлення налаштувань, що стосуються kubelet, після TLS завантаження
  /enable-client-cert-rotation  Ввімкнути ротацію сертифікатів клієнтів kubelet
  /experimental-cert-rotation   Ввімкнути ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: натомість використовуйте 'enable-client-cert-rotation')
  /experimental-cert-rotation  Увімкнення ротації сертифікатів клієнта kubelet
addon                        Встановлення необхідних надбудов для проходження тестів відповідності
  /coredns                     Встановлення надбудови CoreDNS у Kubernetes кластер
  /kube-proxy                  Встановлення надбудови kube-proxy у Kubernetes кластер
show-join-command            Показати команду приєднання для вузлів керування та робочих вузлів

kubeadm init [прапорці]

Параметри

--apiserver-advertise-address string

IP адреса, за якою API Server буде оголошувати, що він слухає. Якщо не встановлено, буде використаний стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого буде привʼязаний API Server.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях для збереження та зберігання сертифікатів.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane-endpoint string

Вкажіть стабільну IP адресу або DNS імʼя для панелі управління.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка init

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Виберіть конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вкажіть діапазон IP-адрес для мережі Podʼів. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для VIP сервісів.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад "myorg.internal".

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--skip-phases strings

Список етапів, які потрібно оминути

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

--token string

Токен для встановлення двосторонньої довіри між вузлами та вузлами панелі управління. Формат [a-z0-9]{6}.[a-z0-9]{16} — наприклад, abcdef.0123456789abcdef

--token-ttl duration     Типово: 24h0m0s

Час перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

[ЕКСПЕРИМЕНТАЛЬНО] Шлях до 'реальної' кореневої файлової системи хоста.

10.1.1.44.1 -

Використовуйте цю команду для виклику однієї фази робочого процесу init

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу init.

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.2 -

Встановлює необхідні надбудови для проходження тестів на відповідність

Опис

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

kubeadm init phase addon [flags]

Параметри

-h, --help

Довідка addon

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.3 -

Встановлює всі надбудови

Опис

Вставляє всі надбудови.

kubeadm init phase addon all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.4 -

Встановлює надбудову CoreDNS в кластер Kubernetes

Опис

Встановлює компоненти надбудови CoreDNS через сервер API. Зверніть увагу, що хоча DNS-сервер розгорнуто, його не буде заплановано, доки не буде встановлено CNI.

kubeadm init phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка coredns

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.5 -

Встановлює надбудову kube-proxy в кластер Kubernetes

Опис

Встановлює компоненти надбудови kube-proxy через API-сервер.

kubeadm init phase addon kube-proxy [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.6 -

Генерує токени bootstrap, які використовуються для приєднання вузла до кластера

Опис

Токени bootstrap використовуються для встановлення двосторонньої довіри між вузлом, що приєднується до кластера, і вузлом панелі управління.

Ця команда виконує всі налаштування, необхідні для роботи токенів bootstrap, а потім створює початковий токен.

kubeadm init phase bootstrap-token [flags]

Приклади

# Налаштувати всі конфігурації токенів Bootstrap та створити 
# початковий токен, функціонально еквівалентний до того, що 
# генерується командою kubeadm init.
kubeadm init phase bootstrap-token

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Довідка bootstrap-token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.7 -

Генерує сертифікати

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm init phase certs [flags]

Параметри

-h, --help

Довідка certs

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.8 -

Генерує всі сертифікати

Опис

Генерує всі сертифікати.

kubeadm init phase certs all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.9 -

Генерує сертифікати, які apiserver використовує для доступу до etcd

Опис

Генерує сертифікати, які apiserver використовує для доступу до etcd та зберігає їх у файлах apiserver-etcd-client.crt та apiserver-etcd-client.key

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-etcd-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.10 -

Генерує сертифікати для сервера API для зʼєднання з kubelet

Опис

Генерує сертифікати для сервера API для зʼєднання з kubelet та зберігає їх у файлах apiserver-kubelet-client.crt та apiserver-kubelet-client.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-kubelet-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.11 -

Генерує сертифікати для обслуговування API Kubernetes

Опис

Генерує сертифікати для обслуговування API Kubernetes та зберігає їх у файли apiserver.crt та apiserver.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver [flags]

Операції

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.12 -

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes

Опис

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes та зберігає їх у файлах ca.crt та ca.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.13 -

Генерує самопідписаний центр сертифікації для надання ідентифікаторів для etcd

Опис

Ця команда генерує самопідписаний центр сертифікації (CA) для надання ідентифікаторів для etcd, та зберігає їх у файлах etcd/ca.crt та etcd/ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.14 -

Генерує сертифікат для проб життєздатності для перевірки справності etcd

Опис

Генерує сертифікат для проб життєздатності для перевірки справності etcd, та зберігає його у файлах etcd/healthcheck-client.crt та etcd/healthcheck-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-healthcheck-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.15 -

Генгерує сертифікати для вузлів etcd для звʼязку між собою

Опис

Генерує сертифікати для вузлів etcd для звʼязку між собою, та зберігає їх у файлах etcd/peer.crt та etcd/peer.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-peer

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.16 -

Генерує сертифітати для обслуговування etcd

Опис

Генерує сертифікати для обслуговування etcd, та зберігає їх у файлах etcd/server.crt та etcd/server.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-server

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.17 -

Генерує самопідписні CA для надання ідентифікаторів для front proxy

Опис

Генерує самопідписні CA для надання ідентифікаторів для front proxy, та зберігає їх у файлах front-proxy-ca.crt та front-proxy-ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-ca [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.18 -

Генерує сетритфікати для клієнта front proxy

Опис

Генерує сертифікати для клієнта front proxy, та зберігає їх у файлах front-proxy-client.crt та front-proxy-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.19 -

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі

Опис

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі, та записує їх у файли sa.key та sa.pub.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs sa [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--kubeconfig string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка sa

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.20 -

Генерує всі маніфести статичних Podʼів потрібні для створення панелі управління

Опис

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

kubeadm init phase control-plane [flags]

Параметри

-h, --help

Довідка control-plane

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.21 -

Генерує всі фали маніфестів статичних Podʼів

Опис

Генерує всі файли маніфестів статичних Podʼів.

kubeadm init phase control-plane all [flags]

Приклади

# Генерує всі файли маніфестів статичних Podʼів для компонентів панелі управління,
# функціонально еквівалентні до тих, що генеруються командою kubeadm init.
kubeadm init phase control-plane all

# Генерує всі файли маніфестів статичних Podʼів з використанням опцій, отриманих з конфігураційного файлу.
kubeadm init phase control-plane all --config config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.22 -

Генерує маніфест статичного Podʼа для kube-apiserver

Опис

Генерує маніфест статичного Podʼа для kube-apiserver

kubeadm init phase control-plane apiserver [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка apiserver

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.23 -

Генерує маніфест статичного Podʼа для kube-controller-manager

Опис

Генерує маніфест статичного Podʼа для kube-controller-manager

kubeadm init phase control-plane controller-manager [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.24 -

Генерує маніфест статичного Podʼа для kube-scheduler

Опис

Генерує маніфест статичного Podʼа для kube-scheduler

kubeadm init phase control-plane scheduler [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.25 -

Генерує файл маніфесту статичного Podʼа для екземпляра local etcd

Опис

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

kubeadm init phase etcd [flags]

Параметри

-h, --help

Довідка etcd

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.26 -

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

kubeadm init phase etcd local [flags]

Приклади

# Генерує файл маніфесту статичного Podʼа для etcd, функціонально
# еквівалентного до того, що генерується командою kubeadm init.
kubeadm init phase etcd local

# Генерує файл маніфесту статичного Podʼа для etcd з використанням опцій
# отриманих з файлу конфігурації.
kubeadm init phase etcd local --config config.yaml

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка local

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.27 -

Генерує всі файли kubeconfig, необхідні для встановлення панелі управління та файл kubeconfig адміністратора

Опис

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

kubeadm init phase kubeconfig [flags]

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.28 -

Генерує файл kubeconfig для використання адміністратором та для самого kubeadm

Опис

Ця команда генерує файл kubeconfig для використання адміністратором та для самого kubeadm й зберігає його у файл admin.conf.

kubeadm init phase kubeconfig admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.29 -

Генерує всі файли kubeconfig

Опис

Генерує всі файли kubeconfig.

kubeadm init phase kubeconfig all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.30 -

Генерує файл kubeconfig для використання менеджером контролерів

Опис

Генерує файл kubeconfig для використання менеджером контролерів та зберігає його у файл controller-manager.conf.

kubeadm init phase kubeconfig controller-manager [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.31 -

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження

Опис

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження та зберігає його у файлі kubelet.conf.

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

kubeadm init phase kubeconfig kubelet [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.32 -

Генерує файл kubeconfig для використання планувальником

Опис

Генерує файл kubeconfig для використання планувальником та зберігає його у файл scheduler.conf.

kubeadm init phase kubeconfig scheduler [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.33 -

Генерує файл kubeconfig для суперкористувача

Опис

Генерує файл kubeconfig для суперкористувача та зберігає його у файл super-admin.conf.

kubeadm init phase kubeconfig super-admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка super-admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.34 -

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

Опис

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

kubeadm init phase kubelet-finalize [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS"
kubeadm init phase kubelet-finalize all --config

Параметри

-h, --help

Довідка kubelet-finalize

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.35 -

Запускає всі фази kubelet-finalize

Опис

Запускає всі фази kubelet-finalize.

kubeadm init phase kubelet-finalize all [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS
kubeadm init phase kubelet-finalize all --config

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.36 -

Вмикає ротацію сертифікатів клієнтів kubelet

Опис

Вмикає ротацію сертифікатів клієнтів kubelet

kubeadm init phase kubelet-finalize enable-client-cert-rotation [flags]

Параметри

Параметри успадковані від батьківських команд

--cert-dir string     Типово: "/var/run/kubernetes"

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--config string

Шлях до файлу конфігурації.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка enable-client-cert-rotation

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.37 -

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

Опис

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка experimental-cert-rotation

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.38 -

Записує налаштування kubelet та (пере)запускаємо kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запустимо kubelet.

kubeadm init phase kubelet-start [flags]

Приклади

# Записує файл динамічного оточення з прапорами kubelet з файлу InitConfiguration.
kubeadm init phase kubelet-start --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.39 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm init phase mark-control-plane [flags]

Приклади

# Застосовує мітку та taint панелі управління до поточного вузла, функціонально еквівалентно до того, що виконується командою kubeadm init.
kubeadm init phase mark-control-plane --config config.yaml

# Застосовує мітку та taint панелі управління до конкретного вузла
kubeadm init phase mark-control-plane --node-name myNode

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.40 -

Виконує передпольотні перевірки

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm init phase preflight [flags]

Приклади

# Виконує передпольотні перевірки для kubeadm init з конфігураційним файлом config.yaml
kubeadm init phase preflight --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.41 -

Показує команду join для панелі управління та робочого вузла

Опис

Показує команду join для панелі управління та робочого вузла.

kubeadm init phase show-join-command [flags]

Параметри

-h, --help

Довідка show-join-command

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.42 -

Завантажує сертифікати до kubeadm-certs

Опис

Завантажує сертифікати панелі управління в Secret kubeadm-certs

kubeadm init phase upload-certs [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка upload-certs

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.43 -

Завантажує конфігурації kubeadm та kubelet у ConfigMap

Опис

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

kubeadm init phase upload-config [flags]

Параметри

-h, --help

Довідка upload-config

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.44 -

Завантажуємо всю конфігурацію в ConfigMap

Опис

Завантажує всю конфігурацію в ConfigMap.

kubeadm init phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.45 -

Завантажує kubeadm ClusterConfiguration у ConfigMap

Опис

Завантажує конфігурацію кластера kubeadm ClusterConfig до ConfigMap з назвою kubeadm-config у просторі імен kube-system. Це дозволить правильно конфігурувати компоненти системи та спростить роботу користувачів під час оновлення.

Альтернативно, ви можете використовувати kubeadm config.

kubeadm init phase upload-config kubeadm [flags]

Приклади

# Завантаження конфігурації кластера
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

Параметри

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeadm

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.44.46 -

Завантажує налаштування компонентів kubelet у ConfigMap

Опис

Завантажуємо конфігурацію kubelet, видобуту з обʼєкта kubeadm InitConfiguration, до ConfigMap kubelet-config у кластері

kubeadm init phase upload-config kubelet [flags]

Приклади

# Завантаження конфігурації kubelet з файла конфігурації kubeadm у ConfigMap в кластері
kubeadm init phase upload-config kubelet --config kubeadm.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.45 -

Використовуйте цю команду для виклику однієї фази робочого процесу init

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу init.

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.46 -

Встановлює необхідні надбудови для проходження тестів на відповідність

Опис

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

kubeadm init phase addon [flags]

Параметри

-h, --help

Довідка addon

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.47 -

Встановлює всі надбудови

Опис

Вставляє всі надбудови.

kubeadm init phase addon all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.48 -

Встановлює надбудову CoreDNS в кластер Kubernetes

Опис

Встановлює компоненти надбудови CoreDNS через сервер API. Зверніть увагу, що хоча DNS-сервер розгорнуто, його не буде заплановано, доки не буде встановлено CNI.

kubeadm init phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка coredns

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.49 -

Встановлює надбудову kube-proxy в кластер Kubernetes

Опис

Встановлює компоненти надбудови kube-proxy через API-сервер.

kubeadm init phase addon kube-proxy [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.50 -

Генерує токени bootstrap, які використовуються для приєднання вузла до кластера

Опис

Токени bootstrap використовуються для встановлення двосторонньої довіри між вузлом, що приєднується до кластера, і вузлом панелі управління.

Ця команда виконує всі налаштування, необхідні для роботи токенів bootstrap, а потім створює початковий токен.

kubeadm init phase bootstrap-token [flags]

Приклади

# Налаштувати всі конфігурації токенів Bootstrap та створити 
# початковий токен, функціонально еквівалентний до того, що 
# генерується командою kubeadm init.
kubeadm init phase bootstrap-token

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Довідка bootstrap-token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.51 -

Генерує сертифікати

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm init phase certs [flags]

Параметри

-h, --help

Довідка certs

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.52 -

Генерує всі сертифікати

Опис

Генерує всі сертифікати.

kubeadm init phase certs all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.53 -

Генерує сертифікати, які apiserver використовує для доступу до etcd

Опис

Генерує сертифікати, які apiserver використовує для доступу до etcd та зберігає їх у файлах apiserver-etcd-client.crt та apiserver-etcd-client.key

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-etcd-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.54 -

Генерує сертифікати для сервера API для зʼєднання з kubelet

Опис

Генерує сертифікати для сервера API для зʼєднання з kubelet та зберігає їх у файлах apiserver-kubelet-client.crt та apiserver-kubelet-client.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-kubelet-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.55 -

Генерує сертифікати для обслуговування API Kubernetes

Опис

Генерує сертифікати для обслуговування API Kubernetes та зберігає їх у файли apiserver.crt та apiserver.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver [flags]

Операції

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.56 -

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes

Опис

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes та зберігає їх у файлах ca.crt та ca.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.57 -

Генерує самопідписаний центр сертифікації для надання ідентифікаторів для etcd

Опис

Ця команда генерує самопідписаний центр сертифікації (CA) для надання ідентифікаторів для etcd, та зберігає їх у файлах etcd/ca.crt та etcd/ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.58 -

Генерує сертифікат для проб життєздатності для перевірки справності etcd

Опис

Генерує сертифікат для проб життєздатності для перевірки справності etcd, та зберігає його у файлах etcd/healthcheck-client.crt та etcd/healthcheck-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-healthcheck-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.59 -

Генгерує сертифікати для вузлів etcd для звʼязку між собою

Опис

Генерує сертифікати для вузлів etcd для звʼязку між собою, та зберігає їх у файлах etcd/peer.crt та etcd/peer.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-peer

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.60 -

Генерує сертифітати для обслуговування etcd

Опис

Генерує сертифікати для обслуговування etcd, та зберігає їх у файлах etcd/server.crt та etcd/server.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-server

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.61 -

Генерує самопідписні CA для надання ідентифікаторів для front proxy

Опис

Генерує самопідписні CA для надання ідентифікаторів для front proxy, та зберігає їх у файлах front-proxy-ca.crt та front-proxy-ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-ca [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.62 -

Генерує сетритфікати для клієнта front proxy

Опис

Генерує сертифікати для клієнта front proxy, та зберігає їх у файлах front-proxy-client.crt та front-proxy-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.63 -

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі

Опис

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі, та записує їх у файли sa.key та sa.pub.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs sa [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

-h, --help

Довідка sa

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.64 -

Генерує всі маніфести статичних Podʼів потрібні для створення панелі управління

Опис

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

kubeadm init phase control-plane [flags]

Параметри

-h, --help

Довідка control-plane

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.65 -

Генерує всі фали маніфестів статичних Podʼів

Опис

Генерує всі файли маніфестів статичних Podʼів.

kubeadm init phase control-plane all [flags]

Приклади

# Генерує всі файли маніфестів статичних Podʼів для компонентів панелі управління,
# функціонально еквівалентні до тих, що генеруються командою kubeadm init.
kubeadm init phase control-plane all

# Генерує всі файли маніфестів статичних Podʼів з використанням опцій, отриманих з конфігураційного файлу.
kubeadm init phase control-plane all --config config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--apiserver-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до API Server або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--controller-manager-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Controller Manager або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--scheduler-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Scheduler або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.66 -

Генерує маніфест статичного Podʼа для kube-apiserver

Опис

Генерує маніфест статичного Podʼа для kube-apiserver

kubeadm init phase control-plane apiserver [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--apiserver-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до API Server або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка apiserver

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.67 -

Генерує маніфест статичного Podʼа для kube-controller-manager

Опис

Генерує маніфест статичного Podʼа для kube-controller-manager

kubeadm init phase control-plane controller-manager [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--controller-manager-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Controller Manager або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.68 -

Генерує маніфест статичного Podʼа для kube-scheduler

Опис

Генерує маніфест статичного Podʼа для kube-scheduler

kubeadm init phase control-plane scheduler [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--scheduler-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Scheduler або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.69 -

Генерує файл маніфесту статичного Podʼа для екземпляра local etcd

Опис

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

kubeadm init phase etcd [flags]

Параметри

-h, --help

Довідка etcd

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.70 -

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

kubeadm init phase etcd local [flags]

Приклади

# Генерує файл маніфесту статичного Podʼа для etcd, функціонально
# еквівалентного до того, що генерується командою kubeadm init.
kubeadm init phase etcd local

# Генерує файл маніфесту статичного Podʼа для etcd з використанням опцій
# отриманих з файлу конфігурації.
kubeadm init phase etcd local --config config.yaml

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка local

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.71 -

Генерує всі файли kubeconfig, необхідні для встановлення панелі управління та файл kubeconfig адміністратора

Опис

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

kubeadm init phase kubeconfig [flags]

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.72 -

Генерує файл kubeconfig для використання адміністратором та для самого kubeadm

Опис

Ця команда генерує файл kubeconfig для використання адміністратором та для самого kubeadm й зберігає його у файл admin.conf.

kubeadm init phase kubeconfig admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.73 -

Генерує всі файли kubeconfig

Опис

Генерує всі файли kubeconfig.

kubeadm init phase kubeconfig all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.74 -

Генерує файл kubeconfig для використання менеджером контролерів

Опис

Генерує файл kubeconfig для використання менеджером контролерів та зберігає його у файл controller-manager.conf.

kubeadm init phase kubeconfig controller-manager [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.75 -

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження

Опис

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження та зберігає його у файлі kubelet.conf.

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

kubeadm init phase kubeconfig kubelet [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.76 -

Генерує файл kubeconfig для використання планувальником

Опис

Генерує файл kubeconfig для використання планувальником та зберігає його у файл scheduler.conf.

kubeadm init phase kubeconfig scheduler [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.77 -

Генерує файл kubeconfig для суперкористувача

Опис

Генерує файл kubeconfig для суперкористувача та зберігає його у файл super-admin.conf.

kubeadm init phase kubeconfig super-admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка super-admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.78 -

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

Опис

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

kubeadm init phase kubelet-finalize [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS"
kubeadm init phase kubelet-finalize all --config

Параметри

-h, --help

Довідка kubelet-finalize

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.79 -

Запускає всі фази kubelet-finalize

Опис

Запускає всі фази kubelet-finalize.

kubeadm init phase kubelet-finalize all [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS
kubeadm init phase kubelet-finalize all --config

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.80 -

Вмикає ротацію сертифікатів клієнтів kubelet

Опис

Вмикає ротацію сертифікатів клієнтів kubelet.

kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка experimental-cert-rotation

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.81 -

Записує налаштування kubelet та (пере)запускаємо kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запустимо kubelet.

kubeadm init phase kubelet-start [flags]

Приклади

# Записує файл динамічного оточення з прапорами kubelet з файлу InitConfiguration.
kubeadm init phase kubelet-start --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.82 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm init phase mark-control-plane [flags]

Приклади

# Застосовує мітку та taint панелі управління до поточного вузла, функціонально еквівалентно до того, що виконується командою kubeadm init.
kubeadm init phase mark-control-plane --config config.yaml

# Застосовує мітку та taint панелі управління до конкретного вузла
kubeadm init phase mark-control-plane --node-name myNode

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.83 -

Виконує передпольотні перевірки

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm init phase preflight [flags]

Приклади

# Виконує передпольотні перевірки для kubeadm init з конфігураційним файлом config.yaml
kubeadm init phase preflight --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.84 -

Показує команду join для панелі управління та робочого вузла

Опис

Показує команду join для панелі управління та робочого вузла.

kubeadm init phase show-join-command [flags]

Параметри

-h, --help

Довідка show-join-command

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.85 -

Завантажує сертифікати до kubeadm-certs

Опис

Завантажує сертифікати панелі управління в Secret kubeadm-certs

kubeadm init phase upload-certs [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка upload-certs

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.86 -

Завантажує конфігурації kubeadm та kubelet у ConfigMap

Опис

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

kubeadm init phase upload-config [flags]

Параметри

-h, --help

Довідка upload-config

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.87 -

Завантажуємо всю конфігурацію в ConfigMap

Опис

Завантажує всю конфігурацію в ConfigMap.

kubeadm init phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.88 -

Завантажує kubeadm ClusterConfiguration у ConfigMap

Опис

Завантажує конфігурацію кластера kubeadm ClusterConfig до ConfigMap з назвою kubeadm-config у просторі імен kube-system. Це дозволить правильно конфігурувати компоненти системи та спростить роботу користувачів під час оновлення.

Альтернативно, ви можете використовувати kubeadm config.

kubeadm init phase upload-config kubeadm [flags]

Приклади

# Завантаження конфігурації кластера
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

Параметри

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeadm

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.89 -

Завантажує налаштування компонентів kubelet у ConfigMap

Опис

Завантажуємо конфігурацію kubelet, видобуту з обʼєкта kubeadm InitConfiguration, до ConfigMap kubelet-config у кластері

kubeadm init phase upload-config kubelet [flags]

Приклади

# Завантаження конфігурації kubelet з файла конфігурації kubeadm у ConfigMap в кластері
kubeadm init phase upload-config kubelet --config kubeadm.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.90 -

Запустіть цю команду на будь-якому компʼютері, який ви хочете приєднати до існуючого кластера

Опис

Під час приєднання до ініціалізованого кластера за допомогою kubeadm, необхідно встановити двосторонню довіру. Цей процес розділяється на два етапи: виявлення (щоб Node довіряв Панелі Управління Kubernetes) та TLS завантаження (щоб Панель управління Kubernetes довіряла Node).

Існує дві основні схеми для виявлення. Перша — використовувати спільний токен разом з IP-адресою сервера API. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go ("exec"), "tokenFile" та "authProvider". Цей файл може бути локальним або завантаженим через URL HTTPS. Форми приєднання є:

kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
kubeadm join --discovery-file path/to/file.conf
kubeadm join --discovery-file https://url/file.conf

Можна використовувати лише одну форму. Якщо інформація для виявлення завантажується з URL, обовʼязково використовувати HTTPS. У цьому випадку для перевірки зʼєднання використовується встановлений на хості набір сертифікатів CA.

Якщо ви використовуєте спільний токен для виявлення, слід також передати прапорець --discovery-token-ca-cert-hash для перевірки публічного ключа кореневого центру сертифікації (CA), який представлений Панеллю Управління Kubernetes. Значення цього прапорця визначається як "<тип-хешу>:<шестнадцяткове-кодоване-значення>", де підтримуваний тип хешу — "sha256". Хеш обчислюється по байтах обʼєкта Subject Public Key Info (SPKI) (як в RFC7469). Це значення доступне у вихідних даних "kubeadm init" або може бути обчислене за допомогою стандартних інструментів. Прапорець --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити використання більше одного публічного ключа.

Якщо ви не можете знати хеш публічного ключа CA заздалегідь, ви можете передати прапорець --discovery-token-unsafe-skip-ca-verification для вимкнення цієї перевірки. Це послаблює модель безпеки kubeadm, оскільки інші вузли можуть потенційно видавати себе за Панель Управління Kubernetes.

Механізм TLS завантаження також керується через спільний токен. Це використовується для тимчасової автентифікації в Панелі Управління Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів. Типово, kubeadm налаштує Панель Управління Kubernetes автоматично схвалювати ці запити на підписання. Цей токен передається за допомогою прапорця --tls-bootstrap-token abcdef.1234567890abcdef.

Часто той самий токен використовується для обох частин. У цьому випадку прапорець --token можна використовувати замість окремого зазначення кожного токена.

Команда "join [api-server-endpoint]" виконує наступні фази:

preflight              Виконати передстартові перевірки для приєднання
control-plane-prepare  Підготувати машину для обслуговування панелі управління
  /download-certs        Завантажити сертифікати, спільні для вузлів панелі управління, з Secret kubeadm-certs
  /certs                 Створити сертифікати для нових компонентів панелі управління
  /kubeconfig            Створити kubeconfig для нових компонентів панелі управління
  /control-plane         Створити маніфести для нових компонентів панелі управління
kubelet-start          Записати налаштування kubelet, сертифікати та (перезавантажити) kubelet
control-plane-join     Приєднати машину як екземпляр панелі управління
  /etcd                  Додати нового локального члена etcd
  /mark-control-plane    Позначити вузол як панель управління
wait-control-plane     Експериментально: чекати запуску панелі управління

kubeadm join [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

Якщо вузол має хостити новий екземпляр панелі управління, IP-адреса, яку сервер API буде оголошувати як ту, на якій він слухає. Якщо не встановлено, буде використовуватися стандартний інтерфейс.

--apiserver-bind-port int32     Стандартно: 6443

Якщо вузол має хостити новий екземпляр панелі управління, порт, до якого буде привʼязаний сервер API.

--certificate-key string

Використовуйте цей ключ для розшифрування секретів сертифікатів, завантажених за допомогою init. Ключ сертифіката — це шестнадцятковий закодований рядок, який є AES ключем розміром 32 байти.

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка join

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вказати імʼя вузла.

--patches string

Шлях до теки, що містить файли з назвами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json" і відповідають форматам патчів, підтримуваних kubectl. Типовий "patchtype" — "strategic". "extension" має бути або "json", або "yaml". "suffix" — це необовʼязковий рядок, який можна використовувати для визначення, які патчі застосовуються першими в алфавітно-числовому порядку.

--skip-phases strings

Список фаз, які потрібно пропустити

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.1 -

Використовуйте цю команду для виклику однієї фази робочого процесу join

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу join

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.2 -

Приєднує машину до екземпляра панелі управління

Опис

Приєднує машину до екземпляра панелі управління.

kubeadm join phase control-plane-join [flags]

Приклади

# Приєднує машину до екземпляра панелі управління
kubeadm join phase control-plane-join all

Параметри

-h, --help

Довідка control-plane-join

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.3 -

Приєднує машину до екземпляру панелі управління

Опис

Приєднує машину до екземпляру панелі управління.

kubeadm join phase control-plane-join all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.4 -

Додає нового учасника local etcd

Опис

Додає нового учасника local etcd

kubeadm join phase control-plane-join etcd [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.5 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm join phase control-plane-join mark-control-plane [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.6 -

Готує машину до обслуговування панелі управління

Опис

Готує машину до обслуговування панелі управління.

kubeadm join phase control-plane-prepare [flags]

Приклади

# Готує машину до обслуговування панелі управління
kubeadm join phase control-plane-prepare all

Параметри

-h, --help

Довідка control-plane-prepare

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.7 -

Готує машину для роботи як панелі управління

Опис

Готує машину для роботи як панелі управління.

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.8 -

Генерує сертифікати для нових компенонетів панелі управління

Опис

Генерує сертифікати для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка certs

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.9 -

Генерує маніфести для нових компонентів панелі управління

Опис

Генерує маніфести для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare control-plane [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка control-plane

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.10 -

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

Опис

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка download-certs

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.11 -

Генерує kubeconfig для нових компонентів панелі управління

Опис

Генерує kubeconfig для нових компонентів панелі управління, які будуть додані до кластера.

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeconfig

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.12 -

Записує налаштування kubelet, сертифікати та (пере)запускає kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запускає kubelet.

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

Параметри

tr>
--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.13 -

Виконує передполітні перевірки join

Опис

Виконує передполітні перевірки для kubeadm join.

kubeadm join phase preflight [api-server-endpoint] [flags]

Приклади

# Виконує передполітні перевірки для kubeadm join
kubeadm join phase preflight --config kubeadm-config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.90.14 -

[EXPERIMENTAL] Очікує запуску панелі управління

Опис

[EXPERIMENTAL] Очікує запуску панелі управління

kubeadm join phase wait-control-plane [flags]

Параметри

-h, --help

Довідка wait-control-plane

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.91 -

Використовуйте цю команду для виклику однієї фази робочого процесу join

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу join

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.92 -

Приєднує машину до екземпляра панелі управління

Опис

Приєднує машину до екземпляра панелі управління.

kubeadm join phase control-plane-join [flags]

Приклади

# Приєднує машину до екземпляра панелі управління
kubeadm join phase control-plane-join all

Параметри

-h, --help

Довідка control-plane-join

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.93 -

Приєднує машину до екземпляру панелі управління

Опис

Приєднує машину до екземпляру панелі управління.

kubeadm join phase control-plane-join all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.94 -

Додає нового учасника local etcd

Опис

Додає нового учасника local etcd

kubeadm join phase control-plane-join etcd [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.95 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm join phase control-plane-join mark-control-plane [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.96 -

Реєструє новий вузол панелі управління у ClusterStatus, який підтримується у kubeadm-config ConfigMap ("DEPRECATED")

Опис

Реєструє новий вузол панелі управління у ClusterStatus, який підтримується у kubeadm-config ConfigMap ("DEPRECATED")

kubeadm join phase control-plane-join update-status [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

-h, --help

Довідка update-status

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.97 -

Готує машину до обслуговування панелі управління

Опис

Готує машину до обслуговування панелі управління.

kubeadm join phase control-plane-prepare [flags]

Приклади

# Готує машину до обслуговування панелі управління
kubeadm join phase control-plane-prepare all

Параметри

-h, --help

Довідка control-plane-prepare

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.98 -

Готує машину для роботи як панелі управління

Опис

Готує машину для роботи як панелі управління.

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.99 -

Генерує сертифікати для нових компенонетів панелі управління

Опис

Генерує сертифікати для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка certs

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.100 -

Генерує маніфести для нових компонентів панелі управління

Опис

Генерує маніфести для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare control-plane [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка control-plane

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.101 -

[EXPERIMENTAL] Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

Опис

[EXPERIMENTAL] Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка download-certs

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.102 -

Генерує kubeconfig для нових компонентів панелі управління

Опис

Генерує kubeconfig для нових компонентів панелі управління, які будуть додані до кластера.

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeconfig

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.103 -

Записує налаштування kubelet, сертифікати та (пере)запускає kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запускає kubelet.

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

Параметри

tr>
--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.104 -

Виконує передполітні перевірки join

Опис

Виконує передполітні перевірки для kubeadm join.

kubeadm join phase preflight [api-server-endpoint] [flags]

Приклади

# Виконує передполітні перевірки для kubeadm join
kubeadm join phase preflight --config kubeadm-config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.105 -

[EXPERIMENTAL] Очікує запуску панелі управління

Опис

[EXPERIMENTAL] Очікує запуску панелі управління

kubeadm join phase wait-control-plane [flags]

Параметри

-h, --help

Довідка wait-control-plane

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.106 -

Файлові утиліти Kubeconfig

Опис

Файлові утиліти Kubeconfig.

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.106.1 -

Виводить файл kubeconfig для додаткового користувача

Опис

Виводить файл kubeconfig для додаткового користувача.

kubeadm kubeconfig user [flags]

Приклади

# Виводить файл kubeconfig для додаткового користувача з іменем foo
kubeadm kubeconfig user --client-name=foo

# Виводить файл kubeconfig для додаткового користувача з іменем foo, використовуючи конфігураційний файл kubeadm bar
kubeadm kubeconfig user --client-name=foo --config=bar

Параметри

--client-name string

Імʼя користувача. Буде використовуватися як CN у разі створення клієнтських сертифікатів

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка user

--org strings

Організації сертифіката клієнта. Буде використовуватися як O, якщо будуть створені клієнтські сертифікати

--token string

TТокен, який слід використовувати як механізм автентифікації для цього kubeconfig замість клієнтських сертифікатів

--validity-period duration     Типово: 8760h0m0s

Термін дії клієнтського сертифіката. Відраховується від поточного часу.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.107 -

Виводить файл kubeconfig для додаткового користувача

Опис

Виводить файл kubeconfig для додаткового користувача.

kubeadm kubeconfig user [flags]

Приклади

# Виводить файл kubeconfig для додаткового користувача з іменем foo
kubeadm kubeconfig user --client-name=foo

# Виводить файл kubeconfig для додаткового користувача з іменем foo, використовуючи конфігураційний файл kubeadm bar
kubeadm kubeconfig user --client-name=foo --config=bar

Параметри

--client-name string

Імʼя користувача. Буде використовуватися як CN у разі створення клієнтських сертифікатів

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка user

--org strings

Організації сертифіката клієнта. Буде використовуватися як O, якщо будуть створені клієнтські сертифікати

--token string

TТокен, який слід використовувати як механізм автентифікації для цього kubeconfig замість клієнтських сертифікатів

--validity-period duration     Типово: 8760h0m0s

Термін дії клієнтського сертифіката. Відраховується від поточного часу.

Параметри успадковані від батьківських команд

--rootfs string

[ЕКСПЕРИМЕНТАЛЬНО] Шлях до "справжньої" кореневої файлової системи хоста.

10.1.1.108 -

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Опис

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Команда "reset" виконує наступні фази:

preflight           Запуск попередніх перевірок
remove-etcd-member  Вилучення локального учасника etcd.
cleanup-node        Запуск очищення вузла.

kubeadm reset [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях до теки, де зберігаються сертифікати. Якщо вказано, очистити цю теку.

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

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

--dry-run

Не вносити жодних змін; лише вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

довідка reset

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-phases strings

Список фаз, які слід пропустити

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.108.1 -

Використовуйте цю команду для виклику однієї фази процесу reset

Опис

Використовуйте цю команду для виклику однієї фази процесу reset

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.108.2 -

Запускає очищення вузла

Опис

Запускає очищення вузла.

kubeadm reset phase cleanup-node [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка cleanup-node

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.108.3 -

Виконує передполітні перевірки для kubeadm reset

Опис

Виконує передполітні перевірки для kubeadm reset.

kubeadm reset phase preflight [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.108.4 -

Видаляє члена local etcd

Опмс

Видаляє члена local etcd для вузла панелі управління.

kubeadm reset phase remove-etcd-member [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка remove-etcd-member

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.109 -

Використовуйте цю команду для виклику однієї фази процесу reset

Опис

Використовуйте цю команду для виклику однієї фази процесу reset

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.110 -

Запускає очищення вузла

Опис

Запускає очищення вузла.

kubeadm reset phase cleanup-node [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка cleanup-node

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.111 -

Виконує передполітні перевірки для kubeadm reset

Опис

Виконує передполітні перевірки для kubeadm reset.

kubeadm reset phase preflight [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.112 -

Видаляє члена local etcd

Опмс

Видаляє члена local etcd для вузла панелі управління.

kubeadm reset phase remove-etcd-member [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка remove-etcd-member

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.113 -

Керує токенами bootstrap

Опис

Ця команда управляє bootstrap токенами. Вона є опціональною та необхідна лише для розширених випадків використання.

Коротко кажучи, bootstrap токени використовуються для встановлення двосторонньої довіри між клієнтом і сервером. Bootstrap токен може бути використаний, коли клієнт (наприклад, вузол, який збирається приєднатися до кластера) має довіряти серверу, з яким він взаємодіє. У цьому випадку можна використовувати bootstrap токен з дозволом на "підписування" ("signing"). Bootstrap токени також можуть функціонувати як спосіб дозволити короткострокову автентифікацію на API сервері (токен слугує способом, щоб API сервер довіряв клієнту), наприклад, для виконання TLS Bootstrap.

Що таке bootstrap токен більш конкретно?

  • Це Secret у просторі імен kube-system типу "bootstrap.kubernetes.io/token".
  • Bootstrap токен повинен мати форму "[a-z0-9]{6}.[a-z0-9]{16}". Перша частина є публічним ідентифікатором токена, а друга — секретом токена, який повинен бути збережений у таємниці за будь-яких обставин!
  • Назва Secret повинна бути "bootstrap-token-(token-id)".

Більше інформації про bootstrap токени можна знайти тут: https://kubernetes.io/docs/admin/bootstrap-tokens/

kubeadm token [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.113.1 -

Створює токени запуску на сервері.

Опис

Ця команда створює токен запуску для вас. Ви можете вказати способи використання цього токену, "час життя" і необовʼязковий опис, зрозумілий людині.

[token] — це власне токен, який потрібно записати. Це має бути безпечно згенерований випадковий токен виду "[a-z0-9]{6}.[a-z0-9]{16}". Якщо [token] не вказано, kubeadm згенерує випадковий токен замість нього.

kubeadm token create [token]

Параметри

--certificate-key string

Якщо використовується разом із '--print-join-command', виводить повний прапорець 'kubeadm join', необхідний для приєднання до кластера як панелі управління. Щоб створити новий ключ сертифіката, потрібно використовувати 'kubeadm init phase upload-certs --upload-certs'.

--config string

Шлях до файлу конфігурації kubeadm.

--description string

Опис, зрозумілий для людини, як використовується цей токен.

--groups strings     Типово: "system:bootstrappers:kubeadm:default-node-token"

Додаткові групи, які будуть автентифікуватися за допомогою цього токена при використанні для автентифікації. Повинно відповідати "\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z"

-h, --help

довідка create

--print-join-command

Замість того, щоб виводити тільки токен, вивести повний прапорець 'kubeadm join', необхідний для приєднання до кластера за допомогою токена.

--ttl duration     Типово: 24h0m0s

Тривалість перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться.

--usages strings     Типово: "signing,authentication"

Описує способи, в яких цей токен може використовуватися. Ви можете передавати --usages кілька разів або надати список параметрів через кому. Дійсні параметри: [signing,authentication]

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.113.2 -

Видаляє токени запуску на сервері.

Опис

Ця команда видаляє токени запуску для вас.

Значення [token-value] — це повний токен у вигляді "[a-z0-9]{6}.[a-z0-9]{16}" або Token ID виду "[a-z0-9]{6}", який потрібно видалити.

kubeadm token delete [token-value] ...

Параметри

-h, --help

довідка delete

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.113.3 -

Генерує та виводить токен запуску, але не створює його на сервері

Опис

Ця команда виведе випадково згенерований токен запуску, який можна використовувати з командами "init" та "join".

Ви не зобовʼязані використовувати цю команду для створення токена. Ви можете зробити це самостійно, якщо він має формат "[a-z0-9]{6}.[a-z0-9]{16}". Ця команда надається для зручності створення токенів у зазначеному форматі.

Ви також можете використовувати "kubeadm init" без вказання токена, і він буде згенерований та виведений для вас.

kubeadm token generate [flags]

Параметри

-h, --help

довідка generate

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.113.4 -

Виводить перелік токенів запуску на сервері

Опис

Ця команда виведе перелік всіх токенів запуску на сервері.

kubeadm token list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігноруйте будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang і jsonpath.

-h, --help

довідка list

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залиште managedFields під час вводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.114 -

Створює токени запуску на сервері.

Опис

Ця команда створює токен запуску для вас. Ви можете вказати способи використання цього токену, "час життя" і необовʼязковий опис, зрозумілий людині.

[token] — це власне токен, який потрібно записати. Це має бути безпечно згенерований випадковий токен виду "[a-z0-9]{6}.[a-z0-9]{16}". Якщо [token] не вказано, kubeadm згенерує випадковий токен замість нього.

kubeadm token create [token]

Параметри

--certificate-key string

Якщо використовується разом із '--print-join-command', виводить повний прапорець 'kubeadm join', необхідний для приєднання до кластера як панелі управління. Щоб створити новий ключ сертифіката, потрібно використовувати 'kubeadm init phase upload-certs --upload-certs'.

--config string

Шлях до файлу конфігурації kubeadm.

--description string

Опис, зрозумілий для людини, як використовується цей токен.

--groups strings     Типово: "system:bootstrappers:kubeadm:default-node-token"

Додаткові групи, які будуть автентифікуватися за допомогою цього токена при використанні для автентифікації. Повинно відповідати "\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z"

-h, --help

довідка create

--print-join-command

Замість того, щоб виводити тільки токен, вивести повний прапорець 'kubeadm join', необхідний для приєднання до кластера за допомогою токена.

--ttl duration     Типово: 24h0m0s

Тривалість перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться.

--usages strings     Типово: "signing,authentication"

Описує способи, в яких цей токен може використовуватися. Ви можете передавати --usages кілька разів або надати список параметрів через кому. Дійсні параметри: [signing,authentication]

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.115 -

Видаляє токени запуску на сервері.

Опис

Ця команда видаляє токени запуску для вас.

Значення [token-value] — це повний токен у вигляді "[a-z0-9]{6}.[a-z0-9]{16}" або Token ID виду "[a-z0-9]{6}", який потрібно видалити.

kubeadm token delete [token-value] ...

Параметри

-h, --help

довідка delete

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.116 -

Генерує та виводить токен запуску, але не створює його на сервері

Опис

Ця команда виведе випадково згенерований токен запуску, який можна використовувати з командами "init" та "join".

Ви не зобовʼязані використовувати цю команду для створення токена. Ви можете зробити це самостійно, якщо він має формат "[a-z0-9]{6}.[a-z0-9]{16}". Ця команда надається для зручності створення токенів у зазначеному форматі.

Ви також можете використовувати "kubeadm init" без вказання токена, і він буде згенерований та виведений для вас.

kubeadm token generate [flags]

Параметри

-h, --help

довідка generate

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.117 -

Виводить перелік токенів запуску на сервері

Опис

Ця команда виведе перелік всіх токенів запуску на сервері.

kubeadm token list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігноруйте будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang і jsonpath.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

-h, --help

довідка list

--show-managed-fields

Якщо true, залиште managedFields під час вводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.118 -

Оновлення кластера до новішої версії відбувається плавно за допомогою цієї команди

Опис

Оновлення кластера до новішої версії відбувається плавно за допомогою цієї команди

kubeadm upgrade [flags]

Параметри

-h, --help

Довідка upgrade

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.119 -

Оновлює кластер Kubernetes до вказаної версії.

Опис

Оновлює кластер Kubernetes до вказаної версії.

kubeadm upgrade apply [version]

Параметри

--allow-experimental-upgrades

Показує нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/версій кандидатів Kubernetes.

--allow-release-candidate-upgrades

Показує версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволяє оновлювати до версій кандидатів на випуск Kubernetes.

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-f, --force

Примусове оновлення, навіть якщо деякі вимоги можуть бути не виконані. Це також передбачає неітерактивний режим.

-h, --help

довідка apply

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, які підтримуються kubectl. За замовчуванням "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який може використовуватися для визначення порядку застосування патчів за алфавітом.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

-y, --yes

Виконати оновлення і не запитувати підтвердження (режим без взаємодії).

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.120 -

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

Опис

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

-c, --context-lines int     Типово: 3

Скільки рядків контексту в виведенні diff.

-h, --help

довідка diff

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.121 -

Команда upgrade для вузлів в кластері

Опис

Команда upgrade для вузлів в кластері.

Команда "node" виконує наступні фази:

preflight       Виконання попереднії перевірок оновлення вузла
control-plane   Оновлення екземпляру панелі управління, розгорнутий на цьому вузлі, якщо такий є
kubelet-config  Оновлення конфігурацію kubelet для цього вузла

kubeadm upgrade node [flags]

Параметри

--certificate-renewal     Типово: true

Виконати оновлення сертифікатів, використовуваних компонентами, які змінюються під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконати оновлення etcd.

-h, --help

довідка node

--ignore-preflight-errors strings

Список перевірок, помилки в яких будуть відображені як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" - це необовʼязковий рядок, який може використовуватися для визначення порядку застосування патчів за алфавітном.

--skip-phases strings

Список фаз, які слід пропустити.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.122 -

Використовуйте цю команду для виклику однієї фази робочого процесу node

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу node

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.123 -

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є

Опис

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є.

kubeadm upgrade node phase control-plane [flags]

Параметри

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.124 -

Оновлює конфігурації kubelet для цього вузла

Опис

Завантажує конфігурацію kubelet з файлу kubelet-config ConfigMap, що зберігається в кластері

kubeadm upgrade node phase kubelet-config [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.125 -

Виконує попередні перевірки на вузлі перед оновленням

Опис

Ця команда виконує попередні перевірки для kubeadm upgrade node.

kubeadm upgrade node phase preflight [flags]

Параметри

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.126 -

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер.

Опис

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер. Ця команда може бути виконана лише на вузлах панелі управління, де існує файл kubeconfig "admin.conf". Щоб пропустити перевірку Інтернету, вкажіть необовʼязковий параметр [version].

kubeadm upgrade plan [version] [flags]

Параметри

--allow-experimental-upgrades

Показати нестабільні версії Kubernetes як альтернативу для оновлення і дозволити оновлення до альфа/бета/кандидатів на випуск версій Kubernetes.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутній у шаблоні. Застосовується лише до форматів виведення golang та jsonpath.

--allow-release-candidate-upgrades

Показати версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволити оновлення до версій кандидатів на випуск Kubernetes.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка plan

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

--show-managed-fields

Якщо true, зберігати managedFields під час виводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.1.127 -

Оновлює кластер Kubernetes до вказаної версії.

Опис

Оновлює кластер Kubernetes до вказаної версії.

kubeadm upgrade apply [version]

Параметри

--allow-experimental-upgrades

Показує нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/версій кандидатів Kubernetes.

--allow-release-candidate-upgrades

Показує версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволяє оновлювати до версій кандидатів на випуск Kubernetes.

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

--feature-gates string

Набір пар ключ=значення, які описують відзначки функцій для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-f, --force

Примусове оновлення, навіть якщо деякі вимоги можуть бути не виконані. Це також передбачає неітерактивний режим.

-h, --help

довідка apply

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, які підтримуються kubectl. За замовчуванням "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який може використовуватися для визначення порядку застосування патчів за алфавітом.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

-y, --yes

Виконати оновлення і не запитувати підтвердження (режим без взаємодії).

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.128 -

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

Опис

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Параметри

--api-server-manifest string     Типово: "/etc/kubernetes/manifests/kube-apiserver.yaml"

Шлях до маніфесту API сервера.

--config string

Шлях до файлу конфігурації kubeadm.

-c, --context-lines int     Типово: 3

Скільки рядків контексту в виведенні diff.

--controller-manager-manifest string     Типово: "/etc/kubernetes/manifests/kube-controller-manager.yaml"

Шлях до маніфесту контролера.

-h, --help

довідка diff

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--scheduler-manifest string     Типово: "/etc/kubernetes/manifests/kube-scheduler.yaml"

Шлях до маніфесту планувальника.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.129 -

Команда upgrade для вузлів в кластері

Опис

Команда upgrade для вузлів в кластері.

Команда "node" виконує наступні фази:

preflight       Виконання попереднії перевірок оновлення вузла
control-plane   Оновлення екземпляру панелі управління, розгорнутий на цьому вузлі, якщо такий є
kubelet-config  Оновлення конфігурацію kubelet для цього вузла

kubeadm upgrade node [flags]

Параметри

--certificate-renewal     Типово: true

Виконати оновлення сертифікатів, використовуваних компонентами, які змінюються під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконати оновлення etcd.

-h, --help

довідка node

--ignore-preflight-errors strings

Список перевірок, помилки в яких будуть відображені як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" - це необовʼязковий рядок, який може використовуватися для визначення порядку застосування патчів за алфавітном.

--skip-phases strings

Список фаз, які слід пропустити.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.130 -

Використовуйте цю команду для виклику однієї фази робочого процесу node

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу node

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.131 -

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є

Опис

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є.

kubeadm upgrade node phase control-plane [flags]

Параметри

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.132 -

Оновлює конфігурації kubelet для цього вузла

Опис

Завантажує конфігурацію kubelet з файлу kubelet-config ConfigMap, що зберігається в кластері

kubeadm upgrade node phase kubelet-config [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.133 -

Виконує попередні перевірки на вузлі перед оновленням

Опис

Ця команда виконує попередні перевірки для kubeadm upgrade node.

kubeadm upgrade node phase preflight [flags]

Параметри

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.134 -

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер.

Опис

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер. Ця команда може бути виконана лише на вузлах панелі управління, де існує файл kubeconfig "admin.conf". Щоб пропустити перевірку Інтернету, вкажіть необовʼязковий параметр [version].

kubeadm upgrade plan [version] [flags]

Параметри

--allow-experimental-upgrades

Показати нестабільні версії Kubernetes як альтернативу для оновлення і дозволити оновлення до альфа/бета/кандидатів на випуск версій Kubernetes.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутній у шаблоні. Застосовується лише до форматів виведення golang та jsonpath.

--allow-release-candidate-upgrades

Показати версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволити оновлення до версій кандидатів на випуск Kubernetes.

--config string

Шлях до файлу конфігурації kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка plan

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

--show-managed-fields

Якщо true, зберігати managedFields під час виводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

10.1.1.135 -

Виводіть версію kubeadm

Опис

Ця команда виводить версію kubeadm.

kubeadm version [flags]

Параметри

-h, --help

довідка version

-o, --output string

Формат виводу; доступні варіанти: 'yaml', 'json' та 'short'

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.2 - kubeadm init

Ця команда ініціалізує вузол панелі управління Kubernetes.

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Опис

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Команда "init" виконує наступні етапи:

preflight                     Виконання перевірок перед запуском
certs                         Генерація сертифікатів
  /ca                           Генерація самопідписаного CA Kubernetes для забезпечення ідентифікації інших компонентів Kubernetes
  /apiserver                    Генерація сертифіката для обслуговування Kubernetes API
  /apiserver-kubelet-client     Генерація сертифіката для зʼєднання API server з kubelet
  /front-proxy-ca               Генерація самопідписаного CA для забезпечення ідентифікації front proxy
  /front-proxy-client           Генерація сертифіката для клієнта front proxy
  /etcd-ca                      Генерація самопідписаного CA для забезпечення ідентифікації etcd
  /etcd-server                  Генерація сертифіката для обслуговування etcd
  /etcd-peer                    Генерація сертифіката для звʼязку між вузлами etcd
  /etcd-healthcheck-client      Генерація сертифіката для перевірки живучості etcd
  /apiserver-etcd-client        Генерація сертифіката, який використовується apiserver для доступу до etcd
  /sa                           Генерація приватного ключа для підписання токенів службових облікових записів разом з його відкритим ключем
kubeconfig                    Генерація всіх kubeconfig файлів, необхідних для створення панелі управління, та kubeconfig файлу адміністратора
  /admin                        Генерація kubeconfig файлу для використання адміністратором та самим kubeadm
  /super-admin                  Генерація kubeconfig файлу для супер-адміністратора
  /kubelet                      Генерація kubeconfig файлу для використання kubelet *лише* для завантаження кластера
  /controller-manager           Генерація kubeconfig файлу для використання контролер-менеджером
  /scheduler                    Генерація kubeconfig файлу для використання планувальником
etcd                          Генерація маніфесту статичного Pod для локального etcd
  /local                        Генерація маніфесту статичного Pod для локального, одновузлового локального etcd
control-plane                 Генерація всіх маніфестів статичних Podʼів, необхідних для створення панелі управління
  /apiserver                    Генерація маніфесту статичного Pod для kube-apiserver
  /controller-manager           Генерація маніфесту статичного Pod для kube-controller-manager
  /scheduler                    Генерація маніфесту статичного Pod для kube-scheduler
kubelet-start                 Запис налаштувань kubelet та (перезавантаження) kubelet
upload-config                 Завантаження конфігурації kubeadm та kubelet у ConfigMap
  /kubeadm                      Завантаження конфігурації кластера kubeadm у ConfigMap
  /kubelet                      Завантаження конфігурації компоненту kubelet у ConfigMap
upload-certs                  Завантаження сертифікатів у kubeadm-certs
mark-control-plane            Маркування вузла як вузла панелі управління
bootstrap-token               Генерація bootstrap токенів, які використовуються для приєднання вузла до кластера
kubelet-finalize             Оновлення налаштувань, що стосуються kubelet, після TLS завантаження
  /enable-client-cert-rotation  Ввімкнути ротацію сертифікатів клієнтів kubelet
  /experimental-cert-rotation   Ввімкнути ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: натомість використовуйте 'enable-client-cert-rotation')
  /experimental-cert-rotation  Увімкнення ротації сертифікатів клієнта kubelet
addon                        Встановлення необхідних надбудов для проходження тестів відповідності
  /coredns                     Встановлення надбудови CoreDNS у Kubernetes кластер
  /kube-proxy                  Встановлення надбудови kube-proxy у Kubernetes кластер
show-join-command            Показати команду приєднання для вузлів керування та робочих вузлів

kubeadm init [прапорці]

Параметри

--apiserver-advertise-address string

IP адреса, за якою API Server буде оголошувати, що він слухає. Якщо не встановлено, буде використаний стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого буде привʼязаний API Server.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях для збереження та зберігання сертифікатів.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane-endpoint string

Вкажіть стабільну IP адресу або DNS імʼя для панелі управління.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка init

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Виберіть конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вкажіть діапазон IP-адрес для мережі Podʼів. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для VIP сервісів.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад "myorg.internal".

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--skip-phases strings

Список етапів, які потрібно оминути

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

--token string

Токен для встановлення двосторонньої довіри між вузлами та вузлами панелі управління. Формат [a-z0-9]{6}.[a-z0-9]{16} — наприклад, abcdef.0123456789abcdef

--token-ttl duration     Типово: 24h0m0s

Час перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

[ЕКСПЕРИМЕНТАЛЬНО] Шлях до 'реальної' кореневої файлової системи хоста.

Процес Init

kubeadm init розгортає вузол панелі управління Kubernetes, виконуючи наступні кроки:

  1. Виконує серію перевірок перед запуском, щоб перевірити стан системи перед внесенням змін. Деякі перевірки лише видають попередження, інші вважаються помилками, і kubeadm припиняє роботу, доки проблема не буде виправлена або користувач не вкаже --ignore-preflight-errors=<list-of-errors>.

  2. Генерує самопідписний CA для налаштування ідентифікаторів для кожного компонента в кластері. Користувач може надати свої власні сертифікат та/або ключ CA, помістивши їх у теку сертифікатів, налаштовану через --cert-dir (типово /etc/kubernetes/pki). Сертифікати APIServer матимуть додаткові записи SAN для будь-яких аргументів --apiserver-cert-extra-sans, з приведенням до нижнього регістру за потреби.

  3. Записує файли kubeconfig у /etc/kubernetes/ для kubelet, controller-manager та scheduler для підключення до API server, кожен зі своїм ідентифікатором. Також створюються додаткові файли kubeconfig, для kubeadm як адміністративної сутності (admin.conf) та для супер адміністратора, що може обходити RBAC (super-admin.conf).

  4. Генерує манифести статичних Pod для API server, controller-manager та scheduler. Якщо зовнішній etcd не надано, створюється додатковий маніфест статичного Pod для etcd.

    Статичні манифести Pod записуються у /etc/kubernetes/manifests; kubelet спостерігає за цією текою для створення Podʼів при запуску.

    Як тільки Podʼи панелі управління будуть запущені та працюватимуть, процес kubeadm init може продовжитися.

  5. Додає мітки та taint на вузол панелі управління, щоб жодні додаткові робочі навантаження не запускалися там.

  6. Генерує токен, який додаткові вузли можуть використовувати для реєстрації у майбутньому на вузлі панелі управління. За бажанням, користувач може надати токен через --token, як описано в документації kubeadm token.

  7. Виконує всі необхідні налаштування для дозволу приєднання вузлів за допомогою механізмів Bootstrap Tokens та TLS Bootstrap:

    • Записує ConfigMap для надання всієї необхідної інформації для приєднання, та налаштовує відповідні правила доступу RBAC.

    • Дозволяє Bootstrap Tokens доступ до API підписання CSR.

    • Налаштовує автоматичне схвалення нових запитів CSR.

    Див. kubeadm join для додаткової інформації.

  8. Встановлює DNS сервер (CoreDNS) та компоненти надбудови kube-proxy через API server. У версії Kubernetes 1.11 і пізніших CoreDNS є типовим сервером DNS. Зверніть увагу, що хоча DNS сервер розгорнутий, він не буде запланований до встановлення CNI.

Використання фаз ініціалізації з kubeadm

Kubeadm дозволяє створювати вузол панелі управління поетапно, використовуючи команду kubeadm init phase.

Щоб переглянути впорядкований список фаз та підфаз, можна викликати kubeadm init --help. Список буде розташований на початку екрана довідки, і кожна фаза матиме опис поруч із нею. Зверніть увагу, що при виклику kubeadm init всі фази та підфази будуть виконані в точно такому порядку.

Деякі фази мають унікальні прапорці, тому, якщо ви хочете переглянути список доступних опцій, додайте --help, наприклад:

sudo kubeadm init phase control-plane controller-manager --help

Ви також можете використовувати --help, щоб побачити список підфаз для певної батьківської фази:

sudo kubeadm init phase control-plane --help

kubeadm init також має прапорець --skip-phases, який можна використовувати для пропуску певних фаз. Прапорець приймає список назв фаз, які можна взяти з вищезгаданого впорядкованого списку.

Приклад:

sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# тепер ви можете змінити файли маніфестів панелі управління та etcd
sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml

Цей приклад записує файли маніфесту для панелі управління та etcd у /etc/kubernetes/manifests на основі конфігурації в configfile.yaml. Це дозволяє вам змінювати файли, а потім пропускати ці фази, використовуючи --skip-phases. Викликом останньої команди ви створите вузол панелі управління з власними файлами маніфестів.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [beta]

Альтернативно, ви можете використовувати поле skipPhases у InitConfiguration.

Використання kubeadm init з конфігураційним файлом

Можна налаштувати kubeadm init за допомогою конфігураційного файлу замість прапорців командного рядка, а деякі більш розширені функції можуть бути доступні лише як опції конфігураційного файлу. Цей файл передається за допомогою прапорця --config, і він повинен містити структуру ClusterConfiguration і, за бажанням, інші структури, розділені ---\n. Змішування --config з іншими прапорцями може не бути дозволеним у деяких випадках.

Ви можете вивести стандартну конфігурацію за допомогою команди kubeadm config print.

Якщо ваша конфігурація не використовує останню версію, рекомендується перейти на нову версію за допомогою команди kubeadm config migrate.

Для отримання додаткової інформації про поля та використання конфігурації ви можете перейти на нашу сторінку API-довідки.

Використання kubeadm init з функціональними можливостями

Kubeadm підтримує набір функціональних можливостей (feature gate), які унікальні для kubeadm і можуть бути застосовані лише під час створення кластера за допомогою kubeadm init. Ці функціональні можливості можуть контролювати поведінку кластера. Функціональні можливості видаляються після того, як функція переходить до стадії GA (General Availability).

Щоб передати функціональні можливості, можна використовувати прапорець --feature-gates для kubeadm init, або можна додати елементи до поля featureGates, коли передаєте конфігураційний файл за допомогою --config.

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

Список функціональних можливостей:

Прапорці функцій kubeadm
ФункціяСтандартноAlphaBetaGA
ControlPlaneKubeletLocalModefalse1.31--
EtcdLearnerModetrue1.271.29-
PublicKeysECDSAfalse1.19--
WaitForAllControlPlaneComponentsfalse1.30--

Опис функціональних можливостей:

ControlPlaneKubeletLocalMode
З цією функціональною можливістю, при приєднанні нового вузла панелі управління kubeadm налаштовуватиме kubelet для підключення до локального kube-apiserver. Це забезпечує дотримання політики щодо версійних розбіжностей під час постійних оновлень (rolling upgrades).
EtcdLearnerMode
З цією функціональною можливістю, коли приєднується новий вузол панелі управління, буде створений новий учасник etcd як 'учень' і його буде підвищено до учасника з правом голосу лише після повного узгодження даних etcd.
PublicKeysECDSA
Може бути використаний для створення кластера, що використовує сертифікати ECDSA замість стандартного алгоритму RSA. Також підтримується оновлення поточних сертифікатів ECDSA за допомогою kubeadm certs renew, але ви не можете перемикатися між алгоритмами RSA та ECDSA на ходу або під час оновлення. У Kubernetes 1.31 є помилка, коли ключі у згенерованих kubeconfig файлах встановлюються для використання RSA, попри увімкнену функціональну можливість. У версіях Kubernetes до v1.31 була помилка, коли ключі у згенерованих файлах kubeconfig встановлювалися з використанням RSA, навіть якщо ви увімкнули функціональну можливість PublicKeysECDSA.
WaitForAllControlPlaneComponents
З цією функціональною можливістю kubeadm буде чекати, поки всі компоненти панелі управління (kube-apiserver, kube-controller-manager, kube-scheduler) на вузлі панелі управління не повідомлять статус 200 на їхніх точках доступу /healthz. Ці перевірки виконуються на https://127.0.0.1:PORT/healthz, де PORT береться з --secure-port компонента. Якщо ви вкажете власні значення --secure-port у конфігурації kubeadm, вони будуть використані. Без ввімкненої функціональної можливості kubeadm буде чекати лише, поки kube-apiserver на вузлі панелі управління стане готовим. Процес очікування починається відразу після того, як kubelet на хості запускається за допомогою kubeadm. Рекомендується ввімкнути цю функціональну можливість, якщо ви хочете спостерігати готовність усіх компонентів панелі управління під час виконання команди kubeadm init або kubeadm join.

Список застарілих функціональних можливостей:

Застарілі функціональні можливості kubeadm
ФункціяСтандартноAlphaBetaGADeprecated
RootlessControlPlanefalse1.22--1.31

Опис застарілих функціональних можливостей:

RootlessControlPlane
Встановлення цього прапорця налаштовує розгорнуті компоненти панелі управління kubeadm у статичних Podʼах для kube-apiserver, kube-controller-manager, kube-scheduler та etcd для запуску від імені користувачів без прав суперкористувача. Якщо прапорець не встановлений, ці компоненти запускаються з правами root. Ви можете змінити значення цього прапорця функції перед оновленням до нової версії Kubernetes.

Список видалених функціональних можливостей:

Видалені функціональні можливості kubeadm
ЕлементAlphaBetaGAВидалено
IPv6DualStack1.161.211.231.24
UnversionedKubeletConfigMap1.221.231.251.26
UpgradeAddonsBeforeControlPlane1.28--1.31

Опис видалених функціональних можливостей:

IPv6DualStack
Цей прапорець допомагає налаштувати компоненти подвійного стека, коли функція знаходиться в процесі розробки. Для отримання більш детальної інформації про підтримку подвійного стека в Kubernetes дивіться Підтримка подвійного стека за допомогою kubeadm.
UnversionedKubeletConfigMap
Цей прапорець контролює назву ConfigMap, в якому kubeadm зберігає дані конфігурації kubelet. Якщо цей прапорець не вказаний або встановлений у true, ConfigMap називається kubelet-config. Якщо ви встановите цей прапорець у false, назва ConfigMap включатиме основну та додаткову версію для Kubernetes (наприклад: kubelet-config-1.31). Kubeadm забезпечує, що правила RBAC для читання та запису цього ConfigMap є відповідними до значення, яке ви встановили. Коли kubeadm записує цей ConfigMap (під час kubeadm init або kubeadm upgrade apply), kubeadm дотримується значення UnversionedKubeletConfigMap. При читанні цього ConfigMap (під час kubeadm join, kubeadm reset, kubeadm upgrade ...), kubeadm спочатку намагається використовувати назву ConfigMap без версії; якщо це не вдається, kubeadm переходить до використання застарілої (версійної) назви для цього ConfigMap.
UpgradeAddonsBeforeControlPlane
Цю функціональну можливість було видалено. Вона була визнана у версії v1.28 як застаріла функція і потім видалена у версії v1.31. Для документації щодо старіших версій, будь ласка, перейдіть на відповідну версію вебсайту.

Додавання параметрів kube-proxy

Для отримання інформації про параметри kube-proxy у конфігурації kubeadm дивіться:

Для отримання інформації про увімкнення режиму IPVS за допомогою kubeadm дивіться:

Передача власних прапорців користувача до компонентів панелі управління

Для отримання інформації про передачу прапорців до компонентів панелі управління дивіться:

Використання kubeadm без підключення до Інтернету

Для запуску kubeadm без підключення до Інтернету необхідно попередньо завантажити необхідні образи панелі управління.

Ви можете отримати перелік та завантажити образи за допомогою команди kubeadm config images:

kubeadm config images list
kubeadm config images pull

Ви можете використати --config з вищенаведеними командами з файлом конфігурації kubeadm для контролю полів kubernetesVersion та imageRepository.

Усі стандартні образи registry.k8s.io, необхідні kubeadm, підтримують кілька архітектур.

Використання власних образів

Стандартно, kubeadm завантажує образи з registry.k8s.io. Якщо запитана версія Kubernetes є CI міткою (наприклад, ci/latest), використовується gcr.io/k8s-staging-ci-images.

Ви можете змінити цю поведінку, використовуючи kubeadm з файлом конфігурації. Дозволені налаштування:

  • Вказати kubernetesVersion, що впливає на версію образів.
  • Вказати альтернативний imageRepository, який буде використовуватися замість registry.k8s.io.
  • Вказати конкретний imageRepository та imageTag для etcd або CoreDNS.

Шляхи образів між стандартним registry.k8s.io та власним репозиторієм, зазначеним за допомогою imageRepository, можуть відрізнятися з причин зворотної сумісності. Наприклад, один образ може мати підшлях у registry.k8s.io/subpath/image, але стандартно бути my.customrepository.io/image при використанні власного репозиторію користувача.

Щоб переконатися, що ви завантажуєте образи до вашого власного репозиторію у шляхи, які може використовувати kubeadm, вам потрібно:

  • Завантажити образи зі стандартних шляхів з registry.k8s.io за допомогою kubeadm config images {list|pull}.
  • Завантажити образи до шляхів з kubeadm config images list --config=config.yaml, де config.yaml містить власне значення imageRepository та/або imageTag для etcd та CoreDNS.
  • Передати той самий config.yaml до kubeadm init.

Власні образи sandbox (pause)

Щоб встановити власний образ для цих контейнерів, потрібно налаштувати ваше середовище виконання контейнерів для використання цього образу. Зверніться до документації вашого середовища виконання контейнерів, щоб дізнатися, як змінити це налаштування; для певних середовищ виконання контейнерів ви також можете знайти поради у розділі Середовища виконання контейнерів.

Завантаження сертифікатів панелі управління до кластера

Додавши прапорець --upload-certs до kubeadm init, ви можете тимчасово завантажити сертифікати панелі управління до Secret у кластері. Зверніть увагу, що дія цього Secret автоматично спливає через 2 години. Сертифікати шифруються за допомогою 32-байтного ключа, який можна задати за допомогою --certificate-key. Той самий ключ можна використовувати для завантаження сертифікатів при приєднанні додаткових вузлів панелі управління, передавши --control-plane та --certificate-key до kubeadm join.

Для повторного завантаження сертифікатів після закінчення їхнього терміну дії можна використовувати таку команду фази:

kubeadm init phase upload-certs --upload-certs --config=SOME_YAML_FILE

Якщо попередньо визначений ключ сертифіката не передано до kubeadm init і kubeadm init phase upload-certs, новий ключ буде згенеровано автоматично.

Для генерації нового ключа за запитом можна використовувати наступну команду:

kubeadm certs certificate-key

Управління сертифікатами за допомогою kubeadm

Для отримання докладної інформації про управління сертифікатами за допомогою kubeadm перегляньте Управління сертифікатами за допомогою kubeadm. Документ містить інформацію про використання зовнішнього центру сертификації (CA), власні сертифікати та оновлення сертифікатів.

Керування drop-in файлом для kubelet у kubeadm

Пакет kubeadm постачається з файлом конфігурації для запуску kubelet через systemd. Зауважте, що CLI kubeadm ніколи не торкається цього drop-in файлу. Цей drop-in файл є частиною пакунка kubeadm DEB/RPM.

Для отримання додаткової інформації дивіться Керування drop-in файлом для systemd в kubeadm.

Використання kubeadm з CRI runtimes

Стандартно kubeadm намагається зʼясувати яке у вас середовище виконання контейнерів. Для детальнішої інформації щодо цього, дивіться посібник з установки CRI для kubeadm.

Налаштування імені вузла

Типово kubeadm присвоює імʼя вузла на основі мережевої адреси машини. Ви можете змінити це налаштування за допомогою прапорця --node-name. Цей прапорець передає відповідне значення --hostname-override до kubelet.

Зверніть увагу, що заміна імені хосту може вплинути на роботу хмарних провайдерів, деталі за посиланням.

Автоматизація kubeadm

Замість копіювання токену, який ви отримали з kubeadm init на кожний вузол, як у базовому посібнику з kubeadm, ви можете паралельно розподіляти токен для полегшення автоматизації. Щоб реалізувати цю автоматизацію, вам потрібно знати IP-адресу, яку матиме вузол панелі управління після запуску, або використовувати DNS-імʼя чи адресу балансувальника навантаження.

  1. Згенеруйте токен. Цей токен повинен мати форму <6 символьний рядок>.<16 символьний рядок>. Формально він повинен відповідати регулярному виразу: [a-z0-9]{6}\.[a-z0-9]{16}.

    kubeadm може згенерувати токен для вас:

    kubeadm token generate

  2. Запустіть одночасно вузол панелі управління та робочі вузли з цим токеном. Під час їх запуску вони мають знайти один одного та сформувати кластер. Той самий аргумент --token можна використовувати як у kubeadm init, так і у kubeadm join.

  3. Аналогічно можна поступити з --certificate-key при приєднанні додаткових вузлів панелі управління. Ключ можна згенерувати за допомогою:

    kubeadm certs certificate-key

Як тільки кластер буде запущений, ви зможете використовувати файл /etc/kubernetes/admin.conf з вузла панелі управління для спілкування з кластером з адміністративними правами чи Генерація файлів kubeconfig для додаткових користувачів.

Зауважте, що цей спосіб ініціалізації має деякі спрощені гарантії безпеки, оскільки не дозволяє перевіряти кореневий хеш сертифіката з --discovery-token-ca-cert-hash (оскільки він не генерується при проведенні вузлів). Докладні відомості дивіться в kubeadm join.

Що далі

  • kubeadm init phase для отримання більш детальної інформації про фази kubeadm init.
  • kubeadm join для налаштування робочого вузла Kubernetes та його приєднання до кластера.
  • kubeadm upgrade для оновлення кластера Kubernetes до новішої версії.
  • kubeadm reset для скидання будь-яких змін, внесених до цього хосту за допомогою kubeadm init або kubeadm join.

10.1.3 - kubeadm join

Ця команда ініціалізує новий вузол Kubernetes і приєднує його до наявного кластера.

Запустіть цю команду на будь-якому компʼютері, який ви хочете приєднати до існуючого кластера

Опис

Під час приєднання до ініціалізованого кластера за допомогою kubeadm, необхідно встановити двосторонню довіру. Цей процес розділяється на два етапи: виявлення (щоб Node довіряв Панелі Управління Kubernetes) та TLS завантаження (щоб Панель управління Kubernetes довіряла Node).

Існує дві основні схеми для виявлення. Перша — використовувати спільний токен разом з IP-адресою сервера API. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go ("exec"), "tokenFile" та "authProvider". Цей файл може бути локальним або завантаженим через URL HTTPS. Форми приєднання є:

kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
kubeadm join --discovery-file path/to/file.conf
kubeadm join --discovery-file https://url/file.conf

Можна використовувати лише одну форму. Якщо інформація для виявлення завантажується з URL, обовʼязково використовувати HTTPS. У цьому випадку для перевірки зʼєднання використовується встановлений на хості набір сертифікатів CA.

Якщо ви використовуєте спільний токен для виявлення, слід також передати прапорець --discovery-token-ca-cert-hash для перевірки публічного ключа кореневого центру сертифікації (CA), який представлений Панеллю Управління Kubernetes. Значення цього прапорця визначається як "<тип-хешу>:<шестнадцяткове-кодоване-значення>", де підтримуваний тип хешу — "sha256". Хеш обчислюється по байтах обʼєкта Subject Public Key Info (SPKI) (як в RFC7469). Це значення доступне у вихідних даних "kubeadm init" або може бути обчислене за допомогою стандартних інструментів. Прапорець --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити використання більше одного публічного ключа.

Якщо ви не можете знати хеш публічного ключа CA заздалегідь, ви можете передати прапорець --discovery-token-unsafe-skip-ca-verification для вимкнення цієї перевірки. Це послаблює модель безпеки kubeadm, оскільки інші вузли можуть потенційно видавати себе за Панель Управління Kubernetes.

Механізм TLS завантаження також керується через спільний токен. Це використовується для тимчасової автентифікації в Панелі Управління Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів. Типово, kubeadm налаштує Панель Управління Kubernetes автоматично схвалювати ці запити на підписання. Цей токен передається за допомогою прапорця --tls-bootstrap-token abcdef.1234567890abcdef.

Часто той самий токен використовується для обох частин. У цьому випадку прапорець --token можна використовувати замість окремого зазначення кожного токена.

Команда "join [api-server-endpoint]" виконує наступні фази:

preflight              Виконати передстартові перевірки для приєднання
control-plane-prepare  Підготувати машину для обслуговування панелі управління
  /download-certs        Завантажити сертифікати, спільні для вузлів панелі управління, з Secret kubeadm-certs
  /certs                 Створити сертифікати для нових компонентів панелі управління
  /kubeconfig            Створити kubeconfig для нових компонентів панелі управління
  /control-plane         Створити маніфести для нових компонентів панелі управління
kubelet-start          Записати налаштування kubelet, сертифікати та (перезавантажити) kubelet
control-plane-join     Приєднати машину як екземпляр панелі управління
  /etcd                  Додати нового локального члена etcd
  /mark-control-plane    Позначити вузол як панель управління
wait-control-plane     Експериментально: чекати запуску панелі управління

kubeadm join [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

Якщо вузол має хостити новий екземпляр панелі управління, IP-адреса, яку сервер API буде оголошувати як ту, на якій він слухає. Якщо не встановлено, буде використовуватися стандартний інтерфейс.

--apiserver-bind-port int32     Стандартно: 6443

Якщо вузол має хостити новий екземпляр панелі управління, порт, до якого буде привʼязаний сервер API.

--certificate-key string

Використовуйте цей ключ для розшифрування секретів сертифікатів, завантажених за допомогою init. Ключ сертифіката — це шестнадцятковий закодований рядок, який є AES ключем розміром 32 байти.

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка join

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вказати імʼя вузла.

--patches string

Шлях до теки, що містить файли з назвами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json" і відповідають форматам патчів, підтримуваних kubectl. Типовий "patchtype" — "strategic". "extension" має бути або "json", або "yaml". "suffix" — це необовʼязковий рядок, який можна використовувати для визначення, які патчі застосовуються першими в алфавітно-числовому порядку.

--skip-phases strings

Список фаз, які потрібно пропустити

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Процес приєднання

kubeadm join ініціалізує робочий вузол Kubernetes або вузол панелі управління та додає його до кластера. Ця дія складається з наступних кроків для робочих вузлів:

  1. kubeadm завантажує необхідну інформацію про кластер з сервера API. Стандартно використовується токен початкового завантаження та хеш ключа CA для перевірки достовірності цих даних. Кореневий CA також може бути виявлений безпосередньо через файл або URL.

  2. Як тільки інформація про кластер відома, kubelet може почати процес TLS початкового завантаження.

    Завантажувач TLS використовує спільний токен для тимчасової автентифікації з сервером API Kubernetes для надсилання запиту на підписання сертифіката (CSR); стандартно панель управління підписує цей CSR-запит автоматично.

  3. Нарешті, kubeadm налаштовує локальний kubelet для підключення до сервера API з остаточною ідентичністю, призначеною вузлу.

Для вузлів панелі управління виконуються додаткові кроки:

  1. Завантаження сертифікатів, спільних для вузлів панелі управління з кластера (якщо це явно запитано користувачем).

  2. Генерація маніфестів компонентів панелі управління, сертифікатів та kubeconfig.

  3. Додавання нового локального члена etcd.

Використання фаз приєднання з kubeadm

Kubeadm дозволяє приєднати вузол до кластера поетапно, використовуючи kubeadm join phase.

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

Деякі фази мають унікальні прапорці, тому якщо ви хочете переглянути список доступних опцій, додайте --help, наприклад:

kubeadm join phase kubelet-start --help

Подібно до команди kubeadm init phase, команда kubeadm join phase дозволяє пропустити список фаз, використовуючи прапорець --skip-phases.

Наприклад:

sudo kubeadm join --skip-phases=preflight --config=config.yaml
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [beta]

Крім того, ви можете використовувати поле skipPhases в JoinConfiguration.

Визначення, якому CA кластера довіряти

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

Виявлення на основі токена з закріпленням CA

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

Хеш ключа CA має формат sha256:<hex_encoded_hash>. Стандартне значення хешу друкується в кінці команди kubeadm init або у виведенні команди kubeadm token create --print-join-command. Воно знаходиться в стандартному форматі (див. RFC7469) і може бути також обчислено сторонніми інструментами або системами забезпечення. Наприклад, використовуючи OpenSSL CLI:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

Приклади команд kubeadm join:

Для робочих вузлів:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443

Для вузлів панелі управління:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443

Ви також можете викликати join для вузла панелі управління з прапорцем --certificate-key для копіювання сертифікатів на цей вузол, якщо команда kubeadm init була викликана з прапорцем --upload-certs.

Переваги:

  • Дозволяє вузлам початкового завантаження безпечно виявляти корінь довіри для вузла панелі управління, навіть якщо інші робочі вузли або мережа скомпрометовані.

  • Зручно виконувати вручну, оскільки вся необхідна інформація вміщується в одну команду kubeadm join.

Недоліки:

  • Хеш CA зазвичай не відомий до тих пір, поки вузол панелі управління не буде впроваджений, що може ускладнити створення автоматизованих інструментів впровадження, які використовують kubeadm. Генеруючи свій CA заздалегідь, ви можете обійти це обмеження.

Виявлення на основі токена без закріплення CA

Цей режим покладається лише на симетричний токен для підпису (HMAC-SHA256) інформації про виявлення, що встановлює корінь довіри для панелі управління. Щоб використовувати цей режим, вузли, що приєднуються, повинні пропустити перевірку хешу публічного ключа CA, використовуючи --discovery-token-unsafe-skip-ca-verification. Якщо можливо, слід розглянути використання одного з інших режимів.

Приклад команди kubeadm join:

kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443

Переваги:

  • Все ще захищає від багатьох атак на рівні мережі.

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

Недоліки:

  • Якщо зловмисник зможе вкрасти токен початкового завантаження через якусь уразливість, вони можуть використовувати цей токен (разом з доступом на рівні мережі) для видавання себе за вузол панелі управління для інших вузлів початкового завантаження. Це може бути або не бути відповідним компромісом у вашому середовищі.

Виявлення на основі файлів або HTTPS

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

У разі, якщо файл для виявлення не містить облікових даних, буде використовуватися токен TLS.

Приклади команд kubeadm join:

  • kubeadm join --discovery-file path/to/file.conf (локальний файл)

  • kubeadm join --discovery-file https://url/file.conf (віддалений HTTPS URL)

Переваги:

  • Дозволяє вузлам початкового завантаження безпечно виявляти корінь довіри для вузла панелі управління, навіть якщо мережа або інші робочі вузли скомпрометовані.

Недоліки:

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

Використання власних облікових даних kubelet з kubeadm join

Щоб дозволити kubeadm join використовувати заздалегідь визначені облікові дані kubelet і пропустити клієнтське початкове завантаження TLS та затвердження CSR для нового вузла:

  1. На робочому вузлі панелі управління в кластері, який має /etc/kubernetes/pki/ca.key, виконайте kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf. $NODE має бути встановлено на імʼя нового вузла.
  2. Відредагуйте отриманий kubelet.conf вручну, щоб налаштувати імʼя кластера та точку доступу сервера, або запустіть kubeadm kubeconfig user --config (приймає InitConfiguration).

Якщо у вашому кластері немає файлу ca.key, вам потрібно підписати вбудовані сертифікати в kubelet.conf зовнішнім чином. Для додаткової інформації дивіться Сертифікати PKI та вимоги та Управління сертифікатами за допомогою kubeadm.

  1. Скопіюйте отриманий kubelet.conf до /etc/kubernetes/kubelet.conf на новому вузлі.
  2. Виконайте kubeadm join з прапорцем --ignore-preflight-errors=FileAvailable--etc-kubernetes-kubelet.conf на новому вузлі.

Ще більший захист вашого встановлення

Типові налаштування kubeadm можуть не підходити для всіх. Цей розділ показує, як посилити захист kubeadm коштом зручності користування.

Вимкнення автоматичного затвердження клієнтських сертифікатів вузла

За замовчуванням увімкнено автоматичне затвердження запитів на клієнтські сертифікати CSR, коли використовується токен Bootstrap під час аутентифікації. Якщо ви не бажаєте, щоб кластер автоматично затверджував клієнтські сертифікати kubelet, ви можете вимкнути цю функцію виконавши наступну команду:

kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap

Після цього команда kubeadm join буде блокуватися до тих пір, поки адміністратор не затвердить CSR вручну:

  1. За допомогою kubectl get csr ви можете переглянути, що оригінальний CSR знаходиться в стані Pending.

    kubectl get csr

    Результат буде подібним до такого:

    NAME                                                   AGE       REQUESTOR                 CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   18s       system:bootstrap:878f07   Pending

  2. kubectl certificate approve дозволяє адміністратору затвердити CSR. Ця дія наказує контролеру підпису сертифікатів видати сертифікат запитувачеві з властивостями, зазначеними у CSR.

    kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ

    Результат буде подібний до такого:

    certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved

  3. Це змінить ресурс CSR на стан Active.

    kubectl get csr

    Результат буде подібний до такого:

    NAME                                                   AGE       REQUESTOR                 CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued

Це змушує процес kubeadm join працювати тільки у випадку, коли була виконана команда kubectl certificate approve.

Вимкнення загального доступу до ConfigMap cluster-info

Для того, щоб досягти потоку приєднання, використовуючи токен як єдину частину інформації про перевірку, необхідно викласти у відкритий доступ ConfigMap з деякими даними, необхідними для перевірки ідентичності вузла панелі управління, стандартно публікується у відкритому доступі. Хоча в цьому ConfigMap немає приватних даних, деякі користувачі можуть бажати вимкнути цю можливість. Це дія призведе до відключення можливості використання прапорця --discovery-token в потоці kubeadm join. Ось кроки для вимкнення цієї функції:

  • Отримайте файл cluster-info з API сервера:

    kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml

    Вивід буде подібний до такого:

    apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <ca-cert>
    server: https://<ip>:<port>
  name: ""
contexts: []
current-context: ""
preferences: {}
users: []

  • Використовуйте файл cluster-info.yaml як аргумент для kubeadm join --discovery-file.

  • Вимкніть загальний доступ до ConfigMap cluster-info:

    kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo

Ці команди слід виконати після kubeadm init, але перед kubeadm join.

Використання kubeadm join з конфігураційним файлом

Можливо сконфігурувати kubeadm join, використовуючи конфігураційний файл замість прапорців командного рядка, і деякі більш розширені функції можуть бути доступні лише як опції конфігураційного файлу. Цей файл передається за допомогою прапорця --config і повинен містити структуру JoinConfiguration. У деяких випадках змішування --config з іншими прапорцями може бути недозволеним.

Стандартна конфігурація може бути виведена за допомогою команди kubeadm config print.

Якщо ваша конфігурація не використовує останню версію, рекомендується перейти на неї за допомогою команди kubeadm config migrate.

Для отримання додаткової інформації щодо полів та використання конфігурації ви можете перейти до нашого довідника API.

Що далі

  • kubeadm init для ініціалізації вузла панелі управління Kubernetes.
  • kubeadm token для управління токенами для kubeadm join.
  • kubeadm reset для скасування будь-яких змін, внесених до цього хосту за допомогою kubeadm init або kubeadm join.

10.1.4 - kubeadm upgrade

kubeadm upgrade — це зручна команда, яка обгортає складну логіку оновлення однією командою, з підтримкою як планування оновлення, так і його фактичного виконання.

Інструкція kubeadm upgrade

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

Ви можете використовувати kubeadm upgrade diff для перегляду змін, які будуть застосовані до маніфестів статичних Pod.

У Kubernetes версії v1.15.0 і пізніше, kubeadm upgrade apply та kubeadm upgrade node також автоматично оновлять сертифікати, керовані kubeadm на цьому вузлі, включаючи ті, що зберігаються у файлах kubeconfig. Щоб відмовитися від цього, можна передати прапорець --certificate-renewal=false. Для отримання додаткової інформації про оновлення сертифікатів дивіться документацію з управління сертифікатами.

kubeadm upgrade plan

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер.

Опис

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер. Ця команда може бути виконана лише на вузлах панелі управління, де існує файл kubeconfig "admin.conf". Щоб пропустити перевірку Інтернету, вкажіть необовʼязковий параметр [version].

kubeadm upgrade plan [version] [flags]

Параметри

--allow-experimental-upgrades

Показати нестабільні версії Kubernetes як альтернативу для оновлення і дозволити оновлення до альфа/бета/кандидатів на випуск версій Kubernetes.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутній у шаблоні. Застосовується лише до форматів виведення golang та jsonpath.

--allow-release-candidate-upgrades

Показати версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволити оновлення до версій кандидатів на випуск Kubernetes.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка plan

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

--show-managed-fields

Якщо true, зберігати managedFields під час виводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm upgrade apply

Оновлює кластер Kubernetes до вказаної версії.

Опис

Оновлює кластер Kubernetes до вказаної версії.

kubeadm upgrade apply [version]

Параметри

--allow-experimental-upgrades

Показує нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/версій кандидатів Kubernetes.

--allow-release-candidate-upgrades

Показує версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволяє оновлювати до версій кандидатів на випуск Kubernetes.

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-f, --force

Примусове оновлення, навіть якщо деякі вимоги можуть бути не виконані. Це також передбачає неітерактивний режим.

-h, --help

довідка apply

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, які підтримуються kubectl. За замовчуванням "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який може використовуватися для визначення порядку застосування патчів за алфавітом.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

-y, --yes

Виконати оновлення і не запитувати підтвердження (режим без взаємодії).

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm upgrade diff

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

Опис

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

-c, --context-lines int     Типово: 3

Скільки рядків контексту в виведенні diff.

-h, --help

довідка diff

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm upgrade node

Команда upgrade для вузлів в кластері

Опис

Команда upgrade для вузлів в кластері.

Команда "node" виконує наступні фази:

preflight       Виконання попереднії перевірок оновлення вузла
control-plane   Оновлення екземпляру панелі управління, розгорнутий на цьому вузлі, якщо такий є
kubelet-config  Оновлення конфігурацію kubelet для цього вузла

kubeadm upgrade node [flags]

Параметри

--certificate-renewal     Типово: true

Виконати оновлення сертифікатів, використовуваних компонентами, які змінюються під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконати оновлення etcd.

-h, --help

довідка node

--ignore-preflight-errors strings

Список перевірок, помилки в яких будуть відображені як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" - це необовʼязковий рядок, який може використовуватися для визначення порядку застосування патчів за алфавітном.

--skip-phases strings

Список фаз, які слід пропустити.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm config якщо ви ініціалізували свій кластер за допомогою kubeadm версії 1.7.x або нижче, щоб налаштувати ваш кластер для оновлення за допомогою kubeadm upgrade.

10.1.5 - kubeadm config

Під час виконання kubeadm init, kubeadm надсилає обʼєкт ClusterConfiguration у ваш кластер у ConfigMap з назвою kubeadm-config у просторі імен kube-system. Ця конфігурація зчитується під час виконання kubeadm join, kubeadm reset та kubeadm upgrade.

Ви можете використовувати kubeadm config print для виведення стандартної статичної конфігурації, яку використовує kubeadm для kubeadm init і kubeadm join.

Для отримання додаткової інформації про init та join перейдіть до Використання kubeadm init з конфігураційним файлом або Використання kubeadm join з конфігураційним файлом.

Для отримання додаткової інформації про використання API конфігурації kubeadm перейдіть до Налаштування компонентів за допомогою API kubeadm.

Ви можете використовувати kubeadm config migrate для перетворення старих конфігураційних файлів, що містять застарілу версію API, на новішу підтримувану версію API.

kubeadm config validate можна використовувати для перевірки конфігураційного файлу.

kubeadm config images list та kubeadm config images pull можна використовувати для виведення списку та завантаження зображень, необхідних kubeadm.

kubeadm config print

Вивід конфігурації

Опис

Ця команда виводить конфігурацію вказаних субкоманд. Докладніше: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Параметри

-h, --help

довідка print

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config print init-defaults

Вивід стандартної конфігурації ініціалізації, яка може використовуватись у kubeadm init.

Опис

Ця команда виводить обʼєкти, такі як стандартну конфігурацію ініціалізації, які можуть бути використані у kubeadm init.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print init-defaults [flags]

Параметри

--component-configs strings

Список обʼєктів API конфігурації компонентів через кому для виводу типових значень. Доступні значення: [KubeProxyConfiguration KubeletConfiguration]. Якщо цей прапорець не встановлено, конфігурації компонентів не буде надруковано.

-h, --help

довідка init-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config print join-defaults

Вивід стандартної конфігурації для команди kubeadm join.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди join, яка використовується для 'kubeadm join'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print join-defaults [flags]

Параметри

-h, --help

довідка join-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config migrate

Зчитує стару версію типів конфігураційного API kubeadm з файлу і виводе аналогічний обʼєкт конфігурації для нової версії

Опис

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

  • kubeadm.k8s.io/v1beta4

Крім того, kubeadm може записувати конфігурацію лише версії "kubeadm.k8s.io/v1beta4", але читати обидві версії. Отже, незалежно від того, яку версію ви передаєте параметру --old-config, API обʼєкт буде прочитано, десеріалізовано, встановлено стандартні значення, конвертовано, валідовано та повторно серіалізовано під час запису у stdout або --new-config, якщо вказано.

Іншими словами, вихід цієї команди є тим, що kubeadm фактично читав би внутрішньо, якщо ви надіслали б цей файл команді "kubeadm init".

kubeadm config migrate [flags]

Параметри

--allow-experimental-api

Дозволити міграцію на експериментальні, невипущені API

-h, --help

довідка migrate

--new-config string

Шлях до отриманого еквівалентного конфігураційного файлу kubeadm з використанням нової версії API. Необовʼязково, якщо не вказано, вивід буде надіслано у STDOUT.

--old-config string

Шлях до конфігураційного файлу kubeadm, який використовує стару версію API і який має бути конвертований. Цей прапорець є обовʼязковим.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config validate

Зчитує файл, що містить конфігураційний API kubeadm, і повідомляє про будь-які проблеми під час валідації

Опис

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

У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta4
kubeadm config validate [flags]

Параметри

--allow-experimental-api

Дозволяє валідацію експериментальних, невипущених API.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка validate

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config images list

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів

Опис

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів.

kubeadm config images list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли у шаблоні відсутнє поле або ключ мапи. Застосовується тільки до форматів виводу golang і jsonpath.

--config string

Шлях до файлу конфігурації kubeadm.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка list

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, зберігати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config images pull

Витягує образи які використовує kubeadm з реєстру

Опис

Витягує образи які використовує kubeadm з реєстру

kubeadm config images pull [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

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

--feature-gates string

Набір пар ключ=значення, що описують ворота функцій для різних можливостей. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка pull

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm upgrade для оновлення кластера Kubernetes до новішої версії

10.1.6 - kubeadm reset

Виконує максимально можливий відкат змін, зроблених командами kubeadm init або kubeadm join.

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Опис

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Команда "reset" виконує наступні фази:

preflight           Запуск попередніх перевірок
remove-etcd-member  Вилучення локального учасника etcd.
cleanup-node        Запуск очищення вузла.

kubeadm reset [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях до теки, де зберігаються сертифікати. Якщо вказано, очистити цю теку.

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

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

--dry-run

Не вносити жодних змін; лише вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

довідка reset

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-phases strings

Список фаз, які слід пропустити

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Робочий процес

kubeadm reset відповідає за очищення файлової системи вузла від файлів, створених за допомогою команд kubeadm init або kubeadm join. Для вузлів панелі управління reset також видаляє локального учасника стека etcd цього вузла з кластера etcd.

kubeadm reset phase можна використовувати для виконання окремих фаз наведеного вище робочого процесу. Щоб пропустити список фаз, ви можете використовувати прапорець --skip-phases, який працює аналогічно до роботи з фазами kubeadm join та kubeadm init.

Очищення зовнішнього etcd

kubeadm reset не видалить жодних даних etcd, якщо використовується зовнішній etcd. Це означає, що якщо ви знову виконаєте kubeadm init з використанням тих самих точок доступу etcd, ви побачите стан від попередніх кластерів.

Щоб видалити дані etcd, рекомендується використовувати клієнт, такий як etcdctl, наприклад:

etcdctl del "" --prefix

Дивіться документацію etcd для отримання додаткової інформації.

Відповідне завершення роботи kube-apiserver

Якщо ваш kube-apiserver налаштований з прапорцем --shutdown-delay-duration, ви можете виконати наступні команди, щоб спробувати завершити роботу відповідним чином для запущеного Pod API сервера, перед тим як виконати kubeadm reset:

yq eval -i '.spec.containers[0].command = []' /etc/kubernetes/manifests/kube-apiserver.yaml
timeout 60 sh -c 'while pgrep kube-apiserver >/dev/null; do sleep 1; done' || true

Що далі

  • kubeadm init для створення вузла панелі управління Kubernetes
  • kubeadm join для приєднання робочого вузла Kubernetes до кластера

10.1.7 - kubeadm token

Токени запуску (Bootstrap token) використовуються для встановлення двосторонньої довіри між вузлом, який приєднується до кластера, та вузлом панелі управління, як описано в розділі автентифікація за допомогою токенів запуску.

kubeadm init створює початковий токен з часом життя 24 години. Наступні команди дозволяють вам керувати таким токеном, а також створювати та керувати новими.

kubeadm token create

Створює токени запуску на сервері.

Опис

Ця команда створює токен запуску для вас. Ви можете вказати способи використання цього токену, "час життя" і необовʼязковий опис, зрозумілий людині.

[token] — це власне токен, який потрібно записати. Це має бути безпечно згенерований випадковий токен виду "[a-z0-9]{6}.[a-z0-9]{16}". Якщо [token] не вказано, kubeadm згенерує випадковий токен замість нього.

kubeadm token create [token]

Параметри

--certificate-key string

Якщо використовується разом із '--print-join-command', виводить повний прапорець 'kubeadm join', необхідний для приєднання до кластера як панелі управління. Щоб створити новий ключ сертифіката, потрібно використовувати 'kubeadm init phase upload-certs --upload-certs'.

--config string

Шлях до файлу конфігурації kubeadm.

--description string

Опис, зрозумілий для людини, як використовується цей токен.

--groups strings     Типово: "system:bootstrappers:kubeadm:default-node-token"

Додаткові групи, які будуть автентифікуватися за допомогою цього токена при використанні для автентифікації. Повинно відповідати "\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z"

-h, --help

довідка create

--print-join-command

Замість того, щоб виводити тільки токен, вивести повний прапорець 'kubeadm join', необхідний для приєднання до кластера за допомогою токена.

--ttl duration     Типово: 24h0m0s

Тривалість перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться.

--usages strings     Типово: "signing,authentication"

Описує способи, в яких цей токен може використовуватися. Ви можете передавати --usages кілька разів або надати список параметрів через кому. Дійсні параметри: [signing,authentication]

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm token delete

Видаляє токени запуску на сервері.

Опис

Ця команда видаляє токени запуску для вас.

Значення [token-value] — це повний токен у вигляді "[a-z0-9]{6}.[a-z0-9]{16}" або Token ID виду "[a-z0-9]{6}", який потрібно видалити.

kubeadm token delete [token-value] ...

Параметри

-h, --help

довідка delete

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm token generate

Генерує та виводить токен запуску, але не створює його на сервері

Опис

Ця команда виведе випадково згенерований токен запуску, який можна використовувати з командами "init" та "join".

Ви не зобовʼязані використовувати цю команду для створення токена. Ви можете зробити це самостійно, якщо він має формат "[a-z0-9]{6}.[a-z0-9]{16}". Ця команда надається для зручності створення токенів у зазначеному форматі.

Ви також можете використовувати "kubeadm init" без вказання токена, і він буде згенерований та виведений для вас.

kubeadm token generate [flags]

Параметри

-h, --help

довідка generate

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm token list

Виводить перелік токенів запуску на сервері

Опис

Ця команда виведе перелік всіх токенів запуску на сервері.

kubeadm token list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігноруйте будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang і jsonpath.

-h, --help

довідка list

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залиште managedFields під час вводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm join — для початкового запуску робочого вузла Kubernetes nf приєднання його до кластера

10.1.8 - kubeadm version

Виводіть версію kubeadm

Опис

Ця команда виводить версію kubeadm.

kubeadm version [flags]

Параметри

-h, --help

довідка version

-o, --output string

Формат виводу; доступні варіанти: 'yaml', 'json' та 'short'

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.9 - kubeadm alpha

Наразі в kubeadm alpha немає експериментальних команд.

Що далі

  • kubeadm init для створення вузла панелі управління Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, внесених на хості за допомогою kubeadm init або kubeadm join

10.1.10 - kubeadm certs

kubeadm certs надає утиліти для керування сертифікатами. Для отримання детальної інформації про використання цих команд, дивіться Керування сертифікатами за допомогою kubeadm.

kubeadm certs

Збірка операцій для роботи з сертифікатами Kubernetes.

Команди, повʼязані з обробкою сертифікатів kubernetes

Опис

Команди, повʼязані з обробкою сертифікатів kubernetes

kubeadm certs [command]

Параметри

-h, --help

довідка certs

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

kubeadm certs renew

Ви можете поновити всі сертифікати Kubernetes, використовуючи підкоманду all, або поновити їх вибірково. Для отримання детальної інформації дивіться Ручне поновлення сертифікатів.

Поновлення сертифікатів для кластера Kubernetes

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm certs renew [flags]

Параметри

-h, --help

довідка renew

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлення всіх доступних сертифікатів

Опис

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

kubeadm certs renew all [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на поточних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, який apiserver використовує для доступу до etcd

Опис

Поновлює сертифікат, який apiserver використовує для доступу до etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR запит.

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

kubeadm certs renew apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-etcd-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для сервера API для підключення до kubelet

Опис

Поновлює сертифікат для сервера API для підключення до kubelet.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-kubelet-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для обслуговування API Kubernetes

Синопсис

Поновлює сертифікат для обслуговування API Kubernetes.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew apiserver [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew controller-manager.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка controller-manager.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd

Опис

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-healthcheck-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним

Опис

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-peer

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для обслуговування etcd

Опис

Поновлює сертифікат для обслуговування etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-server

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлення сертифіката клієнта front proxy

Опис

Поновлення сертифіката клієнта front proxy.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка front-proxy-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew scheduler.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка scheduler.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

kubeadm certs renew super-admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка super-admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm certs certificate-key

Ця команда може бути використана для створення нового ключа сертифіката для панелі управління. Ключ може бути переданий як --certificate-key до kubeadm init та kubeadm join для забезпечення автоматичного копіювання сертифікатів при підключенні додаткових вузлів панелі управління.

Генерує ключів сертифікатів

Опис

Ця команда виведе захищений випадково згенерований ключ сертифіката, який можна використовувати з командою "init".

Ви також можете скористатися командою "kubeadm init --upload-certs" без зазначення ключа сертифіката, і вона згенерує і виведе його для вас.

kubeadm certs certificate-key [flags]

Параметри

-h, --help

Довідка certificate-key

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm certs check-expiration

Ця команда перевіряє термін дії сертифікатів у локальному PKI, керованому kubeadm. Для отримання детальної інформації дивіться Перевірка терміну дії сертифікатів.

Перевіряє термін дії сертифікатів для кластера Kubernetes

Опис

Перевіряє термін дії сертифікатів у локальному PKI, яким керує kubeadm.

kubeadm certs check-expiration [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується тільки до форматів виведення golang і jsonpath.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка check-expiration

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залишати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm certs generate-csr

Ця команда може бути використана для створення ключів і CSRs для всіх сертифікатів панелі управління та файлів kubeconfig. Користувач може потім підписати CSRs з CA на свій вибір. Для отримання додаткової інформації про використання команди дивіться Підписання запитів на підписання сертифікатів (CSR), створених за допомогою kubeadm.

Генерує ключі та запити на підписання сертифікатів

Опис

Генерує ключі та запити на підписування сертифікатів (CSRs) для всіх сертифікатів, необхідних для роботи панелі управління. Ця команда також генерує часткові файли kubeconfig з даними приватного ключа в полі "users > user > client-key-data", і для кожного файлу kubeconfig створюється супутній файл ".csr".

Ця команда призначена для використання в Режимі Kubeadm з зовнішнім CA Kubeadm. Вона генерує CSRs, які ви можете подати на підписання до вашого зовнішнього центру сертифікації.

Закодовані в PEM підписані сертифікати повинні бути збережені поруч з файлами ключів, використовуючи ".crt" як розширення файлу, або, у випадку з файлами kubeconfig, закодований в PEM підписаний сертифікат повинен бути закодований у base64 і доданий до файлу kubeconfig в полі "users > user > client-certificate-data".

kubeadm certs generate-csr [flags]

Приклади

# Наступна команда згенерує ключі та CSRs для всіх сертифікатів панелі управління та файлів kubeconfig:
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Параметри

--cert-dir string

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка generate-csr

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для запуску вузла панелі управління Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, внесених за допомогою kubeadm init або kubeadm join

10.1.11 - kubeadm init phase

kubeadm init phase дозволяє вам викликати атомарні кроки процесу початкового завантаження. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви можете заповнити прогалини якщо ви бажаєте застосувати кастомізацію.

kubeadm init phase узгоджується з kubeadm init workflow, і за лаштунками обидва використовують той самий код.

kubeadm init phase preflight

Використовуючи цю команду, ви можете виконати попередні перевірки на вузлі панелі управління.

Виконує передпольотні перевірки

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm init phase preflight [flags]

Приклади

# Виконує передпольотні перевірки для kubeadm init з конфігураційним файлом config.yaml
kubeadm init phase preflight --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase kubelet-start

Ця фаза створить файл конфігурації kubelet та файл оточення та запустить kubelet.

Записує налаштування kubelet та (пере)запускаємо kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запустимо kubelet.

kubeadm init phase kubelet-start [flags]

Приклади

# Записує файл динамічного оточення з прапорами kubelet з файлу InitConfiguration.
kubeadm init phase kubelet-start --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase certs

Може використовуватися для створення всіх необхідних сертифікатів за допомогою kubeadm.

Генерує сертифікати

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm init phase certs [flags]

Параметри

-h, --help

Довідка certs

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує всі сертифікати

Опис

Генерує всі сертифікати.

kubeadm init phase certs all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes

Опис

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes та зберігає їх у файлах ca.crt та ca.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати для обслуговування API Kubernetes

Опис

Генерує сертифікати для обслуговування API Kubernetes та зберігає їх у файли apiserver.crt та apiserver.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver [flags]

Операції

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати для сервера API для зʼєднання з kubelet

Опис

Генерує сертифікати для сервера API для зʼєднання з kubelet та зберігає їх у файлах apiserver-kubelet-client.crt та apiserver-kubelet-client.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-kubelet-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує самопідписні CA для надання ідентифікаторів для front proxy

Опис

Генерує самопідписні CA для надання ідентифікаторів для front proxy, та зберігає їх у файлах front-proxy-ca.crt та front-proxy-ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-ca [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сетритфікати для клієнта front proxy

Опис

Генерує сертифікати для клієнта front proxy, та зберігає їх у файлах front-proxy-client.crt та front-proxy-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує самопідписаний центр сертифікації для надання ідентифікаторів для etcd

Опис

Ця команда генерує самопідписаний центр сертифікації (CA) для надання ідентифікаторів для etcd, та зберігає їх у файлах etcd/ca.crt та etcd/ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифітати для обслуговування etcd

Опис

Генерує сертифікати для обслуговування etcd, та зберігає їх у файлах etcd/server.crt та etcd/server.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-server

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генгерує сертифікати для вузлів etcd для звʼязку між собою

Опис

Генерує сертифікати для вузлів etcd для звʼязку між собою, та зберігає їх у файлах etcd/peer.crt та etcd/peer.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-peer

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікат для проб життєздатності для перевірки справності etcd

Опис

Генерує сертифікат для проб життєздатності для перевірки справності etcd, та зберігає його у файлах etcd/healthcheck-client.crt та etcd/healthcheck-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-healthcheck-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати, які apiserver використовує для доступу до etcd

Опис

Генерує сертифікати, які apiserver використовує для доступу до etcd та зберігає їх у файлах apiserver-etcd-client.crt та apiserver-etcd-client.key

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-etcd-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі

Опис

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі, та записує їх у файли sa.key та sa.pub.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs sa [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--kubeconfig string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка sa

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase kubeconfig

Ви можете створити всі необхідні файли kubeconfig за допомогою підкоманди all або викликати їх окремо.

Генерує всі файли kubeconfig, необхідні для встановлення панелі управління та файл kubeconfig адміністратора

Опис

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

kubeadm init phase kubeconfig [flags]

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує всі файли kubeconfig

Опис

Генерує всі файли kubeconfig.

kubeadm init phase kubeconfig all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для використання адміністратором та для самого kubeadm

Опис

Ця команда генерує файл kubeconfig для використання адміністратором та для самого kubeadm й зберігає його у файл admin.conf.

kubeadm init phase kubeconfig admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження

Опис

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження та зберігає його у файлі kubelet.conf.

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

kubeadm init phase kubeconfig kubelet [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для використання менеджером контролерів

Опис

Генерує файл kubeconfig для використання менеджером контролерів та зберігає його у файл controller-manager.conf.

kubeadm init phase kubeconfig controller-manager [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для використання планувальником

Опис

Генерує файл kubeconfig для використання планувальником та зберігає його у файл scheduler.conf.

kubeadm init phase kubeconfig scheduler [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для суперкористувача

Опис

Генерує файл kubeconfig для суперкористувача та зберігає його у файл super-admin.conf.

kubeadm init phase kubeconfig super-admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка super-admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase control-plane

Використовуючи цю фазу, ви можете створити всі необхідні файли статичних Podʼів для компонентів панелі управління.

Генерує всі маніфести статичних Podʼів потрібні для створення панелі управління

Опис

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

kubeadm init phase control-plane [flags]

Параметри

-h, --help

Довідка control-plane

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує всі фали маніфестів статичних Podʼів

Опис

Генерує всі файли маніфестів статичних Podʼів.

kubeadm init phase control-plane all [flags]

Приклади

# Генерує всі файли маніфестів статичних Podʼів для компонентів панелі управління,
# функціонально еквівалентні до тих, що генеруються командою kubeadm init.
kubeadm init phase control-plane all

# Генерує всі файли маніфестів статичних Podʼів з використанням опцій, отриманих з конфігураційного файлу.
kubeadm init phase control-plane all --config config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфест статичного Podʼа для kube-apiserver

Опис

Генерує маніфест статичного Podʼа для kube-apiserver

kubeadm init phase control-plane apiserver [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка apiserver

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфест статичного Podʼа для kube-controller-manager

Опис

Генерує маніфест статичного Podʼа для kube-controller-manager

kubeadm init phase control-plane controller-manager [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфест статичного Podʼа для kube-scheduler

Опис

Генерує маніфест статичного Podʼа для kube-scheduler

kubeadm init phase control-plane scheduler [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase etcd

Використовуйте наступну фазу, щоб створити локальний екземпляр etcd на основі файлу статичного Pod.

Генерує файл маніфесту статичного Podʼа для екземпляра local etcd

Опис

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

kubeadm init phase etcd [flags]

Параметри

-h, --help

Довідка etcd

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

kubeadm init phase etcd local [flags]

Приклади

# Генерує файл маніфесту статичного Podʼа для etcd, функціонально
# еквівалентного до того, що генерується командою kubeadm init.
kubeadm init phase etcd local

# Генерує файл маніфесту статичного Podʼа для etcd з використанням опцій
# отриманих з файлу конфігурації.
kubeadm init phase etcd local --config config.yaml

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка local

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase upload-config

За допомогою цієї команди ви можете завантажити конфігурацію kubeadm до вашого кластера. Також ви можете скористатися kubeadm config.

Завантажує конфігурації kubeadm та kubelet у ConfigMap

Опис

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

kubeadm init phase upload-config [flags]

Параметри

-h, --help

Довідка upload-config

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажуємо всю конфігурацію в ConfigMap

Опис

Завантажує всю конфігурацію в ConfigMap.

kubeadm init phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажує kubeadm ClusterConfiguration у ConfigMap

Опис

Завантажує конфігурацію кластера kubeadm ClusterConfig до ConfigMap з назвою kubeadm-config у просторі імен kube-system. Це дозволить правильно конфігурувати компоненти системи та спростить роботу користувачів під час оновлення.

Альтернативно, ви можете використовувати kubeadm config.

kubeadm init phase upload-config kubeadm [flags]

Приклади

# Завантаження конфігурації кластера
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

Параметри

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeadm

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажує налаштування компонентів kubelet у ConfigMap

Опис

Завантажуємо конфігурацію kubelet, видобуту з обʼєкта kubeadm InitConfiguration, до ConfigMap kubelet-config у кластері

kubeadm init phase upload-config kubelet [flags]

Приклади

# Завантаження конфігурації kubelet з файла конфігурації kubeadm у ConfigMap в кластері
kubeadm init phase upload-config kubelet --config kubeadm.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase upload-certs

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

Завантажує сертифікати до kubeadm-certs

Опис

Завантажує сертифікати панелі управління в Secret kubeadm-certs

kubeadm init phase upload-certs [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка upload-certs

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase mark-control-plane

Використовуйте наступну фазу для позначення вузла як вузла панелі управління.

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm init phase mark-control-plane [flags]

Приклади

# Застосовує мітку та taint панелі управління до поточного вузла, функціонально еквівалентно до того, що виконується командою kubeadm init.
kubeadm init phase mark-control-plane --config config.yaml

# Застосовує мітку та taint панелі управління до конкретного вузла
kubeadm init phase mark-control-plane --node-name myNode

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase bootstrap-token

Використовуйте наступну фазу для створення або керування bootstrap токенів.

Генерує токени bootstrap, які використовуються для приєднання вузла до кластера

Опис

Токени bootstrap використовуються для встановлення двосторонньої довіри між вузлом, що приєднується до кластера, і вузлом панелі управління.

Ця команда виконує всі налаштування, необхідні для роботи токенів bootstrap, а потім створює початковий токен.

kubeadm init phase bootstrap-token [flags]

Приклади

# Налаштувати всі конфігурації токенів Bootstrap та створити 
# початковий токен, функціонально еквівалентний до того, що 
# генерується командою kubeadm init.
kubeadm init phase bootstrap-token

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Довідка bootstrap-token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase kubelet-finalize

Використовуйте наступну фазу для оновлення налаштувань, що стосуються kubelet після TLS bootstrap. Ви можете використовувати субкоманду all, щоб запустити всі фази `kubelet-finalize.

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

Опис

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

kubeadm init phase kubelet-finalize [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS"
kubeadm init phase kubelet-finalize all --config

Параметри

-h, --help

Довідка kubelet-finalize

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Запускає всі фази kubelet-finalize

Опис

Запускає всі фази kubelet-finalize.

kubeadm init phase kubelet-finalize all [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS
kubeadm init phase kubelet-finalize all --config

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

Опис

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка experimental-cert-rotation

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase addon

Ви можете встановити всі доступні надбудови за допомогою підкоманди all, або встановити їх вибірково.

Встановлює необхідні надбудови для проходження тестів на відповідність

Опис

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

kubeadm init phase addon [flags]

Параметри

-h, --help

Довідка addon

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Встановлює всі надбудови

Опис

Вставляє всі надбудови.

kubeadm init phase addon all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Встановлює надбудову CoreDNS в кластер Kubernetes

Опис

Встановлює компоненти надбудови CoreDNS через сервер API. Зверніть увагу, що хоча DNS-сервер розгорнуто, його не буде заплановано, доки не буде встановлено CNI.

kubeadm init phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка coredns

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Встановлює надбудову kube-proxy в кластер Kubernetes

Опис

Встановлює компоненти надбудови kube-proxy через API-сервер.

kubeadm init phase addon kube-proxy [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Для отримання більш детальної інформації про кожне поле в конфігурації v1beta4 ви можете перейти на нашу сторінки довідки API.

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm alpha для випробування експериментальних функцій

10.1.12 - kubeadm join phase

kubeadm join phase дозволяє викликати атомарні кроки процесу приєднання. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви заповните прогалини, якщо захочете застосувати налаштування.

kubeadm join phase узгоджується з workflow приєднання kubeadm, і за лаштунками обидва використовують той самий код.

kubeadm join phase

Використовуйте цю команду для виклику однієї фази робочого процесу join

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу join

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase preflight

Використовуючи цю фазу, ви можете виконати передпольотну перевірку вузла, що приєднується.

Виконує передполітні перевірки join

Опис

Виконує передполітні перевірки для kubeadm join.

kubeadm join phase preflight [api-server-endpoint] [flags]

Приклади

# Виконує передполітні перевірки для kubeadm join
kubeadm join phase preflight --config kubeadm-config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase control-plane-prepare

Використовуючи цю фазу, ви можете підготувати вузол до обслуговування панелі управління.

Готує машину до обслуговування панелі управління

Опис

Готує машину до обслуговування панелі управління.

kubeadm join phase control-plane-prepare [flags]

Приклади

# Готує машину до обслуговування панелі управління
kubeadm join phase control-plane-prepare all

Параметри

-h, --help

Довідка control-plane-prepare

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Готує машину для роботи як панелі управління

Опис

Готує машину для роботи як панелі управління.

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

Опис

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка download-certs

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати для нових компенонетів панелі управління

Опис

Генерує сертифікати для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка certs

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує kubeconfig для нових компонентів панелі управління

Опис

Генерує kubeconfig для нових компонентів панелі управління, які будуть додані до кластера.

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeconfig

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфести для нових компонентів панелі управління

Опис

Генерує маніфести для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare control-plane [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка control-plane

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase kubelet-start

На цьому етапі ви можете записати налаштування kubelet, сертифікати та (пере)запустити kubelet.

Записує налаштування kubelet, сертифікати та (пере)запускає kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запускає kubelet.

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

Параметри

tr>
--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

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

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

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

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase control-plane-join

Використовуючи цю фазу, ви можете приєднати вузол як екземпляр панелі управління.

Приєднує машину до екземпляра панелі управління

Опис

Приєднує машину до екземпляра панелі управління.

kubeadm join phase control-plane-join [flags]

Приклади

# Приєднує машину до екземпляра панелі управління
kubeadm join phase control-plane-join all

Параметри

-h, --help

Довідка control-plane-join

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Приєднує машину до екземпляру панелі управління

Опис

Приєднує машину до екземпляру панелі управління.

kubeadm join phase control-plane-join all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Додає нового учасника local etcd

Опис

Додає нового учасника local etcd

kubeadm join phase control-plane-join etcd [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm join phase control-plane-join mark-control-plane [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm alpha для випробування експериментальних функцій

10.1.13 - kubeadm kubeconfig

kubeadm kubeconfig надає інструменти для управління файлами kubeconfig.

Приклади використання kubeadm kubeconfig user дивіться в розділі Генерація файлів kubeconfig для додаткових користувачів.

kubeadm kubeconfig

Файлові утиліти Kubeconfig

Опис

Файлові утиліти Kubeconfig.

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm kubeconfig user

За допомогою цієї команди можна вивести файл kubeconfig для додаткового користувача.

Виводить файл kubeconfig для додаткового користувача

Опис

Виводить файл kubeconfig для додаткового користувача.

kubeadm kubeconfig user [flags]

Приклади

# Виводить файл kubeconfig для додаткового користувача з іменем foo
kubeadm kubeconfig user --client-name=foo

# Виводить файл kubeconfig для додаткового користувача з іменем foo, використовуючи конфігураційний файл kubeadm bar
kubeadm kubeconfig user --client-name=foo --config=bar

Параметри

--client-name string

Імʼя користувача. Буде використовуватися як CN у разі створення клієнтських сертифікатів

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка user

--org strings

Організації сертифіката клієнта. Буде використовуватися як O, якщо будуть створені клієнтські сертифікати

--token string

TТокен, який слід використовувати як механізм автентифікації для цього kubeconfig замість клієнтських сертифікатів

--validity-period duration     Типово: 8760h0m0s

Термін дії клієнтського сертифіката. Відраховується від поточного часу.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

10.1.14 - kubeadm reset phase

kubeadm reset phase дозволяє вам викликати атомарні кроки процесу reset. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви можете заповнити прогалини якщо ви бажаєте застосувати кастомізацію.

kubeadm reset phase узгоджується з kubeadm reset workflow, і за лаштунками обидва використовують той самий код.

kubeadm reset phase

Використовуйте цю команду для виклику однієї фази процесу reset

Опис

Використовуйте цю команду для виклику однієї фази процесу reset

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm reset phase preflight

За допомогою цієї фази ви можете виконати передпольотну перевірку вузла, який скидається.

Виконує передполітні перевірки для kubeadm reset

Опис

Виконує передполітні перевірки для kubeadm reset.

kubeadm reset phase preflight [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm reset phase remove-etcd-member

За допомогою цієї фази ви можете вилучити члена etcd цього вузла панелі управління з кластера etcd.

Видаляє члена local etcd

Опмс

Видаляє члена local etcd для вузла панелі управління.

kubeadm reset phase remove-etcd-member [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка remove-etcd-member

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm reset phase cleanup-node

За допомогою цієї фази ви можете виконати очищення на цьому вузлі.

Запускає очищення вузла

Опис

Запускає очищення вузла.

kubeadm reset phase cleanup-node [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--cri-socket string

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

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка cleanup-node

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm alpha для випробування експериментальних функцій

10.1.15 - kubeadm upgrade phase

У версії v1.15.0 kubeadm запровадив попередню підтримку фаз kubeadm upgrade node. Фази для інших підкоманд kubeadm upgrade, таких як apply, можуть бути додані в наступних випусках.

kubeadm upgrade node phase

Використовуючи цю фазу, ви можете вибрати виконання окремих кроків оновлення вторинних вузлів панелі управління або робочих вузлів. Зверніть увагу, що kubeadm upgrade apply все ще потрібно викликати на первинному вузлі панелі управління.

Використовуйте цю команду для виклику однієї фази робочого процесу node

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу node

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Виконує попередні перевірки на вузлі перед оновленням

Опис

Ця команда виконує попередні перевірки для kubeadm upgrade node.

kubeadm upgrade node phase preflight [flags]

Параметри

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є

Опис

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є.

kubeadm upgrade node phase control-plane [flags]

Параметри

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Оновлює конфігурації kubelet для цього вузла

Опис

Завантажує конфігурацію kubelet з файлу kubelet-config ConfigMap, що зберігається в кластері

kubeadm upgrade node phase kubelet-config [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

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

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm upgrade для оновлення вузла kubeadm
  • kubeadm alpha для випробування експериментальних функцій

10.1.16 - Деталі реалізації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.10 [stable]

kubeadm init та kubeadm join разом забезпечують гарну послідовність дій користувача для створення базового кластера Kubernetes з нуля, відповідно до найкращих практик. Однак може бути не очевидно, як kubeadm це робить.

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

Основні принципи дизайну

Кластер, який налаштовується за допомогою kubeadm init та kubeadm join, має бути:

  • Захищеним: Він повинен дотримуватися останніх найкращих практик, таких як:
    • забезпечення RBAC
    • використання Node Authorizer
    • використання захищеного зв’язку між компонентами панелі управління
    • використання захищеного зв’язку між API-сервером і kubelet-ами
    • обмеження доступу до API kubelet-а
    • обмеження доступу до API для системних компонентів, таких як kube-proxy та CoreDNS
    • обмеження доступу до того, що може отримати Bootstrap Token
  • Зручним для користувачів: Користувачеві не повинно знадобитися виконувати більше, ніж кілька команд:
    • kubeadm init
    • export KUBECONFIG=/etc/kubernetes/admin.conf
    • kubectl apply -f <network-of-choice.yaml>
    • kubeadm join --token <token> <endpoint>:<port>
  • Розширюваним:
    • Він не повинен віддавати перевагу жодному конкретному мережевому провайдеру. Налаштування мережі кластерів не входить до сфери компетенції
    • Він повинен надавати можливість використовувати конфігураційний файл для налаштування різних параметрів

Константи та добре відомі значення та шляхи

Щоб зменшити складність і спростити розробку вищого рівня інструментів, що будуються на основі kubeadm, він використовує обмежений набір констант для добре відомих шляхів та імен файлів.

Тека Kubernetes /etc/kubernetes є константою в застосунку, оскільки вона є очевидним шляхом у більшості випадків і найінтуїтивнішим розташуванням; інші константні шляхи та імена файлів є такими:

  • /etc/kubernetes/manifests як шлях, де kubelet повинен шукати маніфести статичних Podʼів. Імена маніфестів статичних Podʼів:

    • etcd.yaml
    • kube-apiserver.yaml
    • kube-controller-manager.yaml
    • kube-scheduler.yaml

  • /etc/kubernetes/ як шлях, де зберігаються файли kubeconfig з ідентифікаторами для компонентів панелі управління. Імена файлів kubeconfig:

    • kubelet.conf (bootstrap-kubelet.conf під час TLS bootstrap)
    • controller-manager.conf
    • scheduler.conf
    • admin.conf для адміністратора кластера і kubeadm
    • super-admin.conf для супер-адміністратора кластера, який може обходити RBAC

  • Імена сертифікатів і ключових файлів:

    • ca.crt, ca.key для центру авторизації Kubernetes
    • apiserver.crt, apiserver.key для сертифіката API-сервера
    • apiserver-kubelet-client.crt, apiserver-kubelet-client.key для клієнтського сертифіката, що використовується API-сервером для безпечного підключення до kubelet-ів
    • sa.pub, sa.key для ключа, який використовується менеджером контролерів при підписанні ServiceAccount
    • front-proxy-ca.crt, front-proxy-ca.key для центру авторизації front-проксі
    • front-proxy-client.crt, front-proxy-client.key для клієнта front-проксі

Внутрішній дизайн робочого процесу kubeadm init

Команда kubeadm init складається з послідовності атомарних завдань для виконання, як описано в внутрішньому робочому процесі kubeadm init.

Команда kubeadm init phase дозволяє користувачам викликати кожне завдання окремо, і в кінцевому підсумку пропонує багаторазовий і компонований API/інструментарій, який може бути використаний іншими інструментами початкового завантаження Kubernetes, будь-яким інструментом автоматизації ІТ або досвідченим користувачем для створення власних кластерів.

Перевірка перед установкою (Preflight checks)

Kubeadm виконує набір перевірок перед початком ініціалізації з метою перевірки передумов і уникнення типових проблем під час запуску кластера.

Користувач може пропустити певні перевірки перед установкою або всі за допомогою опції --ignore-preflight-errors.

  • [Попередження], якщо версія Kubernetes, яку слід використовувати (вказана за допомогою прапорця --kubernetes-version), є хоча б на одну мінорну версію вищою за версію kubeadm CLI.
  • Вимоги до системи Kubernetes:
    • якщо використовується Linux:
      • [Помилка], якщо версія ядра старіша за мінімально необхідну версію
      • [Помилка], якщо не налаштовані необхідні підсистеми cgroups
  • [Помилка], якщо точка доступу CRI не відповідає
  • [Помилка], якщо користувач не є root
  • [Помилка], якщо імʼя машини не є дійсним DNS-піддоменом
  • [Попередження], якщо імʼя хосту неможливо знайти через мережевий пошук
  • [Помилка], якщо версія kubelet нижча за мінімальну підтримувану версію kubelet, підтримувану kubeadm (поточна мінорна версія -1)
  • [Помилка], якщо версія kubelet хоча б на одну мінорну версію вища за необхідну версію панелі управління (непідтримуване відхилення версій)
  • [Попередження], якщо служба kubelet не існує або вона вимкнена
  • [Попередження], якщо активний firewalld
  • [Помилка], якщо використовується порт привʼязки API-сервера або порти 10250/10251/10252
  • [Помилка], якщо тека /etc/kubernetes/manifests вже існує і не є порожньою
  • [Помилка], якщо включений swap
  • [Помилка], якщо команди conntrack, ip, iptables, mount, nsenter відсутні в шляху до команд
  • [Попередження], якщо команди ebtables, ethtool, socat, tc, touch, crictl відсутні в шляху до команд
  • [Попередження], якщо додаткові аргументи для API-сервера, менеджера контролерів, планувальника містять недійсні параметри
  • [Попередження], якщо зʼєднання з https://API.AdvertiseAddress:API.BindPort пройде через проксі
  • [Попередження], якщо зʼєднання з підмережею сервісів пройде через проксі (перевіряється лише перша адреса)
  • [Попередження], якщо зʼєднання з підмережею Podʼів пройде через проксі (перевіряється лише перша адреса)
  • Якщо використовується зовнішній etcd:
    • [Помилка], якщо версія etcd старіша за мінімально необхідну версію
    • [Помилка], якщо сертифікати або ключі etcd вказані, але не надані
  • Якщо використовується внутрішній etcd (і, таким чином, буде встановлений локальний etcd):
    • [Помилка], якщо використовується порт 2379
    • [Помилка], якщо тека Etcd.DataDir вже існує і не є порожньою
  • Якщо режим авторизації — ABAC:
    • [Помилка], якщо abac_policy.json не існує
  • Якщо режим авторизації — WebHook:
    • [Помилка], якщо webhook_authz.conf не існує

Генерація необхідних сертифікатів

Kubeadm генерує пари сертифікатів і приватних ключів для різних цілей:

  • Самопідписаний центр сертифікації для кластера Kubernetes, збережений у файлі ca.crt і приватний ключ у файлі ca.key

  • Сертифікат обслуговування для API-сервера, згенерований за допомогою ca.crt як CA, збережений у файлі apiserver.crt разом із приватним ключем apiserver.key. Цей сертифікат повинен містити наступні альтернативні імена:

    • Внутрішній clusterIP сервісу Kubernetes (перша адреса в CIDR служб, наприклад, 10.96.0.1, якщо підмережа сервісів — 10.96.0.0/12)
    • DNS-імена Kubernetes, наприклад kubernetes.default.svc.cluster.local, якщо значення прапорця --service-dns-domain є cluster.local, а також типові DNS-імена kubernetes.default.svc, kubernetes.default, kubernetes
    • Імʼя вузла (node-name)
    • --apiserver-advertise-address
    • Додаткові альтернативні імена, вказані користувачем

  • Клієнтський сертифікат для API-сервера для безпечного підключення до kubelet-ів, згенерований за допомогою ca.crt як CA і збережений у файлі apiserver-kubelet-client.crt разом із його приватним ключем apiserver-kubelet-client.key. Цей сертифікат повинен бути в організації system:masters

  • Приватний ключ для підпису токенів ServiceAccount, збережений у файлі sa.key разом із його публічним ключем sa.pub

  • Центр сертифікації для front proxy, збережений у файлі front-proxy-ca.crt разом із його ключем front-proxy-ca.key

  • Клієнтський сертифікат для клієнта front proxy, згенерований за допомогою front-proxy-ca.crt як CA і збережений у файлі front-proxy-client.crt разом із його приватним ключем front-proxy-client.key

Сертифікати зберігаються типово у /etc/kubernetes/pki, але цю теку можна налаштувати за допомогою прапорця --cert-dir.

Зверніть увагу на наступне:

  1. Якщо дані пари сертифікат-приватний ключ вже існують і їх зміст відповідає вищезазначеним вимогам, вони будуть використані, і фаза генерації для даного сертифіката буде пропущена. Це означає, що користувач може, наприклад, скопіювати поточний CA в /etc/kubernetes/pki/ca.{crt,key}, і після цього kubeadm використовуватиме ці файли для підпису інших сертифікатів. Див. також використання власних сертифікатів
  2. Для CA можливо надати файл ca.crt, але не надавати файл ca.key. Якщо всі інші сертифікати і файли kubeconfig вже на місці, kubeadm визнає цю умову і активує ExternalCA, що також означає, що контролер csrsigner в контролері-менеджері не буде запущений
  3. Якщо kubeadm працює в режимі зовнішньої CA; всі сертифікати повинні бути надані користувачем, оскільки kubeadm не може їх генерувати самостійно
  4. У випадку запуску kubeadm у режимі --dry-run, файли сертифікатів записуються в тимчасову теку
  5. Генерацію сертифікатів можна викликати окремо за допомогою команди kubeadm init phase certs all

It seems like you're referring to documentation or a detailed guide on how kubeadm handles various aspects of Kubernetes initialization and configuration. If you need a translation of this content into Ukrainian, I can provide that. Here's the translation:

Генерація kubeconfig файлів для компонентів панелі управління

Kubeadm генерує kubeconfig файли з ідентичностями для компонентів панелі управління:

  • Файл kubeconfig для kubelet, який використовується під час ініціалізації TLS — /etc/kubernetes/bootstrap-kubelet.conf. У цьому файлі є bootstrap-token або вбудовані клієнтські сертифікати для автентифікації цього вузла у кластері.

    Цей клієнтський сертифікат повинен:

    • Бути в організації system:nodes, як вимагається модулем Node Authorization
    • Мати Загальне Імʼя (CN) system:node:<hostname-lowercased>

  • Файл kubeconfig для контролера-менеджера, /etc/kubernetes/controller-manager.conf; у цьому файлі вбудований клієнтський сертифікат з ідентичністю контролера-менеджера. Цей клієнтський сертифікат повинен мати CN system:kube-controller-manager, як визначено стандартними RBAC ролями ядра компонентів

  • Файл kubeconfig для планувальника, /etc/kubernetes/scheduler.conf; у цьому файлі вбудований клієнтський сертифікат з ідентичністю планувальника. Цей клієнтський сертифікат повинен мати CN system:kube-scheduler, як визначено стандартними RBAC ролями ядра компонентів

Додатково, kubeconfig файл для kubeadm як адміністративної сутності генерується і зберігається у /etc/kubernetes/admin.conf. Цей файл включає сертифікат з Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin. kubeadm:cluster-admins — це група, керована kubeadm. Вона повʼязана з cluster-admin ClusterRole під час kubeadm init, за допомогою super-admin.conf файлу, який не потребує RBAC. Файл admin.conf повинен залишатися на вузлах панелі управління і не повинен бути переданий іншим користувачам.

Під час kubeadm init генерується інший kubeconfig файл і зберігається у /etc/kubernetes/super-admin.conf. Цей файл включає сертифікат з Subject: O = system:masters, CN = kubernetes-super-admin. system:masters — це суперкористувачі, які обходять RBAC і роблять super-admin.conf корисним у випадку надзвичайної ситуації, коли кластер заблокований через неправильну конфігурацію RBAC. Файл super-admin.conf повинен зберігатися в безпечному місці і не повинен передаватися іншим користувачам.

Дивіться RBAC user facing role bindings для додаткової інформації про RBAC і вбудовані ClusterRoles та групи.

Зверніть увагу на наступне:

  1. Всі kubeconfig файли включають в себе сертифікат ca.crt.
  2. Якщо вказаний kubeconfig файл вже існує і його зміст відповідає вищезазначеним вимогам, то буде використано існуючий файл, і фаза генерації для даного kubeconfig буде пропущена.
  3. Якщо kubeadm працює в режимі ExternalCA mode, всі необхідні kubeconfig файли також повинні бути надані користувачем, оскільки kubeadm не може згенерувати їх самостійно.
  4. У випадку виконання kubeadm в режимі --dry-run, файли kubeconfig записуються в тимчасову теку.
  5. Генерацію kubeconfig файлів можна викликати окремо за допомогою команди kubeadm init phase kubeconfig all

Генерація маніфестів статичних Pod для компонентів панелі управління

Kubeadm записує файли маніфестів статичних Pod для компонентів панелі управління до /etc/kubernetes/manifests. kubelet спостерігає за цією текою для створення Podʼів при запуску.

Маніфести статичних Podʼів мають спільний набір властивостей:

  • Всі статичні Podʼи розгорнуті в просторі імен kube-system

  • Всі статичні Podʼи мають мітки tier:control-plane та component:{імʼя-компоненти}

  • Всі статичні Podʼи використовують клас пріоритету system-node-critical

  • На всіх статичних Podʼах встановлено hostNetwork: true, щоб дозволити запуск панелі управління до налаштування мережі; в результаті:

    • Адреса, яку використовує контролер-менеджер та планувальник для посилання на API-сервер, є 127.0.0.1
    • Якщо сервер etcd налаштовано локально, адреса etcd-server буде встановлена як 127.0.0.1:2379

  • Включено обрання лідера як для контролер-менеджера, так і для планувальника

  • Контролер-менеджер та планувальник будуть посилатися на файли kubeconfig з їхніми відповідними, унікальними ідентифікаторами

  • Всі статичні Podʼи отримують будь-які додаткові прапорці, вказані користувачем, як описано в передача користувацьких аргументів компонентам панелі управління

  • Всі статичні Podʼи отримують будь-які додаткові томи, вказані користувачем (Шлях хоста)

Зверніть увагу, що:

  1. Усі образи типово будуть витягуватися з registry.k8s.io. Для налаштування репозиторію образів див. використання власних образів
  2. У разі виконання kubeadm у режимі --dry-run файли статичних Podʼів записуються у тимчасову теку
  3. Генерацію маніфестів статичних Podʼів для компонентів панелі управління можна запустити окремо за допомогою команди kubeadm init phase control-plane all

Сервер API

Маніфест статичних Podʼів для сервера API обробляється наступними параметрами, наданими користувачами:

  • apiserver-advertise-address та apiserver-bind-port для звʼязку; якщо вони не вказані, стандартне значення буде IP-адреса основного мережевого інтерфейсу на машині та порт 6443
  • service-cluster-ip-range для використання сервісів
  • Якщо вказаний зовнішній сервер etcd, то etcd-servers та повʼязані налаштування TLS (etcd-cafile, etcd-certfile, etcd-keyfile); якщо зовнішній сервер etcd не вказано, буде використовуватися локальний etcd (через мережу хосту)
  • Якщо вказаний провайдер хмарних послуг, то налаштовується відповідний параметр --cloud-provider разом зі шляхом --cloud-config, якщо такий файл існує (експериментально, альфа версія, буде вилучено в майбутній версії)

Інші прапорці сервера API, що встановлені безумовно, включають:

  • --insecure-port=0 для уникнення небезпечних зʼєднань з сервером API

  • --enable-bootstrap-token-auth=true для активації модуля автентифікації BootstrapTokenAuthenticator. Див. TLS Bootstrapping для деталей

  • --allow-privileged до true (необхідно, наприклад, для kube-proxy)

  • --requestheader-client-ca-file до front-proxy-ca.crt

  • --enable-admission-plugins до:

    • NamespaceLifecycle наприклад, для уникнення видалення системних зарезервованих просторів імен
    • LimitRanger та ResourceQuota для встановлення обмежень на простори імен
    • ServiceAccount для автоматизації службових облікових записів
    • PersistentVolumeLabel приєднує мітки регіону або зони до PersistentVolumes, як визначено провайдером хмарних послуг (Цей контролер допуску є застарілим і буде вилучений у майбутній версії. Він типово не розгорнутий kubeadm починаючи з v1.9, якщо явно не вибрано використання gce або aws як провайдерів хмарних послуг)
    • DefaultStorageClass для встановлення типового класу зберігання на обʼєктах PersistentVolumeClaim
    • DefaultTolerationSeconds
    • NodeRestriction для обмеження того, що kubelet може змінювати (наприклад, тільки Podʼи на цьому вузлі)

  • --kubelet-preferred-address-types до InternalIP,ExternalIP,Hostname; це робить kubectl logs та іншу комунікацію API server-kubelet працюючою в середовищах, де імена хостів вузлів не розвʼязуються

  • Прапорці для використання сертифікатів, згенерованих на попередніх етапах:

    • --client-ca-file до ca.crt
    • --tls-cert-file до apiserver.crt
    • --tls-private-key-file до apiserver.key
    • --kubelet-client-certificate до apiserver-kubelet-client.crt
    • --kubelet-client-key до apiserver-kubelet-client.key
    • --service-account-key-file до sa.pub
    • --requestheader-client-ca-file до front-proxy-ca.crt
    • --proxy-client-cert-file до front-proxy-client.crt
    • --proxy-client-key-file до front-proxy-client.key

  • Інші прапорці для забезпечення безпеки front proxy (Агрегація API) комунікацій:

    • --requestheader-username-headers=X-Remote-User
    • --requestheader-group-headers=X-Remote-Group
    • --requestheader-extra-headers-prefix=X-Remote-Extra-
    • --requestheader-allowed-names=front-proxy-client

Менеджер контролерів

Маніфест статичного Podʼа для менеджера контролерів обробляється наступними параметрами, наданими користувачами:

  • Якщо kubeadm запускається з вказанням --pod-network-cidr, активується функція менеджера підмережі, необхідна для деяких мережевих втулків CNI, встановлюючи:

    • --allocate-node-cidrs=true
    • Прапорці --cluster-cidr та --node-cidr-mask-size відповідно до заданого CIDR

  • Якщо вказаний провайдер хмарних послуг, то відповідно налаштовується --cloud-provider, разом зі шляхом --cloud-config, якщо такий файл конфігурації існує (експериментально, альфа версія, буде вилучено в майбутній версії)

Інші прапорці, які встановлюються безумовно, включають:

  • --controllers, що активує всі стандартні контролери плюс контролери BootstrapSigner та TokenCleaner для TLS-запуску. Див. TLS Bootstrapping для деталей.

  • --use-service-account-credentials до true

  • Прапорці для використання сертифікатів, згенерованих на попередніх етапах:

    • --root-ca-file до ca.crt
    • --cluster-signing-cert-file до ca.crt, якщо відключений зовнішній режим CA, в іншому випадку до ""
    • --cluster-signing-key-file до ca.key, якщо відключений зовнішній режим CA, в іншому випадку до ""
    • --service-account-private-key-file до sa.key.

Планувальник

Маніфест статичного Podʼа для планувальника обробляється наступними параметрами, наданими користувачами.

Генерація маніфесту статичного Pod для локального etcd

Якщо ви вказали зовнішній etcd, цей крок буде пропущено. В іншому випадку kubeadm генерує маніфест статичного Pod для створення локального екземпляра etcd, що працює в Pod з наступними характеристиками:

  • слухати на localhost:2379 і використовувати HostNetwork=true
  • зробити монтування hostPath з dataDir до файлової системи хосту
  • Будь-які додаткові прапорці, вказані користувачем

Зверніть увагу, що:

  1. Образ контейнера etcd буде типово витягнутий з registry.gcr.io. Для налаштування власного репозиторію образів див. використання власних образів.
  2. Якщо ви запускаєте kubeadm у режимі --dry-run, маніфест статичного Pod для etcd записується у тимчасову теку.
  3. Ви можете безпосередньо викликати генерацію маніфесту статичного Pod для локального etcd за допомогою команди kubeadm init phase etcd local.

Очікування запуску панелі управління

kubeadm очікує (до 4 хвилин) на відповідь ok від localhost:6443/healthz (життєздатність kube-apiserver). Однак, для виявлення умов блокування, kubeadm швидко видає помилку, якщо localhost:10255/healthz (життєздатність kubelet) або localhost:10255/healthz/syncloop (готовність kubelet) не повертають ok в межах відповідно 40 та 60 секунд.

kubeadm покладається на kubelet для завантаження образів панелі управління і їх коректного запуску як статичних Podʼів. Після того як панель управління буде запущена, kubeadm завершує виконання завдань, описаних у наступних розділах.

Збереження конфігурації кластера kubeadm у ConfigMap для подальшого посилання

kubeadm зберігає конфігурацію, передану в kubeadm init, у ConfigMap з назвою kubeadm-config в просторі імен kube-system.

Це забезпечить можливість kubeadm у майбутньому (наприклад, під час оновлення kubeadm upgrade) визначати фактичний поточний стан кластера і приймати нові рішення на основі цих даних.

Зверніть увагу, що:

  1. Перед збереженням конфігурації кластера чутлива інформація, така як токен, видаляється з конфігурації.
  2. Завантаження конфігурації вузла панелі управління може бути викликане окремо за допомогою команди kubeadm init phase upload-config.

Позначення вузла як вузла панелі управління

Як тільки панель управління буде доступна, kubeadm виконує наступні дії:

  • Позначає вузол як вузол панелі управління з міткою node-role.kubernetes.io/control-plane=""
  • Додає на вузол taint node-role.kubernetes.io/control-plane:NoSchedule

Зверніть увагу, що фазу позначення вузла як вузла панелі управління можна викликати окремо за допомогою команди kubeadm init phase mark-control-plane.

Налаштування TLS-Bootstrapping для приєднання вузлів

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

kubeadm init забезпечує належну конфігурацію всього процесу, включаючи наступні кроки, а також налаштування прапорців API-сервера та контролера, як вже було описано у попередніх розділах.

Створення bootstrap токена

kubeadm init створює перший bootstrap токен, що генерується автоматично або надається користувачем за допомогою прапорця --token. Згідно з документацією щодо специфікації bootstrap токена, токен слід зберегти як секрет з іменем bootstrap-token-<token-id> у просторі імен kube-system.

Зверніть увагу, що:

  1. bootstrap токен, типово створений kubeadm init, використовуватиметься для перевірки тимчасових користувачів під час процесу TLS-запуску; ці користувачі будуть членами групи system:bootstrappers:kubeadm:default-node-token.
  2. Токен має обмежену чинність, стандартно 24 години (цей інтервал можна змінити за допомогою прапорця --token-ttl).
  3. Додаткові токени можна створити за допомогою команди kubeadm token, яка також надає інші корисні функції для управління токенами.

Дозвіл на виклик API CSR вузлами, які приєднуються

Kubeadm забезпечує можливість користувачам у групі system:bootstrappers:kubeadm:default-node-token доступ до API підпису сертифікатів.

Це реалізується створенням ClusterRoleBinding з назвою kubeadm:kubelet-bootstrap між вищезазначеною групою та рольовим доступом RBAC стандартно system:node-bootstrapper.

Налаштування автоматичного схвалення нових bootstrap токенів

Kubeadm забезпечує автоматичне схвалення запитів на підпис сертифікату Bootstrap Token за допомогою контролера csrapprover.

Це реалізується створенням ClusterRoleBinding з назвою kubeadm:node-autoapprove-bootstrap між групою system:bootstrappers:kubeadm:default-node-token та стандартним рольовим доступом system:certificates.k8s.io:certificatesigningrequests:nodeclient.

Роль system:certificates.k8s.io:certificatesigningrequests:nodeclient також має бути створена, надаючи дозвіл POST на шлях /apis/certificates.k8s.io/certificatesigningrequests/nodeclient.

Налаштування ротації сертифікатів вузлів з автоматичним схваленням

Kubeadm забезпечує активацію ротації сертифікатів для вузлів і автоматичне схвалення запитів на підпис сертифікатів для вузлів за допомогою контролера csrapprover.

Це реалізується створенням ClusterRoleBinding з назвою kubeadm:node-autoapprove-certificate-rotation між групою system:nodes та стандартним рольовим доступом system:certificates.k8s.io:certificatesigningrequests:selfnodeclient.

Створення публічного ConfigMap cluster-info

У цій фазі створюється ConfigMap cluster-info у просторі імен kube-public.

Додатково створюється Role та RoleBinding, які надають доступ до ConfigMap неавтентифікованим користувачам (тобто користувачам у RBAC групі system:unauthenticated).

Встановлення надбудов

Kubeadm встановлює внутрішній DNS-сервер і компоненти надбудов kube-proxy через API-сервер.

proxy

Для kube-proxy створюється обліковий запис ServiceAccount у просторі імен kube-system, після чого kube-proxy розгортається як DaemonSet:

  • Облікові дані (ca.crt та token) до панелі управління отримуються з облікового запису ServiceAccount.
  • Місцезнаходження (URL) API-сервера отримується з ConfigMap.
  • Обліковий запис ServiceAccount kube-proxy повʼязується з правами у рольовому доступі ClusterRole system:node-proxier.

DNS

  • Сервіс CoreDNS називається kube-dns. Це зроблено для запобігання будь-яких перерв у роботі, коли користувач переключає DNS кластера з kube-dns на CoreDNS за допомогою методу --config, описаного тут.

  • У просторі імен kube-system створюється обліковий запис ServiceAccount для CoreDNS.

  • Обліковий запис coredns привʼязаний до привілеїв у ClusterRole system:coredns.

У версії Kubernetes 1.21 була видалена підтримка використання kube-dns з kubeadm. Ви можете використовувати CoreDNS з kubeadm, навіть якщо повʼязаний сервіс називається kube-dns.

Внутрішній дизайн фаз kubeadm join

Подібно до kubeadm init, внутрішній робочий процес kubeadm join також складається з послідовності атомарних завдань, що виконуються.

Вони поділені на дві частини: виявлення (щоб вузол довіряв Kubernetes Master) та початкове завантаження TLS (щоб Kubernetes Master довіряв вузлу).

Дивіться Автентифікація за допомогою Bootstrap Tokens або відповідну пропозицію дизайну.

Попередні перевірки

kubeadm виконує набір попередніх перевірок перед початком приєднання, з метою перевірити попередні умови та уникнути поширених проблем запуску кластера.

Зверніть увагу на наступне:

  1. Попередні перевірки kubeadm join є, по суті, підмножиною попередніх перевірок kubeadm init.
  2. Починаючи з версії 1.24, kubeadm використовує crictl для спілкування з усіма відомими CRI точками доступу.
  3. Починаючи з версії 1.9, kubeadm забезпечує підтримку приєднання вузлів, що працюють на Windows; у такому разі пропускаються специфічні для Linux перевірки.
  4. У будь-якому випадку користувач може пропустити певні попередні перевірки (або, врешті-решт, усі попередні перевірки) за допомогою опції --ignore-preflight-errors.

Виявлення інформації про кластер

Є дві основні схеми для виявлення. Перша полягає у використанні спільного токена разом з IP-адресою сервера API. Друга — наданні файлу (який є підмножиною стандартного файлу kubeconfig).

Виявлення спільного токена

Якщо kubeadm join викликається з параметром --discovery-token, використовується виявлення за допомогою токена; у цьому випадку вузол основному отримує сертифікати CA кластера з ConfigMap cluster-info у просторі імен kube-public.

Щоб запобігти атакам типу "особа посередині", вживаються кілька заходів:

  • Спочатку сертифікат CA отримується через небезпечне зʼєднання (це можливо, тому що kubeadm init надає доступ користувачам cluster-info для system:unauthenticated)

  • Потім сертифікат CA проходить наступні кроки перевірки:

    • Базова перевірка: використовуючи ID токена через підпис JWT
    • Перевірка публічного ключа: використовуючи наданий --discovery-token-ca-cert-hash. Це значення доступне у виводі kubeadm init або може бути обчислене за допомогою стандартних інструментів (хеш обчислюється над байтами обʼєкта Subject Public Key Info (SPKI) відповідно до RFC7469). Прапор --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити більше одного публічного ключа.
    • Як додаткова перевірка, сертифікат CA отримується через безпечне зʼєднання і порівнюється з сертифікатом CA, отриманим спочатку

Виявлення файлу/HTTPS

Якщо kubeadm join викликається з параметром --discovery-file, використовується виявлення за допомогою файлу; цей файл може бути локальним файлом або завантаженим через HTTPS URL; у випадку HTTPS, використовується встановлений на хості пакет сертифікатів CA для перевірки зʼєднання.

При виявленні файлу сертифікат CA кластера надається у самому файлі; фактично, файл для виявлення є файлом kubeconfig з встановленими тільки атрибутами server і certificate-authority-data, як описано у референс-документації kubeadm join; коли зʼєднання з кластером встановлено, kubeadm намагається отримати доступ до ConfigMap cluster-info, і якщо він доступний, використовує його.

TLS Bootstrap

Після того, як інформація про кластер відома, записується файл bootstrap-kubelet.conf, що дозволяє kubelet виконати початкове завантаження TLS.

Механізм початкового завантаження TLS використовує спільний токен для тимчасової автентифікації з сервером API Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів.

Запит автоматично затверджується, і операція завершується збереженням файлів ca.crt і kubelet.conf, які використовуються kubelet для приєднання до кластера, тоді як bootstrap-kubelet.conf видаляється.

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 файл<#>.

  • прапорці: Є необовʼязковими. Наприклад, ви можете використовувати прапорці -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, ви можете використовувати наступну команду:

kubectl config set-context --current --namespace=<namespace-name>

Операції

Наступна таблиця містить короткі описи та загальний синтаксис для всіх операцій kubectl:

ОпераціяСинтаксисОпис
alphakubectl alpha SUBCOMMAND [flags]Вивести список доступних команд, які відповідають альфа-функціям, які зазвичай не є активованими у кластерах Kubernetes.
annotatekubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]Додати або оновити анотації одного чи кількох ресурсів.
api-resourceskubectl api-resources [flags]Вивести список доступних ресурсів API.
api-versionskubectl api-versions [flags]Вивести список доступних версій API.
applykubectl apply -f FILENAME [flags]Застосувати зміну конфігурації до ресурсу з файлу або stdin.
attachkubectl attach POD -c CONTAINER [-i] [-t] [flags]Приєднатися до запущеного контейнера для перегляду виводу або взаємодії з контейнером (stdin).
authkubectl auth [flags] [options]Перегляд авторизації.
autoscalekubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]Автоматично масштабувати набір Podʼів, керованих контролером реплікації.
certificatekubectl certificate SUBCOMMAND [options]Змінити ресурси сертифікатів.
cluster-infokubectl cluster-info [flags]Показати інформацію про точки доступу майстра та сервісів в кластері.
completionkubectl completion SHELL [options]Вивести код функції автозавершення оболонки для bash або zsh.
configkubectl config SUBCOMMAND [flags]Змінити файли kubeconfig. Див. окремі команди для отримання деталей.
convertkubectl convert -f FILENAME [options]Конвертувати файли конфігурації між різними версіями API. Приймаються формати YAML та JSON. Примітка — потрібно встановити втулок kubectl-convert.
cordonkubectl cordon NODE [options]Позначити вузол як недоступний для планування.
cpkubectl cp <file-spec-src> <file-spec-dest> [options]Копіювати файли та теки в та з контейнерів.
createkubectl create -f FILENAME [flags]Створити один чи кілька ресурсів з файлу або stdin.
deletekubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags]Видалити ресурси з файлу, stdin або вказати селектори міток, імена, селектори ресурсів або ресурси.
describekubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags]Показати докладний стан одного чи кількох ресурсів.
diffkubectl diff -f FILENAME [flags]Показати розбіжності між файлом або stdin від робочої конфігурації.
drainkubectl drain NODE [options]Звільнити вузол від ресурсів для підготовки його до обслуговування.
editkubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags]Редагувати та оновити визначення одного чи кількох ресурсів на сервері за допомогою типового редактора.
eventskubectl eventsВивести список подій.
execkubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]Виконати команду в контейнері у Podʼі.
explainkubectl explain TYPE [--recursive=false] [flags]Отримати документацію про різні ресурси, такі як Podʼи, вузли, сервіси і т. д.
exposekubectl 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.
getkubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]Вивести список ресурсів.
kustomizekubectl kustomize <dir> [flags] [options]Вивести список ресурсів API, згенерованих з інструкцій у файлі kustomization.yaml. Аргумент повинен бути шляхом до теки, що містить файл, або URL репозиторію git з суфіксом шляху, який вказує на те ж саме відносно кореня репозиторію.
labelkubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]Додати або оновити мітки одного чи кількох ресурсів.
logskubectl logs POD [-c CONTAINER] [--follow] [flags]Вивести логи контейнера у Podʼі.
optionskubectl optionsСписок глобальних параметрів командного рядка, які застосовуються до всіх команд.
patchkubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]Оновити одне чи кілька полів ресурсу за допомогою процесу стратегії обʼєднання патчів.
pluginkubectl plugin [flags] [options]Надає інструменти для взаємодії з втулками.
port-forwardkubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]Переспрямувати один або декілька локальних портів у Pod.
proxykubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]Запустити проксі до сервера API Kubernetes.
replacekubectl replace -f FILENAMEЗамінити ресурс з файлу або stdin.
rolloutkubectl rollout SUBCOMMAND [options]Керувати розгортанням ресурсу. Дійсні типи ресурсів: Deployment, DaemonSet та StatefulSet.
runkubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]Запустити вказаний образ у кластері.
scalekubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]Оновити розмір вказаного контролера реплікації.
setkubectl set SUBCOMMAND [options]Налаштувати ресурси застосунку.
taintkubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]Оновити taint на одному чи декількох вузлах.
topkubectl top (POD | NODE) [flags] [options]Показати використання ресурсів (CPU/Memory/Storage) для Podʼа чи вузла.
uncordonkubectl uncordon NODE [options]Позначити вузол як доступний для планування.
versionkubectl version [--client] [flags]Показати версію Kubernetes, яка працює на клієнті та сервері.
waitkubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options]Експериментально: чекати на певний стан одного чи кількох ресурсів.

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

Типи ресурсів

У наступній таблиці наведено список всіх підтримуваних типів ресурсів та їх скорочених аліасів.

(Цей вивід можна отримати за допомогою kubectl api-resources, він був актуальним на момент Kubernetes 1.25.0)

ІМʼЯСКОРОЧЕННЯВЕРСІЯ APIПРОСТІР ІМЕНТИП
bindingsv1trueBinding
componentstatusescsv1falseComponentStatus
configmapscmv1trueConfigMap
endpointsepv1trueEndpoints
eventsevv1trueEvent
limitrangeslimitsv1trueLimitRange
namespacesnsv1falseNamespace
nodesnov1falseNode
persistentvolumeclaimspvcv1truePersistentVolumeClaim
persistentvolumespvv1falsePersistentVolume
podspov1truePod
podtemplatesv1truePodTemplate
replicationcontrollersrcv1trueReplicationController
resourcequotasquotav1trueResourceQuota
secretsv1trueSecret
serviceaccountssav1trueServiceAccount
servicessvcv1trueService
mutatingwebhookconfigurationsadmissionregistration.k8s.io/v1falseMutatingWebhookConfiguration
validatingwebhookconfigurationsadmissionregistration.k8s.io/v1falseValidatingWebhookConfiguration
customresourcedefinitionscrd,crdsapiextensions.k8s.io/v1falseCustomResourceDefinition
apiservicesapiregistration.k8s.io/v1falseAPIService
controllerrevisionsapps/v1trueControllerRevision
daemonsetsdsapps/v1trueDaemonSet
deploymentsdeployapps/v1trueDeployment
replicasetsrsapps/v1trueReplicaSet
statefulsetsstsapps/v1trueStatefulSet
tokenreviewsauthentication.k8s.io/v1falseTokenReview
localsubjectaccessreviewsauthorization.k8s.io/v1trueLocalSubjectAccessReview
selfsubjectaccessreviewsauthorization.k8s.io/v1falseSelfSubjectAccessReview
selfsubjectrulesreviewsauthorization.k8s.io/v1falseSelfSubjectRulesReview
subjectaccessreviewsauthorization.k8s.io/v1falseSubjectAccessReview
horizontalpodautoscalershpaautoscaling/v2trueHorizontalPodAutoscaler
cronjobscjbatch/v1trueCronJob
jobsbatch/v1trueJob
certificatesigningrequestscsrcertificates.k8s.io/v1falseCertificateSigningRequest
leasescoordination.k8s.io/v1trueLease
endpointslicesdiscovery.k8s.io/v1trueEndpointSlice
eventsevevents.k8s.io/v1trueEvent
flowschemasflowcontrol.apiserver.k8s.io/v1beta2falseFlowSchema
prioritylevelconfigurationsflowcontrol.apiserver.k8s.io/v1beta2falsePriorityLevelConfiguration
ingressclassesnetworking.k8s.io/v1falseIngressClass
ingressesingnetworking.k8s.io/v1trueIngress
networkpoliciesnetpolnetworking.k8s.io/v1trueNetworkPolicy
runtimeclassesnode.k8s.io/v1falseRuntimeClass
poddisruptionbudgetspdbpolicy/v1truePodDisruptionBudget
podsecuritypoliciespsppolicy/v1beta1falsePodSecurityPolicy
clusterrolebindingsrbac.authorization.k8s.io/v1falseClusterRoleBinding
clusterrolesrbac.authorization.k8s.io/v1falseClusterRole
rolebindingsrbac.authorization.k8s.io/v1trueRoleBinding
rolesrbac.authorization.k8s.io/v1trueRole
priorityclassespcscheduling.k8s.io/v1falsePriorityClass
csidriversstorage.k8s.io/v1falseCSIDriver
csinodesstorage.k8s.io/v1falseCSINode
csistoragecapacitiesstorage.k8s.io/v1trueCSIStorageCapacity
storageclassesscstorage.k8s.io/v1falseStorageClass
volumeattachmentsstorage.k8s.io/v1falseVolumeAttachment

Параметри виводу

Використовуйте наступні розділи для отримання інформації про те, як ви можете форматувати або сортувати вивід деяких команд. Докладні відомості щодо команд, які підтримують різні параметри виводу, див. в документації по kubectl.

Форматування виводу

Стандартний формат виводу для всіх команд kubectl – це читабельний текстовий формат. Щоб вивести деталі у вашому терміналі у певному форматі, ви можете додати параметр -o або --output до підтримуваної команди kubectl.

Синтаксис

kubectl [команда] [ТИП] [ІМʼЯ] -o <формат_виводу>

Залежно від операції kubectl, підтримуються наступні формати виводу:

Формат виводуОпис
-o custom-columns=<специфікація>Вивести таблицю, використовуючи розділений комою список власних стовпців.
-o custom-columns-file=<імʼя_файлу>Вивести таблицю, використовуючи шаблон власних стовпців у файлі <імʼя_файлу>.
-o jsonВивести обʼєкт API у форматі JSON.
-o jsonpath=<шаблон>Вивести поля, визначені в виразі jsonpath.
-o jsonpath-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.

Синтаксис

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ʼи, які працюють на вузлі server01
kubectl 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 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
  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/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

Що далі

11.1 - Вступ до kubectl

kubectl — це версія CLI для Kubernetes, яка може виконувати багато різних речей.

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

Набори команд

Більшість команд kubectl зазвичай відносяться до однієї з кількох категорій:

ТипВикористанняОпис
Декларативне управління ресурсамиРозгортання та операційна діяльність (наприклад, GitOps)Декларативне управління ресурсами Kubernetes за допомогою конфігурації ресурсів
Імперативне управління ресурсамиТільки розробкаВиконання команд для управління ресурсами Kubernetes за допомогою аргументів командного рядка та прапорців
Виведення стану робочого навантаженняНалагодженняВиведення інформації про робочі навантаження
Взаємодія з контейнерамиНалагодженняExec, attach, cp, logs
Управління кластеромОперації з кластеромВиведення та блокування вузлів

Декларативне управління застосунками

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

Виведення стану робочих навантажень

Користувачам потрібно переглядати стан робочих навантажень.

  • Виведення підсумкового стану та інформації про ресурси
  • Виведення повного стану та інформації про ресурси
  • Виведення конкретних полів з ресурсів
  • Запит ресурсів, які відповідають міткам

Налагодження робочих навантажень

kubectl підтримує налагодження, надаючи команди для:

  • Виведення логів контейнерів
  • Виведення подій кластера
  • Виконання або приєднання до контейнера
  • Копіювання файлів з контейнерів в кластері у файлову систему користувача

Управління кластером

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

Парадні команди

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

  • Генерування + створення ресурсів таких, як Deployment, StatefulSet, Service, ConfigMap й так далі
  • Встановлення полів ресурсів
  • Редагування (поточних) ресурсів в текстовому редакторі

  1. Див. https://git-scm.com/book/uk/v2/Git-зсередини-Кухонні-та-парадні-команди ↩︎

11.2 - Швидкий довідник kubectl

Ця сторінка містить перелік загальновживаних команд та прапорців kubectl.

Автозавершення команд kubeclt

BASH

source <(kubectl completion bash) # встановлення автозавершення для bash в поточному терміналі, пакунок bash-completion повинен бути встановлений.
echo "source <(kubectl completion bash)" >> ~/.bashrc # додавання автозавершення для bash в профіль bash для постіного використання

Ви також можете використовувати зручне скорочення для kubectl, яке також працює з автозавершенням:

alias k=kubectl
complete -o default -F __start_kubectl k

ZSH

source <(kubectl completion zsh)  # встановлення автозавершення для zsh в поточному терміналі
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # додавання автозавершення для zsh в профіль zsh для постіного використання

FISH

echo 'kubectl completion fish | source' > ~/.config/fish/completions/kubectl.fish && source ~/.config/fish/completions/kubectl.fish

-A замість --all-namespaces

Додавання --all-namespaces трапляється досить часто, тому вам слід знати скорочення для --all-namespaces:

kubectl -A

Контекст та конфігурація kubectl

Встановіть, з яким кластером Kubernetes kubectl спілкується та змінює інформацію про конфігурацію. Див. документацію Автентифікація між кластерами за допомогою kubeconfig для детальної інформації про конфігураційний файл.

kubectl config view # Показати обʼєднані налаштування kubeconfig.

# використовувати декілька файлів kubeconfig одночасно та переглядати обʼєднані конфігурації {#creating-objects}
KUBECONFIG=~/.kube/config:~/.kube/config2 

kubectl config view

# Показати обʼєднані налаштування kubeconfig, необроблені дані сертифікатів та експоновані секрети
kubectl config view --raw

# отримання пароля для користувача e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

# отримання сертифіката для користувача e2e
kubectl config view --raw -o jsonpath='{.users[?(.name == "e2e")].user.client-certificate-data}' | base64 -d

kubectl config view -o jsonpath='{.users[].name}'    # показати першого користувача
kubectl config view -o jsonpath='{.users[*].name}'   # отримати список користувачів
kubectl config get-contexts                          # показати список контекстів
kubectl config get-contexts -o name                  # отримати всі імена контекстів
kubectl config current-context                       # показати поточний контекст
kubectl config use-context my-cluster-name           # встановити стандартний контекст у my-cluster-name

kubectl config set-cluster my-cluster-name           # встановити запис кластера у kubeconfig

# налаштувати URL проксі-сервера для запитів, зроблених цим клієнтом у kubeconfig
kubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url

# додати нового користувача до kubeconf з підтримкою базової автентифікації
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

# постійно зберігати простір імен для всіх наступних команд kubectl у цьому контексті
kubectl config set-context --current --namespace=ggckad-s2

# встановити контекст, використовуючи конкретне імʼя користувача та простір імен
kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce

kubectl config unset users.foo                       # видалити користувача foo

# скорочення для налаштування/показу контексту/простору імен (працює тільки для bash та сумісних з bash оболонок, поточний контекст має бути встановлений перед використанням kn для налаштування простору імен)
alias kx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f'
alias kn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f'

Kubectl apply

apply керує застосунками через файли, що визначають ресурси Kubernetes. Ця команда створює та оновлює ресурси в кластері, виконуючи команду kubectl apply. Це рекомендований спосіб керування застосунками Kubernetes в операційному середовищі. Дивіться Kubectl Book.

Створення обʼєктів

Маніфести Kubernetes можна визначати у форматах YAML або JSON. Можна використовувати розширення файлів .yaml, .yml та .json.

kubectl apply -f ./my-manifest.yaml                 # створити ресурс(и)
kubectl apply -f ./my1.yaml -f ./my2.yaml           # створити з декількох файлів
kubectl apply -f ./dir                              # створити ресурс(и) з усіх манифестів у теці
kubectl apply -f https://example.com/manifest.yaml  # створити ресурс(и) з URL (Примітка: це приклад домену і не містить дійсного манифесту)
kubectl create deployment nginx --image=nginx       # запустити один екземпляо nginx

# створити завдання, яке виводить "Hello World"
kubectl create job hello --image=busybox:1.28 -- echo "Hello World"

# створити CronJob, який виводить "Hello World" кожну хвилину
kubectl create cronjob hello --image=busybox:1.28   --schedule="*/1 * * * *" -- echo "Hello World"

kubectl explain pods                           # отримати документацію для манифестів pod

# створити декілька YAML обʼєктів зі stdin {#creating-objects}
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox:1.28
    args:
    - sleep
    - "1000000"
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep-less
spec:
  containers:
  - name: busybox
    image: busybox:1.28
    args:
    - sleep
    - "1000"
EOF

# створити секрет з декількома ключами
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

Перегляд і пошук ресурсів

# Отримати команди з базовим виводом
kubectl get services                          # Вивід усіх сервісів у просторі імен
kubectl get pods --all-namespaces             # Вивід усіх Podʼів у всіх просторах імен
kubectl get pods -o wide                      # Вивід усіх Podʼів у поточному просторі імен, з детальною інформацією
kubectl get deployment my-dep                 # Вивід конкретного deployment
kubectl get pods                              # Вивід усіх Podʼів у просторі імен
kubectl get pod my-pod -o yaml                # Отримати Pod в фоматі YAML

# Опис команд з докладним виводом
kubectl describe nodes my-node
kubectl describe pods my-pod

# Вивід сервісів, відсортованих за назвою
kubectl get services --sort-by=.metadata.name

# Вивід Podʼів, відсортованих за кількістю перезапусків
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# Вивід PersistentVolumes, відсортованих за ємністю
kubectl get pv --sort-by=.spec.capacity.storage

# Отримати мітки version усіх Podʼів з міткою app=cassandra
kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

# Отримати значення ключа з крапками, напр. 'ca.crt'
kubectl get configmap myconfig \
  -o jsonpath='{.data.ca\.crt}'

# Отримати значення, закодоване у base64, з дефісами замість підкреслень
kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'

# Отримати всі робочі вузли (використовувати селектор для виключення результатів з міткою
# з назвою 'node-role.kubernetes.io/control-plane')
kubectl get node --selector='!node-role.kubernetes.io/control-plane'

# Отримати всі запущені Podʼи у просторі імен
kubectl get pods --field-selector=status.phase=Running

# Отримати ExternalIP усіх вузлів
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# Вивід імен Podʼів, що належать певному RC
# Команда "jq" корисна для перетворень, які занадто складні для jsonpath, її можна знайти на https://jqlang.github.io/jq/
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# Показати мітки для всіх Podʼів (або будь-якого іншого обʼєкта Kubernetes, що підтримує мітки)
kubectl get pods --show-labels

# Перевірити, які вузли готові
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# Перевірити, які вузли готові з custom-columns
kubectl get node -o custom-columns='NODE_NAME:.metadata.name,STATUS:.status.conditions[?(@.type=="Ready")].status'

# Вивести розкодовані секрети без зовнішніх інструментів
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'

# Вивід усіх секретів, які зараз використовуються Podʼом
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

# Вивід всіх containerID initContainer усіх Podʼів
# Корисно при очищенні зупинених контейнерів, уникаючи видалення initContainer.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3

# Вивід подій, відсортованих за часовою позначкою
kubectl get events --sort-by=.metadata.creationTimestamp

# Вивід всіх попереджувальних подій
kubectl events --types=Warning

# Порівняти поточний стан кластера зі станом, в якому б кластер знаходився, якби було застосовано маніфест.
kubectl diff -f ./my-manifest.yaml

# Створити дерево всіх ключів, розділених крапками, що повертаються для вузлів
# Корисно при пошуку ключа у складній вкладеній структурі JSON
kubectl get nodes -o json | jq -c 'paths|join(".")'

# Створити всіх ключів, розділених крапками, що повертаються для Podʼів тощо
kubectl get pods -o json | jq -c 'paths|join(".")'

# Вивести ENV для всіх Podʼів, за умови, що у вас є типовий контейнер для Podʼів, типовий простір імен і підтримка команди `env`.
# Корисно при виконанні будь-якої підтримуваної команди для всіх Podʼів, не тільки `env`
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done

# Отримати субресурс status для deployment
kubectl get deployment nginx-deployment --subresource=status

Оновлення ресурсів

kubectl set image deployment/frontend www=image:v2               # Rolling update контейнерів "www" в deployment "frontend", оновлення образу
kubectl rollout history deployment/frontend                      # Перегляд історії deployment, включаючи ревізію
kubectl rollout undo deployment/frontend                         # Відкат до попереднього deployment
kubectl rollout undo deployment/frontend --to-revision=2         # Відкат до конкретної ревізії
kubectl rollout status -w deployment/frontend                    # Спостереження за статусом rolling update deployment "frontend" до завершення
kubectl rollout restart deployment/frontend                      # Rolling restart deployment "frontend"

cat pod.json | kubectl replace -f -                              # Заміна Pod на основі JSON, переданого через stdin

# Примусова заміна, видалення та повторне створення ресурсу. Це призведе до простою сервісу.
kubectl replace --force -f ./pod.json

# Створення сервісу для реплікованого nginx, який працює на порту 80 і підключається до контейнерів на порту 8000
kubectl expose rc nginx --port=80 --target-port=8000

# Оновлення версії (теґа) образу одноконтейнерного Podʼа до v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

kubectl label pods my-pod new-label=awesome                      # Додавання мітки
kubectl label pods my-pod new-label-                             # Видалення мітки
kubectl label pods my-pod new-label=new-value --overwrite        # Перезапис поточного значення
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Додавання анотації
kubectl annotate pods my-pod icon-url-                           # Видалення анотації
kubectl autoscale deployment foo --min=2 --max=10                # Автомасштабування deployment "foo"

Накладання патчів на ресурси

# Часткове оновлення вузла
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# Оновлення образу контейнера; spec.containers[*].name обовʼязково, тому що це ключ для злиття
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# Оновлення образу контейнера за допомогою json patch з позиційними масивами
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# Вимкнення livenessProbe у deployment за допомогою json patch з позиційними масивами
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

# Додавання нового елементу до позиційного масиву
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

# Оновлення кількості реплік deployment шляхом накладання патчу на його субресурс scale
kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'

Редагування ресурсів

Ви можете змінювати ресурси, використовуючи ваш улюблений редактор:

kubectl edit svc/docker-registry                      # Редагування service з назвою docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # Використання альтернативного рекактора

Масштабування ресурсів

kubectl scale --replicas=3 rs/foo                                 # Масштабування replicaset з назвою 'foo' до 3
kubectl scale --replicas=3 -f foo.yaml                            # Масштабування ресурсу вказанеого у "foo.yaml" до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # Якщо deployment з назвою mysql має поточний розмір — 2, масштабувати mysql до 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Масштабувати кілька контролерів реплікації

Видалення ресурсів

kubectl delete -f ./pod.json                                      # Вилучити Pod використовуючи тип та назву, вказані в pod.json
kubectl delete pod unwanted --now                                 # Вилучити Pod негайно, без його належного завершення
kubectl delete pod,service baz foo                                # Вилучити Podʼи та сервіси з назвами "baz" та "foo"
kubectl delete pods,services -l name=myLabel                      # Вилучити Podʼи та сервіси з міткою name=myLabel
kubectl -n my-ns delete pod,svc --all                             # Вилучити всі Podʼи та сервіси в просторі імен my-ns,
# Вилучити всі Podʼи, що збігаються з шаблоном awk pattern1 або pattern2
kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod

Взаємодія з працюючими Podʼами

kubectl logs my-pod                                 # вивести логи Podʼа (stdout)
kubectl logs -l name=myLabel                        # вивести логи Podʼів з міткою name=myLabel (stdout)
kubectl logs my-pod --previous                      # вивести логи Podʼа (stdout) для попереднього варіанта контейнера
kubectl logs my-pod -c my-container                 # вивести логи контейнера в Podʼі (stdout, випадок з декількома контейнерами)
kubectl logs -l name=myLabel -c my-container        # вивести логи контейнера в Podʼі з міткою name=myLabel (stdout)
kubectl logs my-pod -c my-container --previous      # вивести логи контейнера в Podʼі (stdout, випадок з декількома контейнерами) для попереднього варіанта контейнера
kubectl logs -f my-pod                              # транслювати логи Podʼа (stdout)
kubectl logs -f my-pod -c my-container              # транслювати логи контейнера в Podʼі (stdout, випадок з декількома контейнерами)
kubectl logs -f -l name=myLabel --all-containers    # транслювати всі логи Podʼів з міткою name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox:1.28 -- sh  # Запустити Pod як інтерактивну оболонку
kubectl run nginx --image=nginx -n mynamespace      # Запустити один екземпляр Podʼа nginx в просторі імен mynamespace
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
                                                    # Згенерувати специфікацію для запуску Podʼа nginx і записати її у файл pod.yaml
kubectl attach my-pod -i                            # Підʼєднатися до працюючого контейнера
kubectl port-forward my-pod 5000:6000               # Слухати порт 5000 на локальній машині і пересилати на порт 6000 на Podʼі my-pod
kubectl exec my-pod -- ls /                         # Виконати команду в існуючому Podʼі (випадок з 1 контейнером)
kubectl exec --stdin --tty my-pod -- /bin/sh        # Інтерактивний доступ до оболонки працюючого Podʼа (випадок з 1 контейнером)
kubectl exec my-pod -c my-container -- ls /         # Виконати команду в існуючому Podʼі (випадок з декількома контейнерами)
kubectl debug my-pod -it --image=busybox:1.28       # Створити інтерактивну налагоджувальну сесію в існуючому Podʼі і відразу підʼєднатися до неї
kubectl debug node/my-node -it --image=busybox:1.28 # Створити інтерактивну налагоджувальну сесію на вущлі і відразу підʼєднатися до неї
kubectl top pod                                     # Показати метрики для всіх Podʼів в стандартному просторі імен
kubectl top pod POD_NAME --containers               # Показати метрики для заданого Podʼа та його контейнерів
kubectl top pod POD_NAME --sort-by=cpu              # Показати метрики для заданого Podʼа і сортувати їх за 'cpu' або 'memory'

Копіювання файлів та тек до і з контейнерів

kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir            # Скопіювати локальну теку /tmp/foo_dir до /tmp/bar_dir у віддаленому Podʼі в поточному просторі імен
kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container    # Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Podʼі в конкретному контейнері
kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar       # Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Podʼі в просторі імен my-namespace
kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar       # Скопіювати /tmp/foo з віддаленого Podʼа до /tmp/bar локально

tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar           # Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Podʼі в просторі імен my-namespace
kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar              # Скопіювати /tmp/foo з віддаленого Podʼа до /tmp/bar локально

Взаємодія з Deployment та Service

kubectl logs deploy/my-deployment                         # Вивести логи Podʼа для Deployment (одноконтейнерний випадок)
kubectl logs deploy/my-deployment -c my-container         # Вивести логи Podʼа для Deployment (багатоконтейнерний випадок)

kubectl port-forward svc/my-service 5000                  # Слухати на локальному порту 5000 і переадресувати на порт 5000 на Service бекенд
kubectl port-forward svc/my-service 5000:my-service-port  # Слухати на локальному порту 5000 і переадресувати на порт цільового Service з імʼям <my-service-port>

kubectl port-forward deploy/my-deployment 5000:6000       # Слухати на локальному порту 5000 і переадресувати на порт 6000 на Podʼі, створеному <my-deployment>
kubectl exec deploy/my-deployment -- ls                   # Виконати команду в першому Podʼі та першому контейнері в Deployment (одноконтейнерний або багатоконтейнерний випадок)

Взаємодія з вузлами та кластером

kubectl cordon my-node                                                # Позначити my-node як непридатний до планування
kubectl drain my-node                                                 # Вивільнити my-node для підготовки до обслуговування
kubectl uncordon my-node                                              # Позначити my-node як придатний до планування
kubectl top node                                                      # Показати метрики для всіх вузлів
kubectl top node my-node                                              # Показати метрики для певного вузла
kubectl cluster-info                                                  # Показати адреси майстра та сервісів
kubectl cluster-info dump                                             # Вивести поточний стан кластера у stdout
kubectl cluster-info dump --output-directory=/path/to/cluster-state   # Вивести поточний стан кластера у /path/to/cluster-state

# Переглянути наявні taint, які є на поточних вузлах.
kubectl get nodes -o='custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect'

# Якщо taint з таким ключем та ефектом вже існує, його значення замінюється, як зазначено.
kubectl taint nodes foo dedicated=special-user:NoSchedule

Типи ресурсів

Для виводу всіх підтримуваних типів ресурсів разом з їх короткими іменами, API групою, чи вони просторово обмежені, та kind:

kubectl api-resources

Інші операції для дослідження ресурсів API:

kubectl api-resources --namespaced=true      # Всі ресурси, які просторово обмежені
kubectl api-resources --namespaced=false     # Всі ресурси, які не є просторово обмеженими
kubectl api-resources -o name                # Усі ресурси з простим виведенням (тільки назва ресурсу)
kubectl api-resources -o wide                # Усі ресурси з розширеним виведенням (так званий "wide" формат)
kubectl api-resources --verbs=list,get       # Усі ресурси, які підтримують запити "list" та "get"
kubectl api-resources --api-group=extensions # Усі ресурси в API групі "extensions"

Форматування виводу

Щоб вивести деталі у вікні термінала у певному форматі, додайте прапорець -o (або --output) до відповідної команди kubectl.

Формат виводуОпис
-o=custom-columns=<spec>Вивести таблицю, використовуючи список власних стовпців, розділених комами
-o=custom-columns-file=<filename>Вивести таблицю, використовуючи шаблон власних стовпців з файлу <filename>
-o=go-template=<template>Вивести поля, визначені за допомогою шаблону на основі golang
-o=go-template-file=<filename>Вивести поля, визначені за допомогою шаблону на основі golang з файлу <filename>
-o=jsonВивести API обʼєкт у форматі JSON
-o=jsonpath=<template>Вивести поля, визначені за допомогою виразу jsonpath
-o=jsonpath-file=<filename>Вивести поля, визначені за допомогою виразу jsonpath з файлу <filename>
-o=nameВивести лише назву ресурсу і нічого більше
-o=wideВивести в текстовому форматі з додатковою інформацією, включаючи імʼя вузла для Podʼів
-o=yamlВивести API обʼєкт у форматі YAML

Приклади використання -o=custom-columns:

# Усі образи, що працюють в кластері
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

# Усі образи, що працюють в просторі імен: default, згруповані по Pod
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"

# Усі образи, за винятком "registry.k8s.io/coredns:1.6.2"
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.io/coredns:1.6.2")].image'

# Усі поля metadata незалежно від назви
kubectl get pods -A -o=custom-columns='DATA:metadata.*'

Додаткові приклади можна знайти в документації kubectl reference documentation.

Рівні деталізації виводу та налагодження для kubectl

Деталізація виводу в kubectl контролюється за допомогою прапорця -v або --v, за яким слідує ціле число, що представляє рівень логування. Загальні конвенції щодо логування Kubernetes та повʼязані рівні описані тут.

Рівень деталізаціїОпис
--v=0Загалом корисно, щоб цей рівень завжди був видимим для оператора кластера.
--v=1Прийнятний стандартний рівень логування, якщо вам не потрібна висока деталізація.
--v=2Корисна стабільна інформація про сервіс та важливі повідомлення логу, які можуть корелювати зі значними змінами в системі. Рекомендований стандартний рівень логування для більшості систем.
--v=3Розширена інформація про зміни.
--v=4Рівень логування для налагодження.
--v=5Рівень логування для налагодження з трасуванням.
--v=6Показати запитані ресурси.
--v=7Показати заголовки HTTP-запитів.
--v=8Показати вміст HTTP-запитів.
--v=9Показати вміст HTTP-запитів без обрізання вмісту.

Що далі

11.3 - Довідник kubectl

11.3.1 - kubectl

Огляд

kubectl керує менеджером кластерів Kubernetes.

Докладніше: https://kubernetes.io/docs/reference/kubectl/

kubectl [flags]

Параметри

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

-h, --help

довідка kubectl

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl annotate — Оновлення анотацій ресурсу
  • kubectl api-resources — Вивід підтримуваних ресурсів API на сервері
  • kubectl api-versions — Вивід підтримуваних версій API на сервері у форматі "група/версія"
  • kubectl apply — Застосування конфігурації до ресурсу за іменем файлу або через stdin
  • kubectl attach — Приєднання до запущеного контейнера
  • kubectl auth — Інспектування авторизації
  • kubectl autoscale — Автоматичне масштабування deployment, replica set, stateful set або контролера реплікацій
  • kubectl certificate — Зміна ресурсів сертифікатів
  • kubectl cluster-info — Вивід інформації про кластер
  • kubectl completion — Вивід коду автозавершення оболонки для вказаної оболонки (bash, zsh, fish або powershell)
  • kubectl config — Зміна файлів kubeconfig
  • kubectl cordon — Позначення вузла як незапланованого
  • kubectl cp — Копіювання файлів та тек до контейнерів і з них
  • kubectl create — Створення ресурсу з файлу або через stdin
  • kubectl debug — Створення сеансів налагодження для усунення несправностей навантажень та вузлів
  • kubectl delete — Видалення ресурсів за іменами файлів, через stdin, ресурсів та імен або за селектором ресурсів і міток
  • kubectl describe — Показ деталей конкретного ресурсу або групи ресурсів
  • kubectl diff — Показ різниці між поточною версією та потенційно застосованою версією
  • kubectl drain — Очищення вузла перед технічним обслуговуванням
  • kubectl edit — Редагування ресурсу на сервері
  • kubectl events — Вивід списку подій
  • kubectl exec — Виконання команди в контейнері
  • kubectl explain — Отримання документації для ресурсу
  • kubectl expose — Використання контролера реплікації, service, deployment або pod та експонування його як нового сервіса Kubernetes
  • kubectl get — Показ одного чи кількох ресурсів
  • kubectl kustomize — Побудова цільового kustomization з текуи або URL
  • kubectl label — Оновлення міток ресурсу
  • kubectl logs — Вивід логів для контейнера в Pod
  • kubectl options — Вивід списку прапорців, успадкованих всіма командами
  • kubectl patch — Оновлення полів ресурсу
  • kubectl plugin — Надає утиліти для взаємодії з втулками
  • kubectl port-forward — Перенаправлення одного або декількох локальних портів до Podʼа
  • kubectl proxy — Запуск проксі для сервера API Kubernetes
  • kubectl replace — Заміна ресурсу за іменем файлу або через stdin
  • kubectl rollout — Керування розгортанням ресурсу
  • kubectl run — Запуск певного образу в кластері
  • kubectl scale — Встановлення нового розміру для deployment, replica set або контролера реплікацій
  • kubectl set — Встановлення конкретних функцій для обʼєктів
  • kubectl taint — Оновлення taint на одному або кількох вузлах
  • kubectl top — Показ використання ресурсів (CPU/памʼять)
  • kubectl uncordon — Позначення вузла як придатного для планування
  • kubectl version — Вивід інформації про версію клієнта та сервера
  • kubectl wait — Експериментальна функція: очікування на визначену умову для одного або кількох ресурсів

11.3.2 - kubectl annotate

Огляд

Оновлення анотацій на одному або декількох ресурсах.

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

Спроба створити анотацію, яка вже існує, призведе до невдачі, якщо не вказано --overwrite. Якщо вказано --resource-version і не збігається з поточною версією ресурсу на сервері, виконання команди буде невдалим.

Для отримання повного списку підтримуваних ресурсів скористайтеся kubectl api-resources.

kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

Приклади

# Оновити Pod 'foo' з анотацією 'description' і значенням 'my frontend'
# Якщо ту саму анотацію встановлено кілька разів, буде застосовано лише останнє значення
kubectl annotate pods foo description='my frontend'

# Оновити Pod, ідентифікований за типом і іменем у "pod.json"
kubectl annotate -f pod.json description='my frontend'

# Оновити Pod 'foo' з анотацією 'description' і значенням 'my frontend running nginx', перезаписуючи будь-яке існуюче значення
kubectl annotate --overwrite pods foo description='my frontend running nginx'

# Оновити всі Podʼи в просторі імен
kubectl annotate pods --all description='my frontend running nginx'

# Оновити Pod 'foo' лише у випадку, якщо ресурс не змінювався з версії 1
kubectl annotate pods foo description='my frontend running nginx' --resource-version=1

# Оновити Pod 'foo', видаливши анотацію з назвою 'description', якщо вона існує
# Не потребує прапорця --overwrite
kubectl annotate pods foo description-

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

--allow-missing-template-keys     Типово: true

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

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-annotate"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновлення анотації

-h, --help

довідка annotate

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--list

Якщо true, показувати анотації для даного ресурсу.

--local

Якщо значення true, annotation НЕ буде звертатися до api-server, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite

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

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resource-version string

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

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.3 - kubectl api-resources

Огляд

Виводить підтримувані ресурси API на сервері.

kubectl api-resources [flags]

Приклади

# Вивести підтримувані ресурси API
kubectl api-resources

# Вивести підтримувані ресурси API з більш детальною інформацією
kubectl api-resources -o wide

# Вивести підтримувані ресурси API відсортовані за колонкою
kubectl api-resources --sort-by=name

# Вивести підтримувані ресурси API, які мають простір імен
kubectl api-resources --namespaced=true

# Вивести підтримувані ресурси API, які не мають простору імен
kubectl api-resources --namespaced=false

# Вивести підтримувані ресурси API з конкретною APIGroup
kubectl api-resources --api-group=rbac.authorization.k8s.io

Параметри

--api-group string

Обмеження на ресурси у вказаній групі API.

--cached

Використовувати кешований список ресурсів, якщо він доступний.

--categories strings

Обмеження на ресурси, які належать до вказаних категорій.

-h, --help

довідка api-resources

--namespaced     Типово: true

Якщо false, будуть повернуті ресурси без простору імен, інакше стандартно будуть повернуті ресурси з простором імен.

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки (заголовки стандартно друкуються).

-o, --output string

Формат виводу. Один з: (wide, name).

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Поле може бути як 'name', так і 'kind'.

--verbs strings

Обмежитися ресурсами, які підтримують вказані дієслова.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.4 - kubectl api-versions

Огляд

Виводити підтримувані версії API на сервері у вигляді "група/версія".

kubectl api-versions

Приклади

  # Вивести підтримуванні версії API
  kubectl api-versions

Параметри

-h, --help

довідка api-versions

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.5 - kubectl apply

Огляд

Застосовує конфігурацію до ресурсу за назвою файлу або stdin. Імʼя ресурсу має бути вказано обовʼязково. Ресурс буде створено, якщо його ще не існує. Щоб використовувати 'apply', завжди створюйте ресурс спочатку за допомогою 'apply' або 'create --save-config'.

Приймаються формати JSON і YAML.

Альфа-застереження: функціональність --prune ще не завершена. Не використовуйте, якщо ви не знаєте поточного стану. Див. https://issues.k8s.io/34274.

kubectl apply (-f FILENAME | -k DIRECTORY)

Приклади

# Застосувати конфігурацію з pod.json до Pod
kubectl apply -f ./pod.json

# Застосувати ресурси з теки, що містить kustomization.yaml — наприклад, dir/kustomization.yaml
kubectl apply -k dir/

# Застосувати JSON, що передається через stdin до Pod
cat pod.json | kubectl apply -f -

# Застосувати конфігурацію з усіх файлів, які закінчуються на '.json'
kubectl apply -f '*.json'

# Примітка: --prune все ще знаходиться в альфа-версії
# Застосувати конфігурацію з manifest.yaml, яка відповідає мітці app=nginx і видалити всі інші ресурси, які не знаходяться в файлі і відповідають мітці app=nginx
kubectl apply --prune -f manifest.yaml -l app=nginx

# Застосувати конфігурацію з manifest.yaml і видалити всі інші config map, які не знаходяться в файлі
kubectl apply --prune -f manifest.yaml --all --prune-allowlist=core/v1/ConfigMap

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

--allow-missing-template-keys     Типово: true

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

--cascade string[="background"]     Типово: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Podʼів, створених Replication Controller). Стандартне значення — background.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-client-side-apply"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновлення анотації

--force

Якщо true, негайно видалити ресурси з API і оминути належне видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--force-conflicts

Якщо значення true, серверне застосування (server-side apply) буде примусово вносити зміни всупереч конфліктам.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Ігнорується, якщо значення відʼємне. Встановлюється у 1 для негайного завершення роботи. Може бути встановлене у 0, тільки якщо --force має значення true (примусове видалення).

-h, --help

довідка apply

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--openapi-patch     Типово: true

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

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite     Типово: true

Автоматично вирішувати конфлікти між зміненою та поточною конфігурацією, використовуючи значення зі зміненої конфігурації

--prune

Автоматично видаляти обʼєкти ресурсів, які не зʼявляються у конфігураціях і створюються за допомогою --save-config. Слід використовувати з -l або --all.

--prune-allowlist strings

Замінити список стандартний дозволів (allowlist) <group/version/kind> для --prune

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--server-side

Якщо значення true, apply виконується на сервері, а не на клієнті.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення таймауту залежно від розміру обʼєкта

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--wait

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl apply edit-last-applied — Редагувати останню анотацію last-applied-configuration ресурса/обʼєкта
  • kubectl apply set-last-applied — Встановити анотацію last-applied-configuration на наявному обʼєкті, щоб відповідати вмісту файлу
  • kubectl apply view-last-applied — Переглянути останню анотацію last-applied-configuration ресурса/обʼєкта

11.3.5.1 - kubectl apply edit-last-applied

Огляд

Редагуйте останні анотації last-applied-configuration ресурсів зі стандартного редактора.

Команда edit-last-applied дозволяє безпосередньо редагувати будь-який API-ресурс, який ви можете отримати за допомогою інструментів командного рядка. Вона відкриє редактор, визначений вашими змінними середовища KUBE_EDITOR або EDITOR, або використає стандартний редактор — 'vi' для Linux або 'notepad' для Windows. Ви можете редагувати кілька обʼєктів, але зміни застосовуються поодинці. Команда приймає імена файлів або аргументи командного рядка, але файли, на які ви посилаєтесь, повинні бути збереженими версіями ресурсів.

Стандартний формат — YAML. Для редагування в JSON вкажіть "-o json".

Прапорець --windows-line-endings може бути використано для примусового завершення рядків в стилі Windows, інакше буде використано типовий варіант для вашої операційної системи.

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

kubectl apply edit-last-applied (RESOURCE/NAME | -f FILENAME)

Приклади

# Редагувати анотації last-applied-configuration за типом/імʼям у форматі YAML
kubectl apply edit-last-applied deployment/nginx

# Редагувати анотації last-applied-configuration за файлом у форматі JSON
kubectl apply edit-last-applied -f deploy.yaml -o json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-client-side-apply"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновлення анотації

-h, --help

довідка edit-last-applied

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--windows-line-endings

Стандартно використовується закінчення рядка, притаманне вашій платформі.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl apply — Застосувати конфігурацію до ресурсу за назвою файлу або з stdin

11.3.5.2 - kubectl apply set-last-applied

Огляд

Встановлює останню last-applied-configuration анотацію, встановивши її, щоб відповідати вмісту файлу. Це призводить до того, що last-applied-configuration оновлюється так, ніби 'kubectl apply -f<file> ' було запущено без оновлення будь-яких інших частин обʼєкта.

kubectl apply set-last-applied -f FILENAME

Приклади

# Встановити last-applied-configuration ресурсу, щоб відповідати вмісту файлу
kubectl apply set-last-applied -f deploy.yaml

# Виконати set-last-applied для кожного файлу конфігурації у директорії
kubectl apply set-last-applied -f path/

# Встановити last-applied-configuration ресурсу, щоб відповідати вмісту файлу; створить анотацію, якщо вона ще не існує
kubectl apply set-last-applied -f deploy.yaml --create-annotation=true

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--create-annotation

Створить анотації 'last-applied-configuration', якщо поточні обʼєкти не мають таких анотацій

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, які містять анотації last-applied-configuration

-h, --help

довідка set-last-applied

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl apply — Застосувати конфігурацію до ресурсу за назвою файлу або з stdin

11.3.5.3 - kubectl apply view-last-applied

Огляд

Переглянути останні застосовані конфігурації за типом/іменем або файлом.

Стандартно вивід буде зроблено у stdout у форматі YAML. Ви можете змінити формат виводу за допомогою опції -o.

kubectl apply view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME)

Приклади

# Переглянути анотації last-applied-configuration за типом/імʼям у форматі YAML
kubectl apply view-last-applied deployment/nginx

# Переглянути анотації last-applied-configuration за файлом у форматі JSON
kubectl apply view-last-applied -f deploy.yaml -o json

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що містить анотацію last-applied-configuration

-h, --help

довідка view-last-applied

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string     Типово: "yaml"

Формат виводу. Має буьти одним з (yaml, json)

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl apply — Застосувати конфігурацію до ресурсу за назвою файлу або з stdin

11.3.6 - kubectl attach

Огляд

Приєднатися до процесу, який вже запущено всередині існуючого контейнера.

kubectl attach (POD | TYPE/NAME) -c CONTAINER

Приклади

# Отримати вивід з запущеного Podʼа mypod; використовуйте анотацію 'kubectl.kubernetes.io/default-container'
# для вибору контейнера, до якого потрібно приєднатися, або буде обрано перший контейнер у Podʼі
kubectl attach mypod

# Отримати вивід з контейнера ruby-container з Podʼа mypod
kubectl attach mypod -c ruby-container

# Перемкнутися в режим raw terminal; відправляє stdin в 'bash' у контейнері ruby-container з Podʼа mypod
# і відправляє stdout/stderr з 'bash' назад до клієнта
kubectl attach mypod -c ruby-container -i -t

# Отримати вивід з першого Podʼа replica set з назвою nginx
kubectl attach rs/nginx

Параметри

-c, --container string

Назва контейнера. Якщо не вказано, використовуйте анотацію kubectl.kubernetes.io/default-container для вибору контейнера, який буде приєднано, інакше буде обрано перший контейнер у Pod

-h, --help

довідка attach

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

-q, --quiet

Виводити дані лише з віддаленого сеансу

-i, --stdin

Передайте stdin в контейнер

-t, --tty

Stdin є TTY

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.7 - kubectl auth

Огляд

Перевірка дозволів.

kubectl auth [flags]

Параметри

-h, --help

Довідка auth

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl auth can-i — Перевірити, чи дозволена дія
  • kubectl auth reconcile — Узгоджує правила для обʼєктів ролі RBAC, привʼязки ролей, кластерної ролі та привʼязки кластерної ролі
  • kubectl auth whoami — Експериментально: Перевірити атрибути власного субʼєкта

11.3.7.1 - kubectl auth can-i

Огляд

Перевіряє, чи дозволена дія.

VERB — дієслово API Kubernetes, таке як 'get', 'list', 'watch', 'delete' тощо. TYPE — це ресурс Kubernetes. Скорочення та групи будуть розпізнані. NONRESOURCEURL — часткова URL-адреса, яка починається з "/". NAME — назва певного ресурсу Kubernetes. Ця команда чудово поєднується з імпровізацією. Дивіться глобальний прапорець --as.

kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]

Приклади

# Перевірити, чи можу я створювати Podʼи в будь-якому просторі імен
kubectl auth can-i create pods --all-namespaces

# Перевірити, чи можу я переглядати списки deployment у моєму поточному просторі імен
kubectl auth can-i list deployments.apps

# Перевірити, чи може служюовий обліковий запис "foo" у просторі імен "dev" переглядати перелік Podʼів
# у просторі імен "prod"
# Ви повинні мати дозвіл на використання імперсонації для глобальної опції "--as"
kubectl auth can-i list pods --as=system:serviceaccount:dev:foo -n prod

# Перевірити, чи можу я виконувати всі дії в моєму поточному просторі імен ("*" означає все)
kubectl auth can-i '*' '*'

# Перевірити, чи можу я отримати завдання з назвою "bar" у просторі імен "foo"
kubectl auth can-i list jobs.batch/bar -n foo

# Перевірити, чи можу я читати логи Podʼів
kubectl auth can-i get pods --subresource=log

# Перевірити, чи можу я отримати доступ до URL /logs/
kubectl auth can-i get /logs/

# Перевірити, чи можу я затвердити certificates.k8s.io
kubectl auth can-i approve certificates.k8s.io

# Переглянути всі дозволені дії в просторі імен "foo"
kubectl auth can-i --list --namespace=foo

Параметри

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

-h, --help

Довідка can-i

--list

Якщо true, виводить усі дозволені дії.

--no-headers

Якщо true, виводить дозволені дії без заголовків

-q, --quiet

Якщо true, заборонити вивід і просто повернути код результату.

--subresource string

SubResource, такі як pod/log або deployment/scale

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.7.2 - kubectl auth reconcile

Огляд

Узгодження правил для ролі RBAC, привʼязки ролі, ролі кластера та обʼєктів привʼязки ролі кластера.

Створюються відсутні обʼєкти, а для обʼєктів простору імен створюється відповідний простір імен, якщо потрібно.

Наявні ролі буде оновлено з урахуванням дозволів вхідних обʼєктів і вилучено зайві дозволи, якщо вказано --remove-extra-permissions.

Існуючі привʼязки буде оновлено до обʼєктів вхідних даних і вилучено зайві обʼєкти, якщо вказано --remove-extra-subjects.

Це бажано застосовувати для ресурсів RBAC, щоб забезпечити семантично усвідомлене обʼєднання правил і обʼєктів.

kubectl auth reconcile -f FILENAME

Приклади

# Узгодження ресурсів RBAC з файлу
kubectl auth reconcile -f my-rbac-rules.yaml

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для узгодження

-h, --help

Довідка reconcile

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--remove-extra-permissions

Якщо true, видаляє зайві дозволи, додані до ролей

--remove-extra-subjects

Якщо true, видаляє зайвих субʼєктів, доданих до rolebindings

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.7.3 - kubectl auth whoami

Огляд

Експериментально: Перевірте, хто ви і які у вас атрибути (групи, додаткові).

Ця команда корисна для ознайомлення з поточними атрибутами користувача, особливо якщо у кластері Kubernacle увімкнено динамічну автентифікацію, наприклад, вебхук, проксі-авторизацію або OIDC-провайдер, увімкнено в кластері Kubernetes.

kubectl auth whoami

Приклади

# Отримати атрибути вашого субʼєкта
kubectl auth whoami

# Отримати атрибути вашого субʼєкта у форматі JSON
kubectl auth whoami -o json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-h, --help

Довідка whoami

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.8 - kubectl autoscale

Огляд

Створює автомасштабувальник, який автоматично вибирає і встановлює кількість Podʼів, що запускаються в кластері Kubernetes.

Шукає deployment, replica set, stateful set або контролер реплікації за назвою і створює автомасштабувальник, який використовує даний ресурс як зразок. Автомасштабувальник може автоматично збільшувати або зменшувати кількість розгорнутих у системі Podʼів за потребою.

kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU]

Приклади

# Автоматично масштабувати deployment "foo" з кількістю Podʼів від 2 до 10, 
# цільове використання CPU не вказано, тому буде використано стандартну 
# політику автосмасштабування
kubectl autoscale deployment foo --min=2 --max=10

# Автоматично масштабувати контролер реплікації "foo" з кількістю Podʼів від 
# 1 до 5, цільове використання CPU на рівні 80%
kubectl autoscale rc foo --max=5 --cpu-percent=80

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--cpu-percent int32     Типово: -1

Цільове середнє використання CPU (представлене у відсотках від запитуваного CPU) для всіх Podʼів. Якщо він не вказаний або відʼємний, буде використано стандартну політику автомасштабування.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-autoscale"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для автомасштабування

-h, --help

Довідка autoscale

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--max int32     Типово: -1

Верхня межа для кількості Podʼів, яку може встановити автомасштабування. Обовʼязково.

--min int32     Типово: -1

Нижня межа для кількості Podʼів, яка може бути встановлена автомасштабуванням. Якщо не вказано або значення відʼємне, сервер застосує стандартне значення.

--name string

Імʼя для новоствореного обʼєкта. Якщо не вказано, буде використано імʼя вхідного ресурсу.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl - kubectl керує менеджером кластерів Kubernetes

11.3.9 - kubectl certificate

Огляд

Зміна ресурсів сертифікатів.

kubectl certificate SUBCOMMAND

Параметри

-h, --help

Довідка certificate

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl certificate approve — Схвалення запиту на підписання сертифіката
  • kubectl certificate deny — Відхилення запиту на підписання сертифіката

11.3.9.1 - kubectl certificate approve

Огляд

Схвалення запиту на підписання сертифіката.

kubectl certificate approve дозволяє адміністратору кластера затвердити запит на підписання сертифіката (CSR). Ця дія вказує контролеру підпису сертифікатів видати сертифікат запитувачу з атрибутами, вказаними у CSR.

ЗАСТЕРЕЖЕННЯ: Залежно від запитуваних атрибутів, виданий сертифікат потенційно може надати заявнику доступ до ресурсів кластера або автентифікацію в якості запитуваного облікового запису. Перш ніж затверджувати CSR, переконайтеся, що ви розумієте, що може робити підписаний сертифікат.

kubectl certificate approve (-f FILENAME | NAME)

Приклади

# Схвалити CSR 'csr-sqgzp'
kubectl certificate approve csr-sqgzp

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновленння

--force

Оновіть CSR, навіть якщо його вже затверджено.

-h, --help

Довідка approve

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.9.2 - kubectl certificate deny

Огляд

Відхилення запиту на підписання сертифіката.

kubectl certificate deny дозволяє адміністратору кластера відхилити запит на підписання сертифіката (CSR). Ця дія вказує контролеру підписання сертифікатів не видавати сертифікат запитувачу.

kubectl certificate deny (-f FILENAME | NAME)

Приклади

# Відхилити CSR 'csr-sqgzp'
kubectl certificate deny csr-sqgzp

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновленння

--force

Оновіть CSR, навіть якщо його вже відхилено.

-h, --help

Довідка deny

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.10 - kubectl cluster-info

Огляд

Виведіть адреси панелі управління та сервісів з міткою kubernetes.io/cluster-service=true. Для подальшого налагодження та діагностики проблем кластера використовуйте 'kubectl cluster-info dump'.

kubectl cluster-info [flags]

Приклади

# Вивести адресу панелі управління та сервісів кластера
kubectl cluster-info

Параметри

-h, --help

Довідка cluster-info

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl cluster-info dump — створення дампу необхідної інформації для налагодження та діагностики

11.3.10.1 - kubectl cluster-info dump

Огляд

Виведення інформації про кластер, придатної для налагодження та діагностики проблем кластера. Стандартно все виводиться до stdout. За бажанням ви можете вказати теку за допомогою --output-directory. Якщо ви вкажете теку, Kubernetes створить набір файлів у цій теці. Типово команда виводить дані лише у поточному просторі імен та просторі імен "kube-system", але ви можете перемикнутися на інший простір імен за допомогою прапорця --namespaces або вказати --all-namespaces для виводу даних з усіх просторів імен.

Команда також виводить логи усіх pods у кластері; ці логи виводяться до різних тек, залежно від простору імен та назви pod.

kubectl cluster-info dump [flags]

Приклади

# Вивести поточний стан кластера до stdout
kubectl cluster-info dump

# Вивести поточний стан кластера до /path/to/cluster-state
kubectl cluster-info dump --output-directory=/path/to/cluster-state

# Вивести всі простори імен до stdout
kubectl cluster-info dump --all-namespaces

# Вивести набір просторів імен до /path/to/cluster-state
kubectl cluster-info dump --namespaces default,kube-system --output-directory=/path/to/cluster-state

Параметри

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-h, --help

Довідка dump

--namespaces strings

Список просторів імен для дампа через кому.

-o, --output string     Типово: "json"

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--output-directory string

Куди виводити файли. Якщо порожньо або '-' використовує stdout, інакше створює ієрархію тек у цій теці

--pod-running-timeout duration     Типово: 20s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.11 - kubectl completion

Огляд

Вивести код завершення команд для вказаного командного інтерпретатора (bash, zsh, fish або powershell). Щоб забезпечити інтерактивне завершення команд kubectl, код оболонки слід опрацювати. Це можна зробити, отримавши його з .bash_profile.

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

для macOS:
https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#enable-shell-autocompletion
для linux:
https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#enable-shell-autocompletion
для windows:
https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/#enable-shell-autocompletion

Примітка для користувачів zsh: [1] завершення zsh підтримуються лише у версіях zsh >= 5.2.

kubectl completion SHELL

Приклади

# Встановлення bash completion на macOS за допомогою homebrew
## Якщо використовується Bash 3.2, включений в macOS
brew install bash-completion
## або, якщо використовується Bash 4.1+
brew install bash-completion@2
## Якщо kubectl встановлено через homebrew, це повинно почати працювати негайно
## Якщо ви встановили іншими способами, можливо, вам потрібно додати completion до вашої теки completion
kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl

# Встановлення bash completion на Linux
## Якщо bash-completion не встановлено на Linux, встановіть пакет 'bash-completion'
## через менеджер пакетів вашого дистрибутива.
## Завантажте код завершення kubectl для bash в поточну оболонку
source <(kubectl completion bash)
## Запишіть код завершення bash у файл і підключіть його з .bash_profile
kubectl completion bash > ~/.kube/completion.bash.inc
printf "
# kubectl shell completion
source '$HOME/.kube/completion.bash.inc'
" >> $HOME/.bash_profile
source $HOME/.bash_profile

# Завантажте код завершення kubectl для zsh[1] в поточну оболонку
source <(kubectl completion zsh)
# Налаштуйте код завершення kubectl для zsh[1], щоб автоматично завантажуватися при запуску
kubectl completion zsh > "${fpath[1]}/_kubectl"

# Завантажте код завершення kubectl для fish[2] в поточну оболонку
kubectl completion fish | source
# Щоб завантажити завершення для кожної сесії, виконайте один раз:
kubectl completion fish > ~/.config/fish/completions/kubectl.fish

# Завантажте код завершення kubectl для powershell в поточну оболонку
kubectl completion powershell | Out-String | Invoke-Expression
# Налаштуйте код завершення kubectl для powershell, щоб запускатися при старті
## Збережіть код завершення в сценарій і виконайте в профілі
kubectl completion powershell > $HOME\.kube\completion.ps1
Add-Content $PROFILE "$HOME\.kube\completion.ps1"
## Виконайте код завершення в профілі
Add-Content $PROFILE "if (Get-Command kubectl -ErrorAction SilentlyContinue) {
kubectl completion powershell | Out-String | Invoke-Expression
}"
## Додайте код завершення безпосередньо в сценарій $PROFILE
kubectl completion powershell >> $PROFILE

Параметри

-h, --help

Довідник completion

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.12 - kubectl config

Огляд

Змінюйте файли kubeconfig за допомогою субкоманд на кшталт "kubectl config set current-context my-context".

Порядок завантаження відповідає наступним правилам:

  1. Якщо встановлено прапорець --kubeconfig, то завантажується лише цей файл. Прапорець може бути встановлений лише один раз і злиття не відбувається.
  2. Якщо встановлено змінну середовища $KUBECONFIG, то вона використовується як список шляхів (звичайні правила розмежування шляхів у вашій системі). Ці шляхи обʼєднуються. Коли значення змінюється, воно змінюється у файлі, який визначає строфу. Коли значення створюється, воно створюється у першому існуючому файлі. Якщо у ланцюжку не існує жодного файлу, то створюється останній файл у списку.
  3. В іншому випадку використовується ${HOME}/.kube/config і злиття не відбувається.
kubectl config SUBCOMMAND

Параметри

-h, —-help

Довідник config

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, —-namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, —-server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, —-version=raw виводить інформацію про версію та завершує роботу; —-version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.1 - kubectl config current-context

Огляд

Показ поточного контексту.

kubectl config current-context [flags]

Приклади

# Показ поточного контексту
kubectl config current-context

Параметри

-h, --help

Довідка current-context

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.2 - kubectl config delete-cluster

Огляд

Видалити вказаний кластер з kubeconfig.

kubectl config delete-cluster NAME

Приклади

# Видалити кластер minikube з kubeconfig
kubectl config delete-cluster minikube
-h, --help

Довідка delete-cluster

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.3 - kubectl config delete-context

Огляд

Видалити вказаний контекст з kubeconfig.

kubectl config delete-context NAME

Приклади

# Видалити контекст для кластера minikube
kubectl config delete-context minikube

Параметри

-h, --help

Довідка delete-context

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.4 - kubectl config delete-user

Огляд

Видалити вказаного користувача з kubeconfig.

kubectl config delete-user NAME

Приклади

# Видалити користувача minikube
kubectl config delete-user minikube

Параметри

-h, --help

Довідка delete-user

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.5 - kubectl config get-clusters

Огляд

Показати кластери, визначені в kubeconfig.

kubectl config get-clusters [flags]

Приклади

# Вивести перелік кластерів, які відомі kubectl
kubectl config get-clusters

Параметри

-h, --help

Довідка get-clusters

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.6 - kubectl config get-contexts

Огляд

Показати один або декілька контекстів з файлу kubeconfig.

kubectl config get-contexts [(-o|--output=)name)]

Приклади

# Показати перелік всіх контекстів з файлу kubeconfig
kubectl config get-contexts

# Показати опис одного контексту з файлу kubeconfig
kubectl config get-contexts my-context

Параметри

-h, --help

Довідка get-contexts

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки (заголовки стандартно друкуються).

-o, --output string

Формат виводу. Один з: (name).

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.7 - kubectl config get-users

Огляд

Показує користувачів, визначених у kubeconfig.

kubectl config get-users [flags]

Приклади

# Перелік користувачів, відомих kubectl
kubectl config get-users

Параметри

-h, --help

Довідка get-users

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.8 - kubectl config rename-context

Огляд

Перейменовує контекст з файлу kubeconfig.

CONTEXT_NAME — назва контексту, яку ви хочете змінити.

NEW_NAME — нова назва, яку ви хочете встановити.

Примітка: Якщо контекст, який перейменовується, є "поточним контекстом", це поле також буде оновлено.

kubectl config rename-context CONTEXT_NAME NEW_NAME

Приклади

# Перейменуйте контекст 'old-name' на 'new-name' у вашому файлі kubeconfig
kubectl config rename-context old-name new-name

Параметри

-h, --help

Довідка rename-context

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.9 - kubectl config set

Огляд

Встановлює індивідуальне значення у файлі kubeconfig.

PROPERTY_NAME — це імʼя, розділене крапками, де кожен токен представляє або імʼя атрибута, або ключ map. Ключі map можуть не містити крапок.

PROPERTY_VALUE — нове значення, яке ви хочете встановити. Двійкові поля, такі як 'certificate-authority-data', очікують рядок у кодуванні base64, якщо не використовується прапорець --set-raw-bytes.

Якщо вказати імʼя атрибута, яке вже існує, нові поля буде додано до наявних значень.

kubectl config set PROPERTY_NAME PROPERTY_VALUE

Приклади

# Встановити поле server для кластера my-cluster на https://1.2.3.4
kubectl config set clusters.my-cluster.server https://1.2.3.4

# Встановити поле certificate-authority-data для кластера my-cluster
kubectl config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

# Встановити поле cluster в контексті my-context на my-cluster
kubectl config set contexts.my-context.cluster my-cluster

# Встановити поле client-key-data для користувача cluster-admin з використанням опції --set-raw-bytes
kubectl config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

Параметри

-h, --help

Довідка set

--set-raw-bytes tristate[=true]

При записі []byte PROPERTY_VALUE, записувати заданий рядок так як є, без декодування base64.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.10 - kubectl config set-cluster

Огляд

Встановлює запис кластера у kubeconfig.

Якщо вказати назву, яка вже існує, нові поля буде обʼєднано з наявними значеннями для цих полів.

kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true] [--tls-server-name=example.com]

Приклади

# Встановити тільки поле server для запису кластера e2e без змін інших значень
kubectl config set-cluster e2e --server=https://1.2.3.4

# Вбудувати дані CA для запису кластера e2e
kubectl config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

# Вимкнути перевірку сертифікатів для запису кластера e2e
kubectl config set-cluster e2e --insecure-skip-tls-verify=true

# Встановити власне імʼя сервера TLS для перевірки для запису кластера e2e
kubectl config set-cluster e2e --tls-server-name=my-cluster-name

# Встановити URL проксі для запису кластера e2e
kubectl config set-cluster e2e --proxy-url=https://1.2.3.4

Параметри

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--embed-certs tristate[=true]

embed-certs для запису кластера в kubeconfig

-h, --help

Довідка set-cluster

--insecure-skip-tls-verify tristate[=true]

insecure-skip-tls-verify для запису кластера в kubeconfig

--proxy-url string

proxy-url для запису кластера в kubeconfig

--server string

server для запису кластера в kubeconfig

--tls-server-name string

tls-server-name ля запису кластера в kubeconfig

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.11 - kubectl config set-context

Огляд

Встановлює запис контексту у kubeconfig.

Якщо вказати назву, яка вже існує, нові поля буде обʼєднано з наявними значеннями для цих полів.

kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]

Приклади

# Встановіть поле користувача у записі контексту gce, не змінюючи інших значень
kubectl config set-context gce --user=cluster-admin

Параметри

--cluster string

cluster для запису контексту в kubeconfig

--current

Змінити поточний контекст

-h, --help

Довідка set-context

--namespace string

namespace для запису контексту в kubeconfig

--user string

user для запису контексту в kubeconfig

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.12 - kubectl config set-credentials

Огляд

Задайте запис user у kubeconfig.

Якщо вказати імʼя, яке вже існує, нові поля буде обʼєднано з наявними значеннями.

Прапорці клієнтського сертифіката:
--client-certificate=certfile --client-key=keyfile
Прапорці токенів на предʼявника:
--token=bearer_token
Базові прапорці авторизації:
--username=базовий_користувач --password=базовий_пароль

Токен на предʼявника та базова авторизація є взаємозаперечними.

kubectl config set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [--password=basic_password] [--auth-provider=provider_name] [--auth-provider-arg=key=value] [--exec-command=exec_command] [--exec-api-version=exec_api_version] [--exec-arg=arg] [--exec-env=key=value]

Приклади

# Встановити тільки поле "client-key" для запису "cluster-admin"
# без змін інших значень
kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key

# Встановити базову автентифікацію для запису "cluster-admin"
kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

# Вбудувати дані сертифіката клієнта для запису "cluster-admin"
kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

# Увімкнути провайдера автентифікації Google Compute Platform для запису "cluster-admin"
kubectl config set-credentials cluster-admin --auth-provider=gcp

# Увімкнути провайдера автентифікації OpenID Connect для запису "cluster-admin" з додатковими аргументами
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

# Видалити значення конфігурації "client-secret" для провайдера автентифікації OpenID Connect для запису "cluster-admin"
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

# Увімкнути новий втулок автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

# Увімкнути новий втулок автентифікації exec для запису "cluster-admin" з інтерактивним режимом
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1 --exec-interactive-mode=Never

# Визначити нові аргументи для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

# Створити або оновити змінні середовища для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

# Видалити змінні середовища для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-env=var-to-remove-

Параметри

--auth-provider string

Провайдер авторизації/автентифікації для запису користувача у kubeconfig

--auth-provider-arg strings

аргументи 'key=value' для провайдера авторизації/автентифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для запису користувача у kubeconfig

--client-key string

Шлях до файлу ключа клієнта для запису користувача у kubeconfig

--embed-certs tristate[=true]

Додати клієнтський сертифікат/ключ для входу користувача у kubeconfig

--exec-api-version string

Версія API втулка exec credential для запису користувача у kubeconfig

--exec-arg strings

Нові аргументи команди втулка exec credential для запису користувача у kubeconfig

--exec-command string

Команди втулка exec credential для запису користувача у kubeconfig

--exec-env strings

'key=value' значеня зміних оточення для втулка exec credential

--exec-interactive-mode string

Режим InteractiveMode втулка exec credentials для запису користувача у kubeconfig

--exec-provide-cluster-info tristate[=true]

ProvideClusterInfo втулка exec credentials для запису користувача у kubeconfig

-h, --help

Довідка set-credentials

--password string

Пароль для запису користувача у kubeconfig

--token string

Токен для запису користувача у kubeconfig

--username string

Імʼя користувачадля запису користувача у kubeconfig

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.13 - kubectl config unset

Огляд

Скинути окреме значення у файлі kubeconfig.

PROPERTY_NAME — це імʼя, розділене крапками, де кожен токен представляє або імʼя атрибута, або ключ map. Ключі map можуть не містити крапок.

kubectl config unset PROPERTY_NAME

Приклади

# Видалити поточний контекст
kubectl config unset current-context

# Видалити простір імен у контексті foo
kubectl config unset contexts.foo.namespace

Параметри

-h, --help

Довідка unset

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.14 - kubectl config use-context

Огляд

Встановлює current-context у файлі kubeconfig.

kubectl config use-context CONTEXT_NAME

Приклади

# Використання контексту для кластера minikube
kubectl config use-context minikube

Параметри

-h, --help

Довідка use-context

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.12.15 - kubectl config view

Огляд

Показує обʼєднану конфігурацію kubeconfig або вказаний файл kubeconfig.

Ви можете використовувати --output jsonpath={...} для вибору конкретних полів конфігурації.

kubectl config view [options]

Приклади

# Показати обʼєднані налаштування kubeconfig
kubectl config view

# Показати обʼєднані налаштування kubeconfig, необроблені дані сертифіката та показати секрети
kubectl config view --raw

# Отримати пароль для користувача e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--flatten

Спростити отриманий файл kubeconfig до окремого вихідного файлу (корисно для створення переносних файлів kubeconfig)

-h, --help

Довідка view

--merge tristate[=true]     Типово: true

Обʼєднати повну ієрархію файлів kubeconfig

--minify

Вилучити з виводу всю інформацію, яка не використовується в current-context

-o, --output string     Типово: "json"

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--raw

Показувати необроблені байт-дані та конфіденційні дані

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.13 - kubectl cordon

Огляд

Позначає вузол як не придатний для планування.

kubectl cordon NODE

# Позначити вузол "foo" як не придатний для планування
kubectl cordon foo

Параметри

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-h, --help

Довідка cordon

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.14 - kubectl cp

Огляд

Копіювання файлів і тек до контейнерів та з них.

kubectl cp <file-spec-src> <file-spec-dest>

Приклади

# !!!Увага!!!
# Вимагає наявності двійкового файлу 'tar' у вашому контейнері.
# Якщо 'tar' відсутній, 'kubectl cp' не вдасться виконати.
#
# Для розширених випадків використання, таких як символічні посилання, розширення
# шаблонів або збереження режиму файлу, розгляньте можливість використання 'kubectl exec'.

# Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Pod в просторі імен <some-namespace>
tar cf - /tmp/foo | kubectl exec -i -n <some-namespace> <some-pod> -- tar xf - -C /tmp/bar

# Скопіювати /tmp/foo з віддаленого Pod до /tmp/bar локально
kubectl exec -n <some-namespace> <some-pod> -- tar cf - /tmp/foo | tar xf - -C /tmp/bar

# Скопіювати локальну теку /tmp/foo_dir до /tmp/bar_dir у віддаленому Pod в стандартному просторі імен
kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir

# Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Pod у конкретному контейнері
kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

# Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Pod в просторі імен <some-namespace>
kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar

# Скопіювати /tmp/foo з віддаленого Pod до /tmp/bar локально
kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar

Параметри

-c, --container string

Назва контейнера. Якщо не вказано, використовуйте анотацію kubectl.kubernetes.io/default-container для вибору контейнера, який буде приєднано, інакше буде обрано перший контейнер у Pod

-h, --help

Довідка cp

--no-preserve

Права власності та дозволи на скопійований файл/теку не будуть збережені в контейнері

--retries int

Вказати кількість спроб для завершення операції копіювання з контейнера. Вкажіть 0 для вимкнення або будь-яке відʼємне значення для нескінченної кількості спроб. Стандартне значення — 0 (без повторних спроб).

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.15 - kubectl create

Огляд

Створити ресурс з файлу або з stdin.

Приймаються формати JSON та YAML.

kubectl create -f FILENAME

Приклади

# Створити Pod з використанням даних з pod.json
kubectl create -f ./pod.json

# Створити Pod на основі JSON, переданого у стандартний ввід
cat pod.json | kubectl create -f -

# Редагувати дані у registry.yaml у форматі JSON, а потім створити ресурс з використанням відредагованих даних
kubectl create -f registry.yaml --edit -o json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--edit

Відредагувати ресурс API перед створенням

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що використовуються для створення ресурсу

-h, --help

Довідка create

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--raw string

Необроблений URI для POST на сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

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

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--windows-line-endings

Має значення лише якщо --edit=true. Стандартно використовується закінчення рядка, притаманне вашій платформі.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.15.1 - kubectl create clusterrole

Огляд

Створення кластерної ролі.

kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run=server|client|none]

Приклади

# Створити кластерну роль з назвою "pod-reader", яка дозволяє користувачу виконувати "get", "watch" та "list" для Podʼів
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

# Створити кластерну роль з назвою "pod-reader" із вказаними іменами ресурсів
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

# Створити кластерну роль з назвою "foo" із вказаною API Group
kubectl create clusterrole foo --verb=get,list,watch --resource=rs.apps

# Створити кластерну роль з назвою "foo" із вказаним субресурсом
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

# Створити кластерну роль з назвою "foo" із вказаним NonResourceURL
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*

# Створити кластерну роль з назвою "monitoring" із вказаним правилом агрегації
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

Параметри

--aggregation-rule <пари 'ключ=значення', розділені комами>

Селектор міток агрегації для обʼєднання ClusterRoles.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка clusterrole

--non-resource-url strings

Частковий URL, до якого користувач повинен мати доступ.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--resource strings

Ресурс, до якого застосовується правило

--resource-name strings

Ресурс у білому списку, до якого застосовується правило, повторіть цей прапорець для кожного елемента

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--verb strings

Дієслово, яке застосовується до ресурсів, що містяться в правилі

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.2 - kubectl create clusterrolebinding

Огляд

Створення привʼязки кластерної ролі для певної кластерної ролі.

kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Створити привʼязування кластерної ролі для user1, user2 та group1, використовуючи кластерну роль cluster-admin
kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--clusterrole string

ClusterRole на яку повинна посилатися привʼязка ClusterRoleBinding

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--group strings

Групи для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кілька груп.

-h, --help

Довідка clusterrolebinding

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--serviceaccount strings

Службові облікові записи для привʼязки до кластерної ролі, у форматі <простір імен>:<імʼя>. Прапорець можна повторювати для додавання декількох службових облікових записів.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--user strings

Імена користувачів для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кількох користувачів.

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.3 - kubectl create configmap

Огляд

Створює ConfigMap на основі файлу, теки або вказаного літерального значення.

Один ConfigMap може містити одну або декілька пар ключ/значення.

При створенні ConfigMap на основі файлу, стандартним значенням ключа буде імʼя файлу, а значенням — його вміст. Якщо назва файлу є невірним ключем, ви можете вказати альтернативний ключ.

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

kubectl create configmap NAME [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]

Приклади

# Створити новий ConfigMap з назвою my-config на основі теки bar
kubectl create configmap my-config --from-file=path/to/bar

# Створити новий ConfigMap з назвою my-config із вказаними ключами замість імен файлів на диску
kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt

# Створити новий ConfigMap з назвою my-config із ключами key1=config1 і key2=config2
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

# Створити новий ConfigMap з назвою my-config із пар ключ=значення у файлі
kubectl create configmap my-config --from-file=path/to/bar

# Створити новий ConfigMap з назвою my-config із файлу зі змінними середовища
kubectl create configmap my-config --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш configmap до назви configmap.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from-env-file strings

Вкажіть шлях до файлу для отримання рядків з парами key=val для створення configmap.

--from-file strings

Файл ключа можна вказати за допомогою шляху до файлу, у цьому випадку імʼя файлу буде використано як ключ configmap, або за допомогою ключа і шляху до файлу, у цьому випадку буде використано заданий ключ. Якщо вказати теку, буде виконано ітерацію для кожного названого файлу у цій теці, імʼя якого є допустимим ключем configmap.

--from-literal strings

Вкажіть ключ і літеральне значення для вставки в configmap (тобто mykey=somevalue)

-h, --help

Довідка configmap

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.4 - kubectl create cronjob

Огляд

Створіть завдання cron із зазначеним імʼям.

kubectl create cronjob NAME --image=image --schedule='0/5 * * * ?' -- [COMMAND] [args...] [flags]

Приклади

# Створити крон-завдання
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *"

# Створити крон-завдання з командою
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка cronjob

--image string

Назва образу контейнера для запуску.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--restart string

Політика перезапуску job. Підтримувані значення: OnFailure, Never

--save-config

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

--schedule string

Розклад у форматі Cron, за яким має виконуватися завдання.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.5 - kubectl create deployment

Огляд

Створює deployment із зазначеним іменем.

kubectl create deployment NAME --image=image -- [COMMAND] [args...]

Приклади

# Створити deployment з назвою my-dep, що використовує образ busybox
kubectl create deployment my-dep --image=busybox

# Створити deployment з командою
kubectl create deployment my-dep --image=busybox -- date

# Створити deployment з назвою my-dep, що використовує образ nginx з 3 репліками
kubectl create deployment my-dep --image=nginx --replicas=3

# Створити deployment з назвою my-dep, що використовує образ busybox і відкриває порт 5701
kubectl create deployment my-dep --image=busybox --port=5701

# Створити deployment з назвою my-dep, що містить декілька контейнерів
kubectl create deployment my-dep --image=busybox:latest --image=ubuntu:latest --image=nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка deployment

--image strings

Назви образів для запуску. Deployment може містити кілька образів для багатоконтейнерних pod.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--port int32     Типово: -1

Порт containerPort, який цей deployment експонує.

-r, --replicas int32     Типово: 1

Кількість реплік для створення. Стандартно дорівнює 1.

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.6 - kubectl create ingress

Огляд

Створює ingress із зазначеною назвою.

kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]]

Приклади

# Створити один ingress з назвою 'simple', який направляє запити з foo.com/bar на svc1:8080 з TLS-сертифікатом "my-cert"
kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"

# Створити ingress, який захоплює усі шляхи "/path" і направляє їх на сервіс svc:port з класом ingress "otheringress"
kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port"

# Створити ingress з двома анотаціями: ingress.annotation1 і ingress.annotations2
kubectl create ingress annotated --class=default --rule="foo.com/bar=svc:port" \
--annotation ingress.annotation1=foo \
--annotation ingress.annotation2=bla

# Створити ingress з тим же хостом і декількома шляхами
kubectl create ingress multipath --class=default \
--rule="foo.com/=svc:port" \
--rule="foo.com/admin/=svcadmin:portadmin"

# Створити ingress з декількома хостами і типом шляху як Prefix
kubectl create ingress ingress1 --class=default \
--rule="foo.com/path*=svc:8080" \
--rule="bar.com/admin*=svc2:http"

# Створити ingress з увімкненим TLS, використовуючи стандартний сертифікат ingress і різними типами шляхів
kubectl create ingress ingtls --class=default \
--rule="foo.com/=svc:https,tls" \
--rule="foo.com/path/subpath*=othersvc:8080"

# Створити ingress з увімкненим TLS, використовуючи конкретний секрет і типом шляху як Prefix
kubectl create ingress ingsecret --class=default \
--rule="foo.com/*=svc:8080,tls=secret1"

# Створити ingress зі стандартним бекендом
kubectl create ingress ingdefault --class=default \
--default-backend=defaultsvc:http \
--rule="foo.com/*=svc:8080,tls=secret1"

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--annotation strings

Анотація для вставки в обʼєкт ingress у форматі annotation=value

--class string

Ingress Class що буде використано

--default-backend string

Стандартний сервіс бекенду, у форматі svcname:port

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка ingress

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--rule strings

Правило у форматі host/path=service:port[,tls=secretname]. Шляхи, що містять початковий символ '*', вважаються pathType=Prefix. tls — необовʼязковий аргумент.

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.7 - kubectl create job

Огляд

Створює job з вказаним іменем.

kubectl create job NAME --image=image [--from=cronjob/name] -- [COMMAND] [args...]

Приклади

# Створити задачу (job)
kubectl create job my-job --image=busybox

# Створити задачу з командою
kubectl create job my-job --image=busybox -- date

# Створити задачу на основі крон-завдання з назвою "a-cronjob"
kubectl create job test-job --from=cronjob/a-cronjob

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from string

Імʼя ресурсу, з якого буде створено Job (підтримується тільки cronjob).

-h, --help

Довідка job

--image string

Назва образу контейнера для запуску.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.8 - kubectl create namespace

Огляд

Створює простір імен з вказаним іменем.

kubectl create namespace NAME [--dry-run=server|client|none]

Приклади

# Створити простір імен з іменем my-namespace
kubectl create namespace my-namespace

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка namespace

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.9 - kubectl create poddisruptionbudget

Огляд

Створіть бюджет розладу роботи Podʼів із зазначеною назвою, селектором і бажаним мінімумом доступних Podʼів.

kubectl create poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run=server|client|none]

Приклади

# Створити бюджет розладу роботи Podʼів з назвою "my-pdb",
# який вибере всі Podʼи з міткою app=rails і вимагатиме, щоб принаймні один з них був доступний в будь-який момент
kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

# Створити бюджет розладу роботи Podʼів з назвою "my-pdb",
# який вибере всі Podʼи з міткою app=nginx і вимагатиме, щоб принаймні половина вибраних Podʼів була доступна в будь-який момент
kubectl create pdb my-pdb --selector=app=nginx --min-available=50%

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка poddisruptionbudget

--max-unavailable string

Максимальна кількість або відсоток недоступних Podʼів, яких вимагає цей бюджет.

--min-available string

Мінімальна кількість або відсоток доступних Podʼів, яких вимагає цей бюджет.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--selector string

Селектор мітки, який буде використано для цього бюджету. Підтримуються лише вимоги до селектора на основі рівності.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.10 - kubectl create priorityclass

Огляд

Створює клас пріоритету з вказаним імʼям, значенням, globalDefault та описом.

kubectl create priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run=server|client|none]

Приклади

# Створити клас пріоритету з назвою high-priority
kubectl create priorityclass high-priority --value=1000 --description="high priority"

# Створити клас пріоритету з назвою default-priority, який вважається глобальним стандартним класом пріоритету
kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority"

# Створити клас пріоритету з назвою high-priority, який не може випереджувати Podʼи з нижчим пріоритетом
kubectl create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never"

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--description string

description — довільний рядок, який зазвичай містить вказівки щодо того, коли слід використовувати цей клас пріоритету.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--global-default

global-default вказує, чи слід вважати цей PriorityClass стандартним пріоритетом.

-h, --help

Довідка priorityclass

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--preemption-policy string     Типово: "PreemptLowerPriority"

preemption-policy — це політика випередження Podʼів з нижчим пріоритетом.

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--value int32

значення цього класу пріоритету.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.11 - kubectl create quota

Огляд

Створення квоти ресурсів із зазначеною назвою, жорсткими обмеженнями та необовʼязковими діапазонами.

kubectl create quota NAME [--hard=key1=value1,key2=value2] [--scopes=Scope1,Scope2] [--dry-run=server|client|none]

Приклади

# Створити нову квоту ресурсів з назвою my-quota
kubectl create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10

# Створити нову квоту ресурсів з назвою best-effort
kubectl create quota best-effort --hard=pods=100 --scopes=BestEffort

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--hard string

Розділений комами набір пар resource=quantity, які визначають жорсткі межі.

-h, --help

Довідка quota

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--scopes string

Розділений комами набір діапазонів квот, які повинні відповідати кожному обʼєкту, що відстежується за допомогою квоти.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.12 - kubectl create role

Створює роль з одним правилом.

kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none]

Приклади

# Створити роль з назвою "pod-reader", яка дозволяє користувачу виконувати "get", "watch" і "list" для Podʼів
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

# Створити роль з назвою "pod-reader" з вказаними ResourceName
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

# Створити роль з назвою "foo" з вказаною API Group
kubectl create role foo --verb=get,list,watch --resource=rs.apps

# Створити роль з назвою "foo" з вказаним SubResource
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка role

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--resource strings

Ресурс, до якого застосовується правило

--resource-name strings

Ресурс у білому списку, до якого застосовується правило, повторіть цей прапорець для кожного елемента

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--verb strings

Дієслово, яке застосовується до ресурсів, що містяться в правилі

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.13 - kubectl create rolebinding

Огляд

Створення привʼязки для певної ролі або кластерної ролі.

kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Створити привʼязки ролей для user1, user2 та group1, використовуючи роль admin
kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1

# Створити привʼязки ролей для serviceaccount monitoring:sa-dev, використовуючи роль admin
kubectl create rolebinding admin-binding --role=admin --serviceaccount=monitoring:sa-dev

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--clusterrole string

ClusterRole на яку повинна посилатися привʼязка ClusterRoleBinding

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--group strings

Групи для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кілька груп.

-h, --help

Довідка rolebinding

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--role string

Роль, на яку має посилатися ця RoleBinding

--save-config

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

--serviceaccount strings

Службові облікові записи для привʼязки до кластерної ролі, у форматі <простір імен>:<імʼя>. Прапорець можна повторювати для додавання декількох службових облікових записів.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--user strings

Імена користувачів для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кількох користувачів.

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

11.3.15.14 - kubectl create secret

Огляд

Створення секрету з вказаним типом.

Секрет типу docker-registry призначений для доступу до реєстру контейнера.

Тип секрету generic вказує на Opaque тип секрету.

Секрет типу tls містить TLS-сертифікат і повʼязаний з ним ключ.

kubectl create secret (docker-registry | generic | tls)

Параметри

-h, --help

Довідка secret

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.15.15 - kubectl create secret docker-registry

Огляд

Створення нового секрету для використання з реєстрами Docker.

Секрети Dockercfg використовуються для автентифікації у реєстрах Docker.

При використанні командного рядка Docker для надсилання образів, ви можете автентифікуватися в заданому реєстрі за допомогою запуску команди:

$ docker login DOCKER_REGISTRY_SERVER --username=DOCKER_USER --password=DOCKER_PASSWORD --email=DOCKER_EMAIL.

В результаті буде створено файл ~/.dockercfg, який використовується наступними командами docker push і docker pull для автентифікації в реєстрі. Адреса електронної пошти не є обовʼязковою.

При створенні програм може виникнути ситуація, коли реєстр Docker вимагає автентифікації. Для того, щоб вузли вузли могли отримувати образи від вашого імені, вони повинні мати облікові дані. Ви можете надати цю інформацію створивши секрет dockercfg і прикріпивши його до свого службового облікового запису.

kubectl create secret docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [--docker-server=string] [--from-file=[key=]source] [--dry-run=server|client|none]

Приклади

# Якщо у вас ще немає файлу .dockercfg, створіть секрет dockercfg безпосередньо
kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

# Створити новий секрет з назвою my-secret з ~/.docker/config.json
kubectl create secret docker-registry my-secret --from-file=path/to/.docker/config.json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш secret до назви secret.

--docker-email string

Email для реєстру Docker

--docker-password string

Пароль для автентифікації в реєстрі Docker

--docker-server string     Типово: "https://index.docker.io/v1/"

Розташування сервера реєстру Docker

--docker-username string

Імʼя користувача для автентифікації в реєстрі Docker

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from-file strings

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

-h, --help

Довідка docker-registry

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create secret — Створити секрет за допомогою вказаної субкоманди

11.3.15.16 - kubectl create secret generic

Огляд

Створення секрету на основі файлу, теки або вказаного літерального значення.

Один секрет може містити одну або декілька пар ключ/значення.

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

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

kubectl create secret generic NAME [--type=string] [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]

Приклади

# Створити новий секрет з назвою my-secret з ключами для кожного файлу в теці bar
kubectl create secret generic my-secret --from-file=path/to/bar

# Створити новий секрет з назвою my-secret з вказаними ключами замість імен на диску
kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-file=ssh-publickey=path/to/id_rsa.pub

# Створити новий секрет з назвою my-secret з key1=supersecret та key2=topsecret
kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

# Створити новий секрет з назвою my-secret з використанням комбінації файлу та літерала
kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret

# Створити новий секрет з назвою my-secret з файлів env
kubectl create secret generic my-secret --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш secret до назви secret.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from-env-file strings

Вкажіть шлях до файлу для отримання рядків з парами key=val для створення secret.

--from-file strings

Файл ключа можна вказати за допомогою шляху до файлу, у цьому випадку імʼя файлу буде використано як ключ, або за допомогою ключа і шляху до файлу, у цьому випадку буде використано заданий ключ. Якщо вказати теку, буде виконано ітерацію для кожного названого файлу у цій теці, імʼя якого є допустимим ключем secret.

--from-literal strings

Вкажіть ключ і літеральне значення для вставки в secret (тобто mykey=somevalue)

-h, --help

Довідка generic

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--type string

Тип секрету, який необхідно створити

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create secret — Створити секрет за допомогою вказаної субкоманди

11.3.15.17 - kubectl create secret tls

Огляд

Створення TLS-секрету із заданої пари публічного/приватного ключа.

Пара відкритий/закритий ключ повинна існувати заздалегідь. Сертифікат відкритого ключа повинен бути зашифрований у форматі .PEM і відповідати заданому закритому ключу.

kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]

Приклади

# Створіть новий TLS-секрет з імʼям tls-secret із заданою парою ключів
kubectl create secret tls tls-secret --cert=path/to/tls.crt --key=path/to/tls.key

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш secret до назви secret.

--cert string

Шлях до PEM-закодованого сертифіката відкритого ключа.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка tls

--key string

Шлях до приватного ключа, повʼязаного з даним сертифікатом.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create secret — Створити секрет за допомогою вказаної субкоманди

11.3.15.18 - kubectl create service

Огляд

Створення сервісу з використанням субкоманд.

kubectl create service [flags]

Параметри

-h, --help

Довідка service

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.15.19 - kubectl create service clusterip

Огляд

Створення сервісу ClusterIP із зазначеним імʼям.

kubectl create service clusterip NAME [--tcp=<port>:<targetPort>] [--dry-run=server|client|none]

Приклади

# Створити новий сервіс ClusterIP з назвою my-cs
kubectl create service clusterip my-cs --tcp=5678:8080

# Створити новий сервіс ClusterIP з назвою my-cs (у режимі headless)
kubectl create service clusterip my-cs --clusterip="None"

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--clusterip string

Призначте власний ClusterIP або встановіть значення "None" для сервісу "headless" (без балансування навантаження).

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка clusterip

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

11.3.15.20 - kubectl create service externalname

Огляд

Створення сервісу ExternalName із зазначеним імʼям.

Сервіс ExternalName посилається на зовнішню DNS-адресу, а не лише на Podʼи, що дозволить авторам застосунків посилатися на сервіси, які існують за межами платформи, в інших кластерах або локально.

kubectl create service externalname NAME --external-name external.name [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс ExternalName з іменем my-ns
kubectl create service externalname my-ns --external-name bar.com

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--external-name string

Зовнішня назва сервісу

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка externalname

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

11.3.15.21 - kubectl create service loadbalancer

Огляд

Створення сервісу LoadBalancer з вказаним імʼям.

kubectl create service loadbalancer NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс LoadBalancer з назвою my-lbs
kubectl create service loadbalancer my-lbs --tcp=5678:8080

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка loadbalancer

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

11.3.15.22 - kubectl create service nodeport

Огляд

Створення сервісу NodePort з вказаним імʼям.

kubectl create service nodeport NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс NodePort з назвою my-ns
kubectl create service nodeport my-ns --tcp=5678:8080

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка nodeport

--node-port int

Порт, який використовується для експонування сервісу на кожному вузлі кластера.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

11.3.15.23 - kubectl create serviceaccount

Огляд

Створення службового облікового запису з вказаним імʼям.

kubectl create serviceaccount NAME [--dry-run=server|client|none]

Приклади

# Створіть новий служюовий обліковий записк з назвою my-service-account
kubectl create serviceaccount my-service-account

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка serviceaccount

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або з stdin

11.3.15.24 - kubectl create token

Огляд

Запит на отримання токена службового облікового запису.

kubectl create token SERVICE_ACCOUNT_NAME

Приклади

# Запит токена для автентифікації на kube-apiserver як службовий обліковий запис "myapp" у поточному просторі імен
kubectl create token myapp

# Запит токена для службового облікового запису у власному просторі імен
kubectl create token myapp --namespace myns

# Запит токена із власним часом дії
kubectl create token myapp --duration 10m

# Запит токена із власною аудиторією
kubectl create token myapp --audience https://example.com

# Запит токена, привʼязаного до обʼєкта типу Secret
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret

# Запит токена, привʼязаного до обʼєкта типу Secret з конкретним UID
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid 0d4691ed-659b-4935-a832-355f77ee47cc

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--audience strings

Аудиторія запитуваного токена. Якщо не встановлено, стандартно запитується токен для використання з сервером API Kubernetes. Може бути повторений для запиту токена, дійсного для декількох аудиторій.

--bound-object-kind string

Тип обʼєкта, до якого привʼязується токен. Підтримуються типи Node, Pod, Secret. Якщо задано, має бути вказано --bound-object-name.

--bound-object-name string

Імʼя обʼєкта, до якого потрібно привʼязати токен. Термін дії токена закінчиться, коли обʼєкт буде видалено. Потрібно вказати --bound-object-kind.

--bound-object-uid string

UID обʼєкта, до якого потрібно привʼязати токен. Потрібні --bound-object-kind та --bound-object-name. Якщо не вказано, використовується UID наявного обʼєкта.

--duration duration

Запитуваний термін життя випущеного токена. Якщо не вказано або вказано 0, то термін життя буде визначено сервером автоматично. Сервер може повернути токен з більшим або меншим терміном дії.

-h, --help

Довідка token

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або з stdin

11.3.16 - kubectl debug

Огляд

Налагодження ресурсів кластера за допомогою інтерактивних контейнерів налагодження.

'debug' автоматизує виконання поширених завдань налагодження для обʼєктів кластера, ідентифікованих за ресурсом та імʼям. Типово будуть використовуватися Podʼи, якщо ресурс не вказано.

Дія, яку виконує 'debug', залежить від вказаного ресурсу. Підтримувані дії включають:

  • Workload: Створити копію поточного Podʼа зі зміненими атрибутами, наприклад, змінити теґ образу на нову версію.
  • Workload: Додати ефемерний контейнер до вже працюючого Podʼа, наприклад, щоб додати утиліти для налагодження без перезапуску Podʼа.
  • Node: Створити новий Pod, який працює у host namespaces вузла та має доступ до файлової системи вузла.
kubectl debug (POD | TYPE[[.VERSION].GROUP]/NAME) [ -- COMMAND [args...] ]

Приклади

# Створити інтерактивну сесію налагодження в Pod mypod та одразу приєднатися до неї.
kubectl debug mypod -it --image=busybox

# Створити інтерактивну сесію налагодження для Pod з файлу pod.yaml та одразу приєднатися до неї.
# (вимагає увімкнення функції EphemeralContainers в кластері)
kubectl debug -f pod.yaml -it --image=busybox

# Створити контейнер налагодження з назвою debugger, використовуючи власний автоматизований образ для налагодження.
kubectl debug --image=myproj/debug-tools -c debugger mypod

# Створити копію mypod, додавши контейнер налагодження, та приєднатися до неї.
kubectl debug mypod -it --image=busybox --copy-to=my-debugger

# Створити копію mypod, змінивши команду mycontainer.
kubectl debug mypod -it --copy-to=my-debugger --container=mycontainer -- sh

# Створити копію mypod, змінивши образи всіх контейнерів на busybox.
kubectl debug mypod --copy-to=my-debugger --set-image=*=busybox

# Створити копію mypod, додавши контейнер налагодження та змінивши образи контейнерів.
kubectl debug mypod -it --copy-to=my-debugger --image=debian --set-image=app=app:debug,sidecar=sidecar:debug

# Створити інтерактивну сесію налагодження на вузлі та одразу приєднатися до неї.
# Контейнер працюватиме в host namespaces та файлову систему вузла буде змонтовано у /host.
kubectl debug node/mynode -it --image=busybox

Параметри

--arguments-only

Якщо вказано, все, що знаходиться після --, буде передано до нового контейнера як Args замість Command.

--attach

Якщо значення true, дочекайтись запуску контейнера, а потім приєднати його так, ніби було викликано команду 'kubectl attach ...'. Стандартне значення false, якщо не задано параметр '-i/--stdin', у цьому випадку стандартне значення true.

-c, --container string

Назва контейнера, який буде використано для налагодження.

--copy-to string

Створіює копію цільового Pod з цією назвою.

--custom string

Шлях до JSON або YAML-файлу, що містить часткову специфікацію контейнера для налаштування вбудованих профілів налагодження.

--env stringToString     Типово: []

Змінні оточення, які потрібно встановити в контейнері.

-f, --filename strings

визначення ресурсу для налагодження

-h, --help

Довідка debug

--image string

Назва образу контейнера для запуску.

--image-pull-policy string

Політика отримання образів для контейнера. Якщо залишити порожнім, це значення не буде вказано клієнтом і буде стандартно визначене сервером.

--keep-annotations

Якщо значення true, зберігати оригінальні анотації p Podʼів (цей прапорець працює лише при використанні '--copy-to').

--keep-init-containers     Default: true

Запустити ініціалізаційні контейнери для pod. Стандартно дорівнює true (цей прапорець працює лише у випадку використання з '--copy-to').

--keep-labels

Якщо значення true, зберігати оригінальні мітки Podʼів (цей прапорець працює лише при використанні '--copy-to').

--keep-liveness

Якщо значення true, зберегти оригінальні проби життєздатності Podʼа. (Цей прапорець працює лише при використанні '--copy-to').

--keep-readiness

Якщо значення true, зберегти оригінальні проби готовності Podʼа. (Цей прапорець працює лише при використанні '--copy-to').

--keep-startup

Якщо значення true, зберігати оригінальні проби запуску (цей прапорець працює лише при використанні '--copy-to').

--profile string     Типово: "legacy"

Варіанти: " legacy", "general", "baseline", "netadmin", "restricted" або "sysadmin".

-q, --quiet

Якщо true, то придушити інформаційні повідомлення.

--replace

При використанні з '--copy-to' видаляє оригінальний Pod.

--same-node

Якщо використовується з '--copy-to', призначити копію цільового Pod на той самий вузол.

--set-image stringToString     Типово: []

При використанні з '--copy-to', список пар name=image для зміни образів контейнерів, подібно до того, як працює команда 'kubectl set image'.

--share-processes     Типово: true

При використанні з '--copy-to' вмикає спільне використання простору імен процесів у копії.

-i, --stdin

Залишати stdin відкритим у контейнері (контейнерах), навіть якщо до нього нічого не приєднано.

--target string

При використанні ефемерного контейнера, спрямовувати процеси до цього контейнера.

-t, --tty

Призначення TTY для контейнера налагодження.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.17 - kubectl delete

Огляд

Видалення ресурсів за іменами файлів, stdin, ресурсами та іменами, або за ресурсами та селекторами міток.

Приймаються формати JSON та YAML. Можна вказати лише один тип аргументів: імена файлів, ресурси та імена, або ресурси та селектори міток.

Деякі ресурси, такі як Podʼи, підтримують належне видалення. Ці ресурси визначають стандартний період перед примусовим завершенням (пільговий період), але ви можете змінити це значення за допомогою прапорця --grace-period або передати --now, щоб встановити пільговий період на 1. Оскільки ці ресурси часто представляють сутності в кластері, видалення може не бути підтверджене одразу. Якщо вузол, який хостить Pod, відключений або не може досягти API-сервера, завершення може зайняти значно більше часу, ніж пільговий період. Щоб примусово видалити ресурс, ви повинні вказати прапорець --force. Примітка: лише підмножина ресурсів підтримує належне видалення. За відсутності підтримки, прапорець --grace-period ігнорується.

ВАЖЛИВО: Примусове видалення Podʼів не чекає підтвердження, що процеси Podʼа завершені, що може залишити ці процеси запущеними, поки вузол не виявить видалення та не завершить належне видалення. Якщо ваші процеси використовують спільне сховище або звертаються до віддаленого API та залежать від імені Podʼа для ідентифікації, примусове видалення цих Podʼів може призвести до запуску кількох процесів на різних машинах з однаковою ідентифікацією, що може призвести до пошкодження даних або неконсистентності. Примусово видаляйте Pod лише коли ви впевнені, що Pod завершено, або якщо ваш застосунок може витримати кілька копій одного Podʼа, які працюють одночасно. Також, якщо ви примусово видаляєте Pod, планувальник може розмістити нові Pod на цих вузлах до того, як вузол звільнить ці ресурси, що спричинить негайне виселення цих Podʼів.

Зверніть увагу, що команда delete НЕ перевіряє версію ресурсу, тому якщо хтось подасть оновлення ресурсу в той момент, коли ви подасте команду delete, їхнє оновлення буде втрачено разом з рештою ресурсу.

Після видалення CustomResourceDefinition інвалідація кешу виявлення може тривати до 6 годин. Якщо ви не хочете чекати, можливо, варто запустити "kubectl api-resources", щоб оновити кеш виявлення.

kubectl delete ([-f FILENAME] | [-k DIRECTORY] | TYPE [(NAME | -l label | --all)])

Приклади

# Видалити Pod, використовуючи тип та імʼя, вказані в pod.json
kubectl delete -f ./pod.json

# Видалити ресурси з теки, що містить kustomization.yaml — наприклад, dir/kustomization.yaml
kubectl delete -k dir

# Видалити ресурси з усіх файлів, що закінчуються на '.json'
kubectl delete -f '*.json'

# Видалити Pod на основі типу та імені в JSON, переданому в stdin
cat pod.json | kubectl delete -f -

# Видалити Podʼи та сервіси з іменами "baz" та "foo"
kubectl delete pod,service baz foo

# Видалити Podʼи та сервіси з міткою name=myLabel
kubectl delete pods,services -l name=myLabel

# Видалити Pod з мінімальною затримкою
kubectl delete pod foo --now

# Примусово видалити Pod на мертвому вузлі
kubectl delete pod foo --force

# Видалити всі Podʼи
kubectl delete pods --all

Параметри

--all

Вилучити всі ресурси у просторі імен вказаних типів ресурсів.

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--cascade string[="background"]     Типово: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Podʼів, створених Replication Controller). Стандартне значення — background.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

містить ресурс, який потрібно видалити.

--force

Якщо true, негайно видалити ресурси з API і оминути процедуру належного видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Ігнорується, якщо значення відʼємне. Встановлюється у 1 для негайного завершення роботи. Може бути встановлене у 0, тільки якщо --force має значення true (примусове видалення).

-h, --help

Довідка delete

--ignore-not-found

Вважати "resource not found" за успішне видалення. Стандартно дорівнює "true", якщо вказано --all.

-i, --interactive

Якщо true, видаляти ресурс тільки після підтвердження користувача.

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--now

Якщо значення true, ресурсам дається сигнал про негайне припинення роботи (так само, як і --grace-period=1).

-o, --output string

Режим виводу. Використовуйте "-o name" для скороченого виводду (resource/name).

--raw string

Необроблений URI для DELETE на сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення таймауту залежно від розміру обʼєкта

--wait     Типово: true

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.18 - kubectl describe

Огляд

Показує детальну інформацію про певний ресурс або групу ресурсів.

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

kubectl describe TYPE NAME_PREFIX

спочатку перевірить наявність точного збігу між TYPE і NAME_PREFIX. Якщо такого ресурсу не існує, він виведе дані для кожного ресурсу, який має назву з префіксом NAME_PREFIX.

Для отримання повного списку підтримуваних ресурсів скористайтеся "kubectl api-resources".

kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)

Приклади

# Вивести опис вузла
kubectl describe nodes kubernetes-node-emt8.c.myproject.internal

# Вивести опис Podʼа
kubectl describe pods/nginx

# Вивести опис Podʼа, визначений типом та іменем у "pod.json"
kubectl describe -f pod.json

# Вивести опис всіх Podʼів
kubectl describe pods

# Вивести опис Podʼів за міткою name=myLabel
kubectl describe pods -l name=myLabel

# Вивести опис всіх Podʼів, керовані контролером реплікації 'frontend'
# (Podʼи, створені rc, отримують імʼя rc як префікс у назві Podʼа)
kubectl describe pods frontend

Параметри

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для отриманні інформації

-h, --help

Довідка describe

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-events     Типово: true

Якщо true, показувати події, повʼязані з описаним обʼєктом.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.19 - kubectl diff

Огляд

Порівнює конфігурації, вказані за назвою файлу або stdin, між поточною онлайн-конфігурацією та конфігурацією, яка була б застосована.

На виході завжди буде YAML.

Змінна середовища KUBECTL_EXTERNAL_DIFF може бути використана для вибору вашої власної команди diff. Користувачі також можуть використовувати зовнішні команди з параметрами, наприклад: KUBECTL_EXTERNAL_DIFF="colordiff -N -u"

Стандартно команду "diff", доступну у вашому шляху, буде запущено з параметрами "-u" (уніфікований diff) і "-N" (вважати відсутні файли порожніми).

Стан завершення роботи: 0 — Відмінностей не знайдено. 1 — Відмінності знайдено. >1 — Запуск Kubectl або diff завершився з помилкою.

Зауваження: якщо використовується KUBECTL_EXTERNAL_DIFF, очікується, що його буде застосовано відповідно до цієї конвенції.

kubectl diff -f FILENAME

Приклади

# Diff resources included in pod.json
kubectl diff -f pod.json

# Diff file read from stdin
cat service.yaml | kubectl diff -f -

Параметри

--concurrency int     Типово: 1

Кількість обʼєктів для паралельної обробки у порівнянні з реальною версією. Більша кількість = швидше, але більше памʼяті, вводу/виводу та процесора за коротший проміжок часу.

--field-manager string     Типово: "kubectl-client-side-apply"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що містить конфігурацію для diff

--force-conflicts

Якщо значення true, серверне застосування (server-side apply) буде примусово вносити зміни всупереч конфліктам.

-h, --help

Довідка diff

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--prune

Включити ресурси, які буде видалено під час обрізання. Можна використовувати з параметром -l і типово показує всі ресурси, які буде вилучено

--prune-allowlist strings

Замінити список стандартний дозволів (allowlist) <group/version/kind> для --prune

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--server-side

Якщо значення true, apply виконується на сервері, а не на клієнті.

--show-managed-fields

Якщо true, включити керовані поля в diff.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.20 - kubectl drain

Огляд

Очищує вузол для підготовки до обслуговування.

Зазначений вузол будо позначено, як не придатний для розміщення робочих навантажень для запобігання створенню нових Podʼів на ньому. 'drain' виселяє Podʼи, якщо API сервер підтримує розлади або виселення. В іншому випадку він використовує звичайний DELETE, щоб видалити Podʼи. 'drain' виселяє або видаляє всі Podʼи, окрім дзеркальних Podʼів (які не можна видалити за допомогою API сервера). Якщо це самокерований Pod демона, drain не спрацює, якщо немає --ignore-daemonsets, і Pod не буде видалено, бо такі Podʼи будуть негайно замінені новими контролером DaemonSet, який не звертає уваги на позначку unschedulable. Якщо є якісь Podʼи, які не є дзеркальними Podʼами, і які не керуються контролером реплікації, replica set, daemon set, stateful set, або job то drain не видалить жодного Pod, якщо ви не скористаєтеся опцією --force. --force також дозволить продовжити видалення, якщо відсутній керуючий ресурс одного або декількох Podʼів.

'drain' чекає на коректне завершення. Ви не повинні працювати на машині, поки команда не завершиться.

Коли ви будете готові повернути вузол до експлуатації, скористайтеся командою kubectl uncordon, яка зробить вузол знову доступним для планування.

kubectl drain

kubectl drain NODE

Приклади

# Спорожнити вузол "foo", навіть якщо на ньому є Podʼи, які не керуються контролером реплікації, replica set, job, daemon set або stateful set
kubectl drain foo --force

# Як вище, але перервати, якщо наявні Podʼи, які не керуються контролером реплікації, replica set, job, daemon set або stateful set, і використовувати пільговий період у 15 хвилин
kubectl drain foo --grace-period=900

Параметри

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

--delete-emptydir-data

Продовжувати, навіть якщо є Podʼи, що використовують emptyDir (локальні дані, які буде видалено, коли вузол буде спорожнено).

--disable-eviction

Примусово виводити ресурси за допомогою delete, навіть якщо підтримується виселення. Це дозволить обійти перевірку PodDisruptionBudgets, використовуйте з обережністю.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--force

Продовжувати, навіть якщо є Podʼи, які не задекларували контролер.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Якщо значення відʼємне, то буде використано стандартне значення, вказане у Pod.

-h, --help

Довідка drain

--ignore-daemonsets

Ігнорувати Podʼи керовані DaemonSet.

--pod-selector string

Селектор міток для фільтрування Podʼів на вузлі

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--skip-wait-for-delete-timeout int

Якщо хначення DeletionTimestamp Podʼа старіще за N секунд, пропускати очікування Podʼа. Значення секунд має бути більще за 0, щоб його оминути.

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає нескіченно

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.21 - kubectl edit

Огляд

Редагування ресурсу за допомогою стандартного редактора.

Команда edit дозволяє вам безпосередньо редагувати будь-який ресурс API, який ви можете отримати за допомогою інструментів командного рядка. Вона відкриє редактор, визначений вашими змінними оточення KUBE_EDITOR або EDITOR, або відкриє "vi" для Linux чи "notepad" для Windows. Під час спроби відкрити редактор спочатку буде використано оболонку, визначену у змінній оточення 'SHELL'. Якщо її не визначено, буде використано стандартну оболонку, якою є "/bin/bash" для Linux або "cmd" для Windows.

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

Редагування виконується за допомогою версії API, використаної для отримання ресурсу. Щоб редагувати з використанням певної версії API, повністю вкажіть ресурс, версію і групу.

Стандартний формат — YAML. Для редагування у форматі JSON вкажіть "-o json".

Прапорець --windows-line-endings може бути використаний для забезпечення примусового завершення рядків у форматі Windows, інакше буде використано типовий для вашої операційної системи.

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

kubectl edit (RESOURCE/NAME | -f FILENAME)

Приклади

# Змінити сервіс з назвою 'registry'
kubectl edit svc/registry

# Використовувати альтернативний редактор
KUBE_EDITOR="nano" kubectl edit svc/registry

# Редагувати job 'myjob' у форматі JSON з використанням формату API v1
kubectl edit job.v1.batch/myjob -o json

# Редагувати deployment 'mydeployment' в YAML і зберегти змінений конфіг в його анотації
kubectl edit deployment/mydeployment -o yaml --save-config

# Редагувати субресурс 'status' для deployment 'mydeployment'
kubectl edit deployment mydeployment --subresource='status'

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-edit"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, для редагування ресурсів

-h, --help

Довідка edit

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--output-patch

Вивести патч, якщо ресурс редагується.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--windows-line-endings

Стандартно використовується закінчення рядка, притаманне вашій платформі.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.22 - kubectl events

Огляд

Показати події.

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

kubectl events [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file] [--for TYPE/NAME] [--watch] [--types=Normal,Warning]

Приклади

# Вивести список нещодавніх подій у стандартному просторі імен
kubectl events

# Показати нещодавні події у всіх просторах імен
kubectl events --all-namespaces

# Вивести список нещодавніх подій для вказаного pod, потім дочекатися нових подій і виводити їх по мірі надходження
kubectl events --for pod/web-pod-13je7 --watch

# Показати нещодавні події у форматі YAML
kubectl events -oyaml

# Показати лише нещодавні події типу 'Warning' або 'Normal'
kubectl events --types=Warning,Normal

Параметри

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

--for string

Відфільтрувати події, щоб залишити лише ті, що стосуються вказаного ресурсу.

-h, --help

Довідка events

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--types strings

Вивести лише події заданих типів.

-w, --watch

Після отримання списку бажаних подій слідкувати за новими подіями.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.23 - kubectl exec

Огляд

Виконує команду в контейнері.

kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...]

Приклади

# Отримати вивід від виконання команди 'date' з Pod mypod, використовуючи типово перший контейнер
kubectl exec mypod -- date

# Отримати вивід команди 'date' у ruby-контейнері з Pod mypod
kubectl exec mypod -c ruby-container -- date

# Перехід у режим необробленого терміналу; надсилає stdin до 'bash' у ruby-контейнері з Pod mypod
# і надсилає stdout/stderr з 'bash' назад клієнту
kubectl exec mypod -c ruby-container -i -t -- bash -il

# Вивести вміст /usr з першого контейнера Pod mypod і відсортувати за часом модифікації
# Якщо команда, яку ви хочете виконати в Pod, має спільні прапорці (наприклад, -i),
# ви повинні використовувати два тире (--), щоб відокремити прапорці/аргументи вашої команди.
# Також зауважте, що не слід брати команду та її прапорці/аргументи у лапки
# якщо тільки ви не виконуватимете її так у звичайному режимі (тобто, виконайте ls -t /usr, а не "ls -t /usr").
kubectl exec mypod -i -t -- ls -t /usr

# Отримання результатів виконання команди 'date' з першого Pod deployment mydeployment, з використанням стандартно першого контейнера
kubectl exec deploy/mydeployment -- date

# Отримати вивід команди 'date' з першого Pod сервісу myservice, використовуючи стандартно перший контейнер
kubectl exec svc/myservice -- date

Параметри

-c, --container string

Назва контейнера. Якщо не вказано, використовуйте анотацію kubectl.kubernetes.io/default-container для вибору контейнера, який буде приєднано, інакше буде обрано перший контейнер у pod

-f, --filename strings

Імʼя файлу, теки або URL до файлів, для виконання ресурсів

-h, --help

Довідка exec

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

-q, --quiet

Виводити лише дані, отримані під час віддаленого сеансу

-i, --stdin

Передати stdin до контейнера

-t, --tty

Stdin є TTY

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.24 - kubectl explain

Огляд

Описує поля і структуру різних ресурсів.

Ця команда описує поля, повʼязані з кожним підтримуваним ресурсом API. Поля ідентифікуються за допомогою простого ідентифікатора JSONPath:

<type>.<fieldName>[.<fieldName>]

Інформація про кожне поле отримується з сервера у форматі OpenAPI.

Використовуйте "kubectl api-resources" для отримання повного списку підтримуваних ресурсів.

kubectl explain TYPE [--recursive=FALSE|TRUE] [--api-version=api-version-group] [--output=plaintext|plaintext-openapiv2]

Приклади

# Отримати документацію про ресурс та його поля
kubectl explain pods

# Отримати всі поля ресурсу
kubectl explain pods --recursive

# Отримати пояснення щодо deployment у підтримуваних версіях api
kubectl explain deployments --api-version=apps/v1

# Отримати документацію щодо певного поля ресурсу
kubectl explain pods.spec.containers

# Отримати документацію ресурсів у іншому форматі
kubectl explain deployment --output=plaintext-openapiv2

Параметри

--api-version string

Використовувати вказану api-version (group/version) ресурсу.

-h, --help

Довідка explain

--output string     Типово: "plaintext"

Формат, у якому потрібно показати схему. Допустимими значеннями є: (plaintext, plaintext-openapiv2).

--recursive

Якщо значення true, вивести назви всіх полів рекурсивно. Інакше, вивести доступні поля з їхнім описом.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.25 - kubectl expose

Огляд

Експонувати ресурс як нову службу Kubernetes.

Шукає deployment, service, replica set, replica controller або pod за назвою і використовує селектор для цього ресурсу як селектор для нового service на зазначеному порту. Deployment або replica set буде показано як сервіс, лише якщо його селектор буде перетворено на селектор, який підтримується сервісом, тобто коли селектор містить лише компонент matchLabels. Зауважте, що якщо за допомогою --port не вказано жодного порту, а експонований ресурс має декілька портів, усі вони будуть використані новим сервісом повторно. Також, якщо не вказано жодних міток, новий сервіс повторно використає мітки з ресурсу, який він відкриває.

Можливі ресурси включають (без урахування регістру):

pod (po), service (svc), replicationcontroller (rc), deployment (deploy), replicaset (rs)

kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP|SCTP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]

Приклади

# Створити сервіс для реплікованого nginx, який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose rc nginx --port=80 --target-port=8000

# Створити сервіс для контролера реплікації, визначеного типом та іменем у "nginx-controller.yaml", який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000

# Створити сервіс для Pod valid-pod, який працює на порту 444 з іменем "frontend"
kubectl expose pod valid-pod --port=444 --name=frontend

# Створити другий сервіс на основі вищезгаданого сервісу, відкриваючи контейнерний порт 8443 як порт 443 з іменем "nginx-https"
kubectl expose service nginx --port=443 --target-port=8443 --name=nginx-https

# Створити сервіс для реплікованого стрімінгового застосунку на порту 4100, балансуючи UDP-трафік, з імʼям 'video-stream'
kubectl expose rc streamer --port=4100 --protocol=UDP --name=video-stream

# Створити сервіс для реплікованого nginx за допомогою replica set, який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose rs nginx --port=80 --target-port=8000

# Створити сервіс для deployment nginx, який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose deployment nginx --port=80 --target-port=8000

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--cluster-ip string

ClusterIP, який буде призначено сервісу. Залиште порожнім для автоматичного призначення або встановіть значення "None", щоб створити сервіс headless.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--external-ip string

Додаткова зовнішня IP-адреса (не керована Kubernetes), яку буде використано для сервісу. Якщо цю IP-адресу перенаправлено на вузол, до сервісу можна отримати доступ з цієї IP-адреси на додачу до згенерованої IP-адреси сервісу.

--field-manager string     Типово: "kubectl-expose"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс, для експонування сервісу

-h, --help

Довідка expose

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-l, --labels string

Мітки, які будуть застосовані до сервісу, створеного цим викликом.

--load-balancer-ip string

IP для призначення LoadBalancer. Якщо поле порожнє, буде створено та використано ефемерний IP (залежить від хмарного провайдера).

--name string

Імʼя для новоствореного обʼєкта.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--override-type string     Типово: "merge"

Метод, який використовується для перевизначення згенерованого обʼєкта: json, merge або strategic.

--overrides string

Вбудоване перевизначення JSON для згенерованого обʼєкта. Якщо він не порожній, то використовується для перевизначення згенерованого обʼєкта. Вимагає, щоб обʼєкт надавав дійсне поле apiVersion.

--port string

Порт, на якому має працювати сервіс. Копіюється з ресурсу, що експонується, якщо не вказано

--protocol string

Мережевий протокол для сервісу, який буде створено. Стандартно — "TCP".

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

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

--selector string

Селектор міток, який потрібно використовувати для цього сервісу. Підтримуються лише вимоги до селектора на основі рівності. Якщо порожньо (стандартно), виводитиметься селектор з контролера реплікації або replica set.

--session-affinity

Якщо не порожньо, встановлює сесійну подібнітсть для сервісу. Допустимі значення: None, ClientIP.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--target-port string

Назва або номер порту в контейнері, на який сервіс повинен спрямовувати трафік. Необовʼязково.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--type string

Тип сервісу: ClusterIP, NodePort, LoadBalancer або ExternalName. Стандартно використовується 'ClusterIP'.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.26 - kubectl get

Огляд

Показати один або декілька ресурсів.

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

Зазначивши виведення як "template" і надавши шаблон Go як значення прапорця --template, ви можете відфільтрувати атрибути отриманих ресурсів.

Для отримання повного списку підтримуваних ресурсів скористайтеся "kubectl api-resources".

kubectl get [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file|custom-columns|custom-columns-file|wide] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]

Приклади

# Вивести перелік всіх Podʼів у форматі виводу ps
kubectl get pods

# Вивести перелік всії Podʼів у форматі виводу ps з додатковою інформацією (наприклад, імʼя вузла)
kubectl get pods -o wide

# Вивести перелік один контролер реплікації з вказаним NAME у форматі виводу ps
kubectl get replicationcontroller web

# Вивести перелік deployment у форматі виводу JSON, у версії "v1" групи API "apps"
kubectl get deployments.v1.apps -o json

# Вивести один Pod у форматі виводу JSON
kubectl get -o json pod web-pod-13je7

# Вивести перелік Podʼів, визначений типом та іменем у "pod.yaml", у форматі виводу JSON
kubectl get -f pod.yaml -o json

# Вивести перелік ресурси з теки з kustomization.yaml - наприклад, dir/kustomization.yaml
kubectl get -k dir/

# Повернути лише значення фази вказаного Pod
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}

# Вивести перелік інформації про ресурси у власних стовпцях
kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

# Вивести перелік всіх контролерів реплікації та сервіси разом у форматі виводу ps
kubectl get rc,services

# Вивести перелік один або більше ресурсів за їх типом та іменами
kubectl get rc/web service/frontend pods/web-pod-13je7

# Вивести перелік субресурс 'status' для одного Pod
kubectl get pod web-pod-13je7 --subresource status

# Вивести перелік всіх deployments в namespace 'backend'
kubectl get deployments.apps --namespace backend

# Вивести перелік всіх pods пристуніх в усіх namespaces
kubectl get pods --all-namespaces

Параметри

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс, для отримання з сервера.

-h, --help

Довідка get

--ignore-not-found

Якщо запитуваний обʼєкт не існує, команда поверне код виходу 0.

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-L, --label-columns strings

Приймає список міток, розділених комами, які буде представлено у вигляді стовпчиків. Назви чутливі до регістру. Ви також можете використовувати декілька прапорців, наприклад, -L label1 -L label2...

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки (заголовки стандартно друкуються).

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file, custom-columns, custom-columns-file, wide).Дивіться нестандартні стовпці [https://kubernetes.io/docs/reference/kubectl/#custom-columns](/uk/docs/reference/kubectl/#custom-columns), шаблон golang [http://golang.org/pkg/text/template/#pkg-overview] та шаблон jsonpath [https://kubernetes.io/docs/reference/kubectl/jsonpath/](/uk/docs/reference/kubectl/jsonpath/).

--output-watch-events

Виводити обʼєкти подій спостереження, якщо використовується --watch або --watch-only. Існуючі обʼєкти виводяться як початкові події ADDED.

--raw string

Необроблений URI для запиту з сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--server-print     Типово: true

Якщо це значення true, сервер має повернути відповідний вивід таблиці. Підтримує API розширення та CRD.

--show-kind

Якщо є, вкажіть тип ресурсу для запитуваного обʼєкта (обʼєктів).

--show-labels

Під час друку показувати всі мітки в останньому стовпчику (стандартно приховувати стовпчик міток)

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Специфікація поля виражається у вигляді виразу JSONPath (наприклад, '{.metadata.name}'). Поле в ресурсі API, визначене цим виразом JSONPath, має бути цілим чи рядком.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status scale]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

-w, --watch

Після отримання списку бажаних подій слідкувати за новими подіями.

--watch-only

Спостерігати за змінами запитуваного обʼєкта (обʼєктів), не переглядаючи/отримуючи їх спочатку.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.27 - kubectl kustomize

Огляд

Створення набору ресурсів KRM за допомогою файлу 'kustomization.yaml'. Аргумент DIR має бути шляхом до теки з файлом 'kustomization.yaml' або URL-адресою git-сховища з суфіксом шляху, що вказує на те саме відносно кореня сховища. Якщо DIR не вказано, буде використано символ ".".

kubectl kustomize DIR [flags]

Приклади

# Створити поточну робочу теку
kubectl kustomize

# Створити теку конфігурації зі спільним доступом
kubectl kustomize /home/config/production

# Побудувати з github
kubectl kustomize https://github.com/kubernetes-sigs/kustomize.git/examples/helloWorld?ref=v1.0.6

Параметри

--as-current-user

використовувати uid та gid виконавця команди для запуску функції в контейнері

--enable-alpha-plugins

увімкнути втулки kustomize

--enable-helm

Увімкніть використання генератора наповнювача чартів Helm.

-e, --env strings

список змінних оточення, які будуть використовуватися функціями

--helm-api-versions strings

Версії Kubernetes api, що використовуються Helm для Capabilities.APIVersions

--helm-command string     Типово: "helm"

команда helm (шлях до виконавчого файлу)

--helm-kube-version string

Версія Kubernetes, що використовується Helm для Capabilities.KubeVersion

-h, --help

Довідка kustomize

--load-restrictor string     Типово: "LoadRestrictionsRootOnly"

якщо встановлено значення 'LoadRestrictionsNone', локальні кастомізації можуть завантажувати файли ззовні свого кореня. Однак це порушує можливість переміщення кастомізації.

--mount strings

список параметрів сховища, отриманий з файлової системи

--network

вмикає доступ до мережі для функцій, які декларують про це

--network-name string     Типово: "bridge"

мережа docker для запуску контейнера

-o, --output string

Якщо вказано, записати вивід у цей шлях.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.28 - kubectl label

Огляд

Оновлює мітки ресурсів.

  • Ключ і значення мітки повинні починатися з літери або цифри і можуть містити літери, цифри, дефіси, крапки і підкреслення, до 63 символів кожна.
  • За бажанням, ключ може починатися з префікса субдомену DNS і одного символу "/", наприклад, example.com/my-app.
  • Якщо --overwrite має значення true, то наявні мітки можна перезаписати, інакше спроба перезаписати мітку призведе до помилки.
  • Якщо вказано --resource-version, то під час оновлення буде використано цю версію ресурсу, інакше буде використано наявну версію ресурсу.
kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

Приклади

# Оновити pod 'foo' міткою 'unhealthy' і значенням 'true'
kubectl label pods foo unhealthy=true

# Оновити pod 'foo' міткою 'status' і значенням 'unhealthy', замінивши будь-яке існуюче значення
kubectl label --overwrite pods foo status=unhealthy

# Оновити всі pods у просторі назв
kubectl label pods --all status=unhealthy

# Оновити pod, визначений за типом та назвою у файлі "pod.json"
kubectl label -f pod.json status=unhealthy

# Оновлювати pod 'foo' тільки якщо ресурс не змінився з версії 1
kubectl label pods foo status=unhealthy --resource-version=1

# Оновити pod 'foo', видаливши мітку з назвою 'bar', якщо вона існує
# Не потребує прапорця --overwrite
kubectl label pods foo bar-

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-label"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс, для оновлення міток.

-h, --help

Довідка label

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--list

Якщо true, показувати мітки для даного ресурсу.

--local

Якщо значення true, мітка НЕ буде звертатися до api-server, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite

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

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resource-version string

Якщо значення не порожнє, оновлення мітки буде успішним, тільки якщо це поточна версія ресурсу для обʼєкта. Дійсно лише при зазначенні одного ресурсу.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.29 - kubectl logs

Огляд

Вивести логи для контейнера у Podʼі або вказаного ресурсу. Якщо в pod є лише один контейнер, назва контейнера не є обовʼязковою.

kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]

Приклади

# Вивести знімок логів з Podʼа nginx з одним контейнером
kubectl logs nginx

# Вивести знімок логів з Podʼа nginx з кількома контейнерами
kubectl logs nginx --all-containers=true

# Вивести знімок логів з усіх контейнерів у Podʼах, визначених міткою app=nginx
kubectl logs -l app=nginx --all-containers=true

# Вивести знімок логів з попереднього завершеного контейнера ruby з Podʼа web-1
kubectl logs -p -c ruby web-1

# Почати трансляцію логів контейнера ruby у Podʼі web-1
kubectl logs -f -c ruby web-1

# Почати трансляцію логів з усіх контейнерів у Podʼах, визначених міткою app=nginx
kubectl logs -f -l app=nginx --all-containers=true

# Показати лише останні 20 рядків виводу в Podʼі nginx
kubectl logs --tail=20 nginx

# Показати всі логи з Podʼа nginx, записані за останню годину
kubectl logs --since=1h nginx

# Показати логи з kubelet з простроченим сертифікатом сервера
kubectl logs --insecure-skip-tls-verify-backend nginx

# Вивести знімок логів з першого контейнера завдання з назвою hello
kubectl logs job/hello

# Вивести знімок логів з контейнера nginx-1 у deployment з назвою nginx
kubectl logs deployment/nginx -c nginx-1

Параметри

--all-containers

Отримайте логи всіх контейнерів у pod(ах).

--all-pods

Отримати логи з усіх Pod(ів). Встановлює префікс у true.

-c, --container string

Вивести логи цього контейнера

-f, --follow

Вкажіть, чи потрібно транслювати логи.

-h, --help

Довідка logs

--ignore-errors

Якщо ви переглядаєте / стежите за логами pod, дозвольте будь-яким помилкам, що трапляються, бути не фатальними

--insecure-skip-tls-verify-backend

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

--limit-bytes int

Максимальна кількість байт логів для виводу. Стандартно без обмежень.

--max-log-requests int     Типово: 5

Вкажіть максимальну кількість паралельних логів, які слід відстежувати при використанні селектора. Стандартно встановлено значення 5.

--pod-running-timeout duration     Типово: 20s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

--prefix

До початку кожного рядка логу додайте джерело логу (імʼя pod та імʼя контейнера)

-p, --previous

Якщо true, вивести логи для попереднього екземпляра контейнера в pod, якщо він існує.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--since duration

Виводити лише ті логи, що є новішими за відносну тривалість, наприклад, 5s, 2m або 3h. Стандартно для всіх логів. Можна використовувати лише один з параметрів since-time / since.

--since-time string

Виводити логи лише після певної дати (RFC3339). Стандартно для всіх логів. Можна використовувати лише один з параметрів since-time / since.

--tail int     Типово: -1

Рядки нещодавнього файлу логу для показу. Стандартно дорівнює -1 без селектора, показуючи всі рядки логу, інакше 10, якщо селектор вказано.

--timestamps

Додайте мітки часу до кожного рядка у виводі логу

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.30 - kubectl options

Огляд

Виводить список прапорців, успадкованих усіма командами

kubectl options [flags]

Приклади

# Вивести список прапорців, успадкованих усіма командами
kubectl options

Параметри

-h, --help

Довідка options

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.31 - kubectl patch

Огляд

Оновлення полів ресурсу за допомогою патча стратегічного злиття, патча злиття JSON або патча JSON.

Підтримуються формати JSON і YAML.

Примітка: Стратегічне злиття не підтримується для власних ресурсів користувача.

kubectl patch (-f FILENAME | TYPE NAME) [-p PATCH|--patch-file FILE]

Приклади

# Частково оновити вузол за допомогою патчів стратегічного злиття, вказавши патч як JSON
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# Частково оновити вузол за допомогою патчів стратегічного злиття, вказавши патч як YAML
kubectl patch node k8s-node-1 -p $'spec:\n unschedulable: true'

# Частково оновити вузол, визначений типом та імʼям у "node.json", за допомогою патчів стратегічного злиття
kubectl patch -f node.json -p '{"spec":{"unschedulable":true}}'

# Оновити образ контейнера; spec.containers[*].name є обовʼязковим, оскільки це ключ для злиття
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# Оновити образ контейнера за допомогою патча JSON з позиційними масивами
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# Оновити кількість реплік deployment через субресурс 'scale' за допомогою злиття патчів
kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-patch"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс для оновлення.

-h, --help

Довідка patch

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо true, патч буде працювати з вмістом файлу, а не з ресурсом на стороні сервера.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-p, --patch string

Патч, який буде застосовано до JSON-файлу ресурсу.

--patch-file string

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

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status scale]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--type string     Типово: "strategic"

Тип патчу, що застосовується; один з [json merge strategic].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.32 - kubectl plugin

Впроваджує утиліти для взаємодії з втулками.

Втулки надають розширену функціональність, яка не є частиною основного коду kubectl. Будь ласка, зверніться до документації та прикладів для отримання додаткової інформації про те, як писати власні втулки.

Найпростіший спосіб знайти та встановити втулки — за допомогою субпроєкту kubernetes krew. Щоб встановити krew, відвідайте krew.sigs.k8s.io.

kubectl plugin [flags]

Приклади

# Вивести перелік всіх доступних втулків
kubectl plugin list

# Вивести перелік назв двійкових файлів доступних втулків без шляхів
kubectl plugin list --name-only

Параметри

-h, --help

Довідка plugin

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl plugin list — список усіх виконуваних файлів втулків видимих у PATH користувача

11.3.32.1 - kubectl plugin list

Огляд

Показати всі доступні файли втулків у PATH користувача. Для виводу тільки назв двійкових файлів використовуйте прапорець --name-only.

Доступними вважаються файли втулків, які є:

  • виконуваними
  • будь-де в PATH користувача
  • починаються з "kubectl-"
kubectl plugin list [flags]

Приклади

# Вивести перелік всіх доступних втулків
kubectl plugin list

# Вивести перелік назв двійкових файлів доступних втулків без шляхів
kubectl plugin list --name-only

Параметри

-h, --help

Довідка list

--name-only

Якщо значення true, показувати лише назву команди кожного втулка, а не повний шлях до нього

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl plugin — Впроваджує утиліти для взаємодії з втулками.

11.3.33 - kubectl port-forward

Огляд

Перенаправте один або кілька локальних портів у Pod.

Використовуйте тип/назву ресурсу, наприклад, deployment/mydeployment, для вибору Podʼа. Якщо його не вказано, тип ресурсу стандартно дорівнюватиме 'pod'.

Якщо є кілька Podʼів, що відповідають критеріям, автоматично буде обрано один з них. Сеанс перенаправлення завершується після завершення роботи вибраного Podʼа, і для відновлення перенаправлення потрібно повторно виконати команду.

kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]

Приклади

# Слухати на портах 5000 і 6000 локально, перенаправляючи дані з/на порти 5000 і 6000 у Pod
kubectl port-forward pod/mypod 5000 6000

# Слухати на портах 5000 і 6000 локально, перенаправляючи дані з/на порти 5000 і 6000 у Pod, обраний за допомогою deployment
kubectl port-forward deployment/mydeployment 5000 6000

# Слухати на порту 8443 локально, перенаправляючи на targetPort порту сервісу з імʼям "https" у Pod, обраний за допомогою сервісу
kubectl port-forward service/myservice 8443:https

# Слухати на порту 8888 локально, перенаправляючи на порт 5000 у Pod
kubectl port-forward pod/mypod 8888:5000

# Слухати на порту 8888 на всіх адресах, перенаправляючи на порт 5000 у Pod
kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000

# Слухати на порту 8888 на localhost та вибраній IP-адресі, перенаправляючи на порт 5000 у Pod
kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000

# Слухати на випадковому порту локально, перенаправляючи на 5000 у Pod
kubectl port-forward pod/mypod :5000

Параметри

--address strings     Типово: "localhost"

Адреси для прослуховування (через кому). Допускається вказувати лише IP-адреси або localhost. Якщо вказано localhost, kubectl спробує привʼязатися до адрес 127.0.0.1 та ::1 і завершить роботу, якщо жодна з цих адрес не буде доступною для привʼязки.

-h, --help

Довідка port-forward

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.34 - kubectl proxy

Огляд

Створює проксі-сервер або шлюз на рівні програми між localhost і сервером API Kubernetes. Він також дозволяє передавати статичний вміст за вказаним HTTP-шляхом. Всі вхідні дані надходять через один порт і перенаправляються на порт віддаленого сервера Kubernetes API, за винятком шляху, що збігається зі шляхом до статичного контенту.

kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix]

Приклади

# Проксіювати Kubernetes API і більше нічого
kubectl proxy --api-prefix=/

# Проксіювати лише частину Kubernetes API та деякі статичні файли
# Ви можете отримати інформацію про Podʼи за допомогою 'curl localhost:8001/api/v1/pods'
kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/

# Проксіювати весь Kubernetes API за іншим коренем
# Ви можете отримати інформацію про Podʼи за допомогою 'curl localhost:8001/custom/api/v1/pods'
kubectl proxy --api-prefix=/custom/

# Запустити проксі до сервера Kubernetes API на порту 8011, обслуговуючи статичний контент з ./local/www/
kubectl proxy --port=8011 --www=./local/www/

# Запустити проксі до сервера Kubernetes API на довільному локальному порту
# Обраний порт для сервера буде виведено в stdout
kubectl proxy --port=0

# Запустити проксі до сервера Kubernetes API, змінюючи префікс API на k8s-api
# Це робить, наприклад, API підів доступним за адресою localhost:8001/k8s-api/v1/pods/
kubectl proxy --api-prefix=/k8s-api

Параметри

--accept-hosts string     Типово: "^localhost$,^127\.0\.0\.1$,^\[::1\]$"

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

--accept-paths string     Типово: "^.*"

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

--address string     Типово: "127.0.0.1"

IP-адреса, на якій буде здійснюватися обслуговування.

--api-prefix string     Типово: "/"

Префікс для обслуговування проксі API.

--append-server-path

Якщо значення true, вмикає автоматичне додавання шляху до сервера kube context до кожного запиту.

--disable-filter

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

-h, --help

Довідка proxy

--keepalive duration

keepalive задає період підтримки активного мережевого зʼєднання. Встановіть значення 0, щоб вимкнути keepalive.

-p, --port int     Типово: 8001

Порт, на якому буде запущено проксі. Встановіть 0, щоб вибрати випадковий порт.

--reject-methods string     Типово: "^$"

Регулярний вираз для HTTP-методів, які проксі повинен відхиляти (еаприклад --reject-methods='POST,PUT,PATCH').

--reject-paths string     Типово: "^/api/.*/pods/.*/exec,
^/api/.*/pods/.*/attach"

Регулярний вираз для шляхів, які проксі має відхиляти. Шляхи, вказані тут, буде відхилено, навіть якщо їх буде прийнято за допомогою --accept-paths.

-u, --unix-socket string

Сокет Unix, на якому буде запущено проксі.

-w, --www string

Також обслуговуватимуться статичні файли із заданої теки з вказаним префіксом.

-P, --www-prefix string     Типово: "/static/"

Префікс для обслуговування статичних файлів, якщо вказано теку зі статичними файлами.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.35 - kubectl replace

Огляд

Заміна ресурсу за назвою файлу або stdin.

Приймаються формати JSON та YAML. Якщо ви замінюєте наявний ресурс, необхідно надати повну специфікацію ресурсу. Її можна отримати за допомогою

kubectl get TYPE NAME -o yaml

kubectl replace -f FILENAME

Приклади

# Замінити pod, використовуючи дані з pod.json
kubectl replace -f ./pod.json

# Замінити pod на основі JSON, переданого в stdin
cat pod.json | kubectl replace -f -

# Оновити версію образу (тег) одноконтейнерного pod до v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

# Примусово замінити, видалити, а потім перестворити ресурс
kubectl replace --force -f ./pod.json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--cascade string[="background"]     Типово: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Podʼів, створених Replication Controller). Стандартне значення — background.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-replace"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлів, яки містять конфігурацію для заміни.

--force

Якщо true, негайно видалити ресурси з API і обійти належне видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Якщо значення відʼємнеі – ігнорується. Встановіть значення 1 для негайного припинення роботи. Можна встановити у 0, лише якщо --force має значення true (примусове видалення).

-h, --help

Довідка replace

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--raw string

Необроблений URI для PUT на сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status scale]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--wait

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.36 - kubectl rollout

Керування розгортанням одного або декількох ресурсів.

Допустимі типи ресурсів включають:

  • deployments
  • daemonsets
  • statefulsets
kubectl rollout SUBCOMMAND

Приклади

# Відкотитись до попереднього deployment
kubectl rollout undo deployment/abc

# Перевірити статус розгортання daemonset
kubectl rollout status daemonset/foo

# Перезапустити deployment
kubectl rollout restart deployment/abc

# Перезапустити deployment з міткою 'app=nginx'
kubectl rollout restart deployment --selector=app=nginx

Параметри

-h, --help

Довідка rollout

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

11.3.36.1 - kubectl rollout history

Огляд

Переглянути попередні версії та конфігурації розгортання.

kubectl rollout history (TYPE NAME | TYPE/NAME) [flags]

Приклади

# Переглянути історію розгортання deployment
kubectl rollout history deployment/abc

# Переглянути деталі daemonset ревізії 3
kubectl rollout history daemonset/abc --revision=3

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка history

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--revision int

Переглянути деталі, включаючи podTemplate вказаної ревізії

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

11.3.36.2 - kubectl rollout pause

Огляд

Позначає вказані ресурси як призупинені.

Призупинені ресурси не будуть узгоджуватися контролером. Щоб відновити роботу призупиненого ресурсу, скористайтеся "kubectl rollout resume". Наразі призупинення підтримується лише у deployment.

kubectl rollout pause RESOURCE

Приклади

# Позначити deployment nginx як призупинений
# Будь-який поточний стан deployment продовжить свою роботу; нові оновлення
# deployment не матимуть ефекту, доки deployment призупинено
kubectl rollout pause deployment/nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-rollout"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка pause

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

11.3.36.3 - kubectl rollout restart

Огляд

Перезапускає ресурс.

Розгортання ресурсів буде перезапущено.

kubectl rollout restart RESOURCE

Приклади

# Перезапустити всі deployment у просторі імен test-namespace
kubectl rollout restart deployment -n test-namespace

# Перезапустіть deployment
kubectl rollout restart deployment/nginx

# Перезапустити набір демонів
kubectl rollout restart daemonset/abc

# Перезапустити deployment з міткою app=nginx
kubectl rollout restart deployment --selector=app=nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-rollout"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка restart

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

11.3.36.4 - kubectl rollout resume

Огляд

Відновити роботу призупиненого ресурсу.

Призупинені ресурси не будуть узгоджуватися контролером. Відновивши ресурс, ми дозволимо йому знову бути узгодженим. Наразі лише deployments підтримують відновлення.

kubectl rollout resume RESOURCE

Приклади

# Відновити роботу призупиненого deployment
kubectl rollout resume deployment/nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-rollout"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка resume

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

11.3.36.5 - kubectl rollout status

Огляд

Показувати статус розгортання.

Стандартно "rollout status" буде стежити за статусом останнього розгортання, доки воно не завершиться. Якщо ви не бажаєте чекати на завершення розгортання, ви можете використати --watch=false. Зауважте, що якщо у проміжку між ними розпочнеться нове розгортання, то "rollout status" продовжуватиме стежити за останньою ревізією. Якщо ви хочете привʼязатися до певної ревізії і перервати процес, якщо його буде перенесено на іншу ревізію, скористайтеся --revision=N, де N — ревізія, за якою ви хочете стежити.

kubectl rollout status (TYPE NAME | TYPE/NAME) [flags]

Приклади

# Перегляд статусу розгортання deployment
kubectl rollout status deployment/nginx

Параметри

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка status

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--revision int

Закріпити за певною ревізією для показу її статусу. Стандартно дорівнює 0 (остання ревізія).

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту

-w, --watch     Типово: true

Відстежувати статус розгортання, доки воно не завершиться.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout — Керування розгортанням ресурсів

11.3.36.6 - kubectl rollout undo

Огляд

Повернення до попереднього розгортання.

kubectl rollout undo (TYPE NAME | TYPE/NAME) [flags]

# Відкотитися до попередньої версії deployment
kubectl rollout undo deployment/abc

# Відкотитися до ревізії 3 daemonset
kubectl rollout undo daemonset/abc --to-revision=3

# Перевірити відкат до попередньої версії за допомогою dry-run
kubectl rollout undo --dry-run=server deployment/abc

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка undo

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--to-revision int

Ревізія для відкату. Стандартно 0 (остання ревізія).

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

11.3.37 - kubectl run

Огляд

Створити та запустити певний образ у Pod.

kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client] [--overrides=inline-json] [--command] -- [COMMAND] [args...]

Приклади

# Запустити pod nginx
kubectl run nginx --image=nginx

# Запустити pod hazelcast і дозволити контейнеру відкривати порт 5701
kubectl run hazelcast --image=hazelcast/hazelcast --port=5701

# Запустити pod hazelcast і встановити змінні середовища "DNS_DOMAIN=cluster" та "POD_NAMESPACE=default" у контейнері
kubectl run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default"

# Запустити pod hazelcast і встановити мітки "app=hazelcast" та "env=prod" у контейнері
kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"

# Імітація запуску; вивести відповідні обʼєкти API без їх створення
kubectl run nginx --image=nginx --dry-run=client

# Запустити pod nginx, але перевантажити spec частковим набором значень, розібраних з JSON
kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'

# Запустити pod busybox і тримати його на передньому плані, не перезапускати його, якщо він завершиться
kubectl run -i -t busybox --image=busybox --restart=Never

# Запустити pod nginx, використовуючи стандартну команду, але використовуючи власні аргументи (arg1 .. argN) для цієї команди
kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN>

# Запустити pod nginx, використовуючи іншу команду та власні аргументи
kubectl run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--annotations strings

Анотації для застосування до pod.

--attach

Якщо значення true, дочекайтеся запуску Pod, а потім приєднайтеся до нього так, ніби було викликано команду 'kubectl attach ...'. Стандартно має значення false, якщо не задано параметр '-i/--stdin', у цьому випадку значення буде true. За допомогою '--restart=Never' повертається код завершення процесу контейнера.

--cascade string[="background"]     Default: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Pods, створених ReplicationController). Стандартно — background.

--command

Якщо присутні істинні та додаткові аргументи, використовуйте їх як поле 'command' у контейнері, а не поле 'args', яке використовується стандартно.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--env strings

Змінні оточення для установки в контейнері.

--expose --port

Якщо значення true, створить сервіс ClusterIP, асоційований з podʼом. Потрібен --port.

--field-manager string     Типово: "kubectl-run"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

імʼя файлу для заміни ресурсу.

--force

Якщо true, негайно видалити ресурси з API і обійти належне видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--grace-period int     Default: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Ігнорується, якщо значення відʼємне. Встановлюється у 1 для негайного завершення роботи. Може бути встановлено у 0, тільки якщо --force має значення true (примусове видалення).

-h, --help

Довідка run

--image string

Назва образу контейнера для запуску.

--image-pull-policy string

Політика отримання образів для контейнера. Якщо залишити порожнім, це значення не буде вказано клієнтом і буде використано сервером стандартна поведінка.

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-l, --labels string

Мітки через кому для застосування до pod. Перевизначить попередні значення.

--leave-stdin-open

Якщо pod запущено в інтерактивному режимі або за допомогою stdin, залиште stdin відкритим після завершення першого приєднання. Типово, stdin буде закрито після завершення першого приєднання.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--override-type string     Типово: "merge"

Метод, який використовується для перевизначення згенерованого обʼєкта: json, merge або strategic.

--overrides string

Вбудоване перевизначення JSON для згенерованого обʼєкта. Якщо він не порожній, то використовується для перевизначення згенерованого обʼєкта. Вимагає, щоб обʼєкт надавав дійсне поле apiVersion.

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

--port string

Порт, який експонує цей контейнер.

--privileged

Якщо true, запустити контейнер у привілейованому режимі.

-q, --quiet

Якщо true, не виводити повідомлення.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--restart string     Типово: "Always"

Політика перезапуску Pod. Підтримувані значення: [Always, OnFailure, Never]

--rm

Якщо значення true, видалити pod після його виходу. Діє лише при приєднанні до контейнера, наприклад, за допомогою '--attach' або '-i/--stdin'.

--save-config

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

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

-i, --stdin

Залишати stdin відкритим на контейнері в pod, навіть якщо до нього нічого не приєднано.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення таймауту залежно від розміру обʼєкта

-t, --tty

Призначити TTY для контейнера в pod.

--wait

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.38 - kubectl scale

Огляд

Встановлення нового розміру для deployment, replica set, replication controller або stateful set.

Scale також дозволяє користувачам вказати одну або декілька передумов для дії масштабування.

Якщо вказано параметр --current-replicas або --resource-version, його буде перевірено перед спробою масштабування, і буде гарантовано, що передумови буде виконано, коли масштабування буде надіслано на сервер.

kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)

Приклади

# Масштабувати replica set з назвою 'foo' до 3
kubectl scale --replicas=3 rs/foo

# Масштабувати ресурс, визначений типом та назвою, вказаними у "foo.yaml", до 3
kubectl scale --replicas=3 -f foo.yaml

# Якщо поточний розмір deployment з назвою mysql дорівнює 2, масштабувати mysql до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

# Масштабування декількох контролерів реплікації
kubectl scale --replicas=5 rc/example1 rc/example2 rc/example3

# Масштабувати stateful set з назвою 'web' до 3
kubectl scale --replicas=3 statefulset/web

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--current-replicas int     Типово: -1

Передумова для поточного розміру. Вимагає, щоб поточний розмір ресурсу відповідав цьому значенню для масштабування. -1 ( стандартно) для відсутності умови.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, якому потрібно задати новий розмір.

-h, --help

Довідка scale

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--replicas int

Нова бажана кількість реплік. Обовʼязково.

--resource-version string

Передумова для версії ресурсу. Вимагає, щоб поточна версія ресурсу відповідала цьому значенню для масштабування./p>

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту. Будь-які інші значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h).

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.39 - kubectl set

Огляд

Налаштування ресурсів застосунку.

Ці команди допоможуть вам внести зміни до наявних ресурсів застосунку.

kubectl set SUBCOMMAND

Параметри

-h, --help

Довідка set

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl set env — Оновити змінні оточення у шаблоні Pod
  • kubectl set image — Оновити образ шаблону Pod
  • kubectl set resources — Оновити запити/ліміти ресурсів у обʼєктів в шаблонах Pod
  • kubectl set selector — Встановити селектор на ресурсі
  • kubectl set serviceaccount — оновити службовий обліковий запис ресурсу
  • kubectl set subject — Оновити обліковий запис користувача, групи або сервісу у привʼязці ролі або привʼязці ролі кластера

11.3.39.1 - kubectl set env

Огляд

Оновити змінні середовища у шаблоні Pod.

Вивести перелік визначення змінних середовища в одному або декількох Pod, шаблонах Pod. Додати, оновити або видалити визначення змінних середовища контейнера в одному або декількох шаблонах Pod (в рамках контролерів реплікації або конфігурацій deployment). Переглянути або змінити визначення змінних середовища у всіх контейнерах у вказаних Pod або шаблонах Pod, або тільки тих, що відповідають шаблону.

Якщо передано "--env -", змінні середовища можуть бути прочитані зі STDIN за допомогою стандартного синтаксису env.

Перелік можливих ресурсів містить (незалежно від регістру):

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

kubectl set env RESOURCE/NAME KEY_1=VAL_1 ... KEY_N=VAL_N

Приклади

# Оновити deployment 'registry' новою змінною середовища
kubectl set env deployment/registry STORAGE_DIR=/local

# Вивести перелік змінних середовища, визначених в deployment 'sample-build'
kubectl set env deployment/sample-build --list

# Вивести перелік змінних середовища, визначених у всіх podʼах
kubectl set env pods --all --list

# Вивести змінений deployment у форматі YAML, не змінюючи обʼєкт на сервері
kubectl set env deployment/sample-build STORAGE_DIR=/data -o yaml

# Оновити всі контейнери у всіх контролерах реплікації в проєкті, додавши змінну середовища ENV=prod
kubectl set env rc --all ENV=prod

# Імпортувати змінні середовища з secret
kubectl set env --from=secret/mysecret deployment/myapp

# Імпортувати змінні середовища з config map з префіксом
kubectl set env --from=configmap/myconfigmap --prefix=MYSQL_ deployment/myapp

# Імпортувати конкретні ключі з config map
kubectl set env --keys=my-example-key --from=configmap/myconfigmap deployment/myapp

# Видалити змінну середовища ENV з контейнера 'c1' у всіх deployment
kubectl set env deployments --all --containers="c1" ENV-

# Видалити змінну середовища ENV з файлу визначення deployment на диску та
# оновити конфігурацію deployment на сервері
kubectl set env -f deploy.json ENV-

# Встановити деякі змінні середовища з локальної оболонки у конфігурацію deployment на сервері
env | grep RAILS_ | kubectl set env -e - deployment/registry

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-c, --containers string     Типово: "*"

Назви контейнерів у вибраних шаблонах pod для зміни, можна використовувати підстановочні знаки

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-e, --env strings

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

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, для оновлення env.

--from string

Імʼя ресурсу, з якого потрібно підʼєднати змінні оточення.

-h, --help

Довідка env

--keys strings

Список ключів через кому для імпорту з вказаного ресурсу

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--list

Якщо встановлено, виводити оточення та будь-які зміни у стандартному форматі. Цей прапорець буде вилучено, коли ми матимемо kubectl view env.

--local

Якщо значення true, set env НЕ звʼязуватиметься з api-serverʼом, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite     Типово: true

Якщо true, дозволити перезапис оточення, інакше відхилити оновлення, які перезаписують існуюче оточення.

--prefix string

Префікс для додавання до імен змінних

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resolve

Якщо true, показувати посилання на secret або configmap під час виведення списку змінних

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

11.3.39.2 - kubectl set image

Огляд

Оновити наявні образи контейнерів ресурсів.

Можливі ресурси включають (не чутливі до регістру):

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N

Приклади

# Встановити образ контейнера nginx в deployment як 'nginx:1.9.1', а образ контейнера busybox на 'busybox'
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1

# Оновити образ контейнера nginx у всіх deployment та контролерах реплікації на 'nginx:1.9.1'
kubectl set image deployments,rc nginx=nginx:1.9.1 --all

# Оновити образи всіх контейнерів у daemonset abc на 'nginx:1.9.1'
kubectl set image daemonset abc *=nginx:1.9.1

# Вивести результат (у форматі yaml) оновлення образу контейнера nginx з локального файлу, без звернення до сервера
kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, для отримання ресурсів з сервера.

-h, --help

Довідка image

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо значення true, set image НЕ звʼязуватиметься з api-serverʼом, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

11.3.39.3 - kubectl set resources

Огляд

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

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

Можливі ресурси включають (незалежно від регістру): Використовуйте "kubectl api-resources" для повного списку підтримуваних ресурсів.

kubectl set resources (-f FILENAME | TYPE NAME)  ([--limits=LIMITS & --requests=REQUESTS]

Приклади

# Встановити межі використання ЦП для контейнера nginx у deployment на "200m" та памʼяті на "512Mi"
kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi

# Встановити запити та межі ресурсів для всіх контейнерів у deployment nginx
kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

# Видалити запити ресурсів для контейнерів у deployment nginx
kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0

# Вивести результат (у форматі yaml) оновлення меж використання ресурсів для контейнера nginx з локального файлу, без звернення до сервера
kubectl set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-c, --containers string     Типово: "*"

Назви контейнерів у вибраних шаблонах pod для зміни, стандартно вибрані всі контейнери, можна використовувати підстановочні знаки

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, для отримання ресурсів з сервера.

-h, --help

Довідка resources

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--limits string

Вимоги до ресурсів для цього контейнера. Наприклад, 'cpu=100m,memory=256Mi'. Зверніть увагу, що серверні компоненти можуть призначати запити залежно від конфігурації сервера, наприклад, граничних діапазонів.

--local

Якщо значення true, set resources НЕ звʼязуватиметься з api-serverʼом, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--requests string

Вимоги до ресурсів для цього контейнера. Наприклад, 'cpu=100m,memory=256Mi'. Зверніть увагу, що серверні компоненти можуть призначати запити залежно від конфігурації сервера, наприклад, граничних діапазонів.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

11.3.39.4 - kubectl set selector

Огляд

Встановити селектор на ресурс. Зауважте, що новий селектор замінить старий, якщо ресурс вже мав селектор перед викликом команди 'set selector'.

Селектор повинен починатися з літери або цифри та може містити літери, цифри, дефіси, крапки та підкреслення, до 63 символів. Якщо вказано --resource-version, оновлення використовуватимуть цю версію ресурсу, інакше використовуватиметься наявна версія ресурсу. Примітка: зараз селектори можна встановлювати лише на обʼєкти типу Service.

kubectl set selector (-f FILENAME | TYPE NAME) EXPRESSIONS [--resource-version=version]

Приклади

# Встановіть мітки і селектор перед створенням пари deployment/service
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -

kubectl create deployment my-dep -o yaml --dry-run=client | kubectl label --local -f - environment=qa -o yaml | kubectl create -f -

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс.

-h, --help

Довідка selector

--local

Якщо значення true, анотація НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive     Типово: true

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resource-version string

Якщо значення не порожнє, оновлення селекторів буде успішним, тільки якщо це поточна версія ресурсу для обʼєкта. Дійсно тільки при вказівці одного ресурсу.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

11.3.39.5 - kubectl set serviceaccount

Огляд

Оновлення службового облікового запису ресурсів шаблону pod.

Можливі ресурси (нечутливі до регістру) можуть бути такими:

replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset

kubectl set serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT

Приклади

# Встановити службовий обліковий запис nginx-deployment у serviceaccount1
kubectl set serviceaccount deployment nginx-deployment serviceaccount1

# Вивести результат (у форматі YAML) оновленого deployment nginx з службовим обліковим записом з локального файлу, не звертаючись до сервера API
kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run=client -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для отримання з сервера.

-h, --help

Довідка serviceaccount

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо значення true, set serviceaccount НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

11.3.39.6 - kubectl set subject

Огляд

Оновлює user, group або service account в обʼєкті RoleBinding або ClusterRoleBinding.

kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Оновлення привʼязки кластерних ролей для serviceaccount1
kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1

# Оновлення привʼязки ролей для user1, user2 і group1
kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1

# Вивести результат (у форматі YAML) оновлення субʼєктів привʼязки ролей локально, без звернення до сервера
kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурси для оновлення.

--group strings

Групи для привʼязки до ролі.

-h, --help

Довідка subject

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо значення true, set subject НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--serviceaccount strings

Службові облікові записи для привʼязки до ролі.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--user strings

Імена користувачів для привʼязки до ролі.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

11.3.40 - kubectl taint

Огляд

Оновлення taint на одному або декількох вузлах.

  • Taint складається з ключа, значення та ефекту. Як аргумент тут він має вигляд ключ=значення:ефект.
  • Ключ повинен починатися з літери або цифри і може містити літери, цифри, дефіси, крапки і підкреслення, до 253 символів.
  • За бажанням, ключ може починатися з префікса субдомену DNS і одного символу "/", наприклад, example.com/my-app.
  • Значення не є обовʼязковим. Якщо вказано, воно повинно починатися з літери або цифри і може містити літери, цифри, дефіси, крапки та символи підкреслення (до 63 символів).
  • Ефект має бути NoSchedule, PreferNoSchedule або NoExecute.
  • Наразі taint може бути застосовано лише до вузла.
kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N

Приклади

# Оновити вузол 'foo', додавши taint з ключем 'dedicated', значенням 'special-user' та ефектом 'NoSchedule'
# Якщо taint з цим ключем та ефектом вже існує, його значення буде замінено на вказане
kubectl taint nodes foo dedicated=special-user:NoSchedule

# Видалити з вузла 'foo' taint з ключем 'dedicated' та ефектом 'NoSchedule', якщо він існує
kubectl taint nodes foo dedicated:NoSchedule-

# Видалити з вузла 'foo' всі taint з ключем 'dedicated'
kubectl taint nodes foo dedicated-

# Додати taint з ключем 'dedicated' на вузли, що мають мітку myLabel=X
kubectl taint node -l myLabel=X dedicated=foo:PreferNoSchedule

# Додати до вузла 'foo' taint з ключем 'bar' без значення
kubectl taint nodes foo bar:NoSchedule

Параметри

--all

Вибрати всі вузли в кластері

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-taint"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка taint

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite

Якщо true, дозволити перезапис taint, інакше відхиляти оновлення taint, які перезаписують наявні taint.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.41 - kubectl top

Огляд

Показує використання ресурсів (CPU, памʼять).

Команда top дозволяє вам спостерігати за використанням ресурсів вузлами та Podʼами.

Ця команда вимагає наявності працюючого та налаштованого Metrics Server в кластері.

kubectl top [flags]

Параметри

-h, --help

Довідка top

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl top node — Показати використання ресурсів (процесор/памʼять) вузлами
  • kubectl top pod — Показувати використання ресурсів (процесора/памʼять) Podʼами

11.3.41.1 - kubectl top node

Огляд

Показати використання ресурсів (процесор/памʼять) вузлами.

Команда top-node дозволяє переглядати використання ресурсів вузлами кластера.

kubectl top node [NAME | -l label]

Приклади

# Показати метріки для всіх вузлівShow metrics for all nodes
kubectl top node

# Показати метріки для вузла NODE_NAME
kubectl top node NODE_NAME

Параметри

-h, --help

Довідка node

--no-headers

Якщо присутній, то виводити без заголовків.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-capacity

Вивести ресурси вузлів на основі Capacity замість Allocatable (стандартно) для вузлів.

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Поле може мати значення 'cpu' або 'memory'.

--use-protocol-buffers     Типово: true

Дозволяє використовувати протокол-буфери для доступу до API Metrics.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl top — Показ використання ресурсів (CPU/памʼять)

11.3.41.2 - kubectl top pod

Огляд

Показувати використання ресурсів (процесора/памʼять) pod'ами

Команда 'top pod' дозволяє вам переглядати використання ресурсів (процесора/памʼяті) podʼами.

Через затримку конвеєра метрик, вони можуть бути недоступні протягом декількох хвилин з моменту створення podʼів.

kubectl top pod [NAME | -l label]

Приклади

# Показати метрики для всіх podʼів у стандартному просторі імен
kubectl top pod

# Показати метрики для всіх podʼів у вказаному просторі імен
kubectl top pod --namespace=NAMESPACE

# Показати метрики для вказаного podʼа та його контейнерів
kubectl top pod POD_NAME --containers

# Показати метрики для podʼів, визначених міткою name=myLabel
kubectl top pod -l name=myLabel

Параметри

-A, --all-namespaces

Якщо вказано, вивести перелік запитуваних обʼєктів у всіх просторах назв. Простір назв у поточному контексті ігнорується, навіть якщо вказано --namespace.

--containers

Якщо є, показати використання контейнерів в межах pod.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-h, --help

Довідка pod

--no-headers

Якщо присутній, то виводити без заголовків.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Поле може мати значення 'cpu' або 'memory'.

--sum

Вивести сумарне використання ресурсів

--use-protocol-buffers     Типово: true

Дозволяє використовувати протокол-буфери для доступу до API Metrics.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl top — Показ використання ресурсів (CPU/памʼять)

11.3.42 - kubectl uncordon

Огляд

Позначає вузол як готовий для планування.

kubectl uncordon NODE

Приклади

# Позначити вузол "foo" як готовий для планування
kubectl uncordon foo

Параметри

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-h, --help

Довідка uncordon

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.43 - kubectl version

Огляд

Вивести інформацію про версії клієнта та сервера для поточного контексту.

kubectl version [flags]

Приклади

# Вивести версії клієнта та сервера для поточного контексту
kubectl version

Параметри

--client

Якщо true, показує лише клієнтську версію (server не вимагається).

-h, --help

Довідка version

-o, --output string

Формат виводу. Один з: (json, yaml).

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.3.44 - kubectl wait

Огляд

Експериментально: Очікувати на певний стан одного чи кількох ресурсів.

Команда бере кілька ресурсів і чекає, доки у полі стану кожного з них не зʼявиться вказана умова.

Крім того, команда може чекати на видалення заданого набору ресурсів, вказавши ключове слово "delete" як значення прапорця --for.

Успішне повідомлення буде виведено у stdout із зазначенням того, що вказану умову було виконано. Ви можете скористатися опцією -o, щоб змінити місце виведення.

kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available|--for=jsonpath='{}'[=value]]

Приклади

# Очікувати, поки Pod "busybox1" не міститиме умови статусу типу "Ready"
kubectl wait --for=condition=Ready pod/busybox1

# Типове значення умови статусу є true; ви можете очікувати на інші значення після знаку рівності (порівнюється після простого складання Unicode, яке є загальнішою формою нечутливості до регістру)
kubectl wait --for=condition=Ready=false pod/busybox1

# Очікувати, поки Pod "busybox1" не міститиме фази статусу "Running"
kubectl wait --for=jsonpath='{.status.phase}'=Running pod/busybox1

# Очікувати, поки Pod "busybox1" не буде в стані Ready
kubectl wait --for='jsonpath={.status.conditions[?(@.type=="Ready")].status}=True' pod/busybox1

# Очікувати, поки сервіс "loadbalancer" не матиме ingress
kubectl wait --for=jsonpath='{.status.loadBalancer.ingress}' service/loadbalancer

# Очікувати, поки Pod "busybox1" не буде видалено, з таймаутом 60с, після виконання команди "delete"
kubectl delete pod/busybox1
kubectl wait --for=delete pod/busybox1 --timeout=60s

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

-A, --all-namespaces

Якщо вказано, вивести перелік запитуваних обʼєктів у всіх просторах імен. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурси.

--for string

Умова для очікування: [delete|condition=ім' condition-name[=condition-value]|jsonpath='{JSONPath expression}'=[JSONPath value]]. Стандартне значення condition-value дорівнює true. Значення умови порівнюються після простого згортання регістру Unicode, що є більш загальною формою нечутливості до регістру.

-h, --help

Довідка wait

--local

Якщо значення true, НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration     Типово: 30s

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту

Параметри батьківських команд

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

11.4 - Команди kubectl

Довідник команд kubectl

11.5 - kubectl

Огляд

kubectl керує менеджером кластерів Kubernetes.

Додаткову інформацію можна знайти в розділі Інструмент командного рядка (kubectl).

kubectl [flags]

Параметри

--add-dir-header
Якщо true, додає теку файлу до заголовка повідомлень логу
--alsologtostderr
писати лог до standard error, а також в файл
--as string

Імʼя користувача, яке використовується для виконання операції.

--as-group stringArray
Назва групи, яка використовується для виконання операції, цей прапорець можна повторити, щоб вказати кілька груп.
--azure-container-registry-config string
Шлях до файлу, що містить інформацію про конфігурацію реєстру контейнера Azure.
--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cloud-provider-gce-l7lb-src-cidrs cidrs     Типово: 130.211.0.0/22,35.191.0.0/16

CIDR, відкриті в фаєврволі GCE для трафіку L7 LB та перевірок стану

--cloud-provider-gce-lb-src-cidrs cidrs     Типово: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16

CIDR, відкриті в фаєврволі GCE для трафіку L4 LB та перевірок стану

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

-h, --help

Довідка kubectl

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--log-backtrace-at traceLocation     Default: :0
коли логування попадаж в рядок file:N, видавати trace стека
--log-dir string
Якщо не порожньо, записати лог-файли в цю теку
--log-file string
Якщо не порожньо, використовувати цей файл
--log-file-max-size uint     Типово: 1800
Визначає максимальний розмір, до якого може вирости файл логу. Одиниця виміру — мегабайти. Якщо значення дорівнює 0, максимальний розмір файлу необмежений.
--log-flush-frequency duration     Типово: 5s
Максимальна кількість секунд між очищеннями журналу
--logtostderr     Типово: true
писати лог в standard error, а не у файл
--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--one-output
Якщо true, записувати логи лише до їхнього власного рівня важливості (замість того, щоб записувати до кожного нижчого рівня важливості)
--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--skip-headers
Якщо true, уникати префіксів заголовків у повідомленнях логу
--skip-log-headers
Якщо true, уникати заголовків при відкритті файлів логів
--stderrthreshold severity     Типово: 2
логи, що дорівнюють або перевищують цей поріг, потрапляють до stderr
--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

-v, --v Level
число рівня повноти записів логу
--version version[=true]

Вивести інформацію про версію та вийти

--vmodule moduleSpec
список параметрів pattern=N, розділених комами, для файл-фільтрованого логування.
--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Змінні оточення

KUBECONFIG
Шлях до файлу конфігурації kubectl ("kubeconfig"). Типово: "$HOME/.kube/config"
KUBECTL_COMMAND_HEADERS
Якщо встановлено false, вимикає додаткові HTTP заголовки, що деталізують виконану команду kubectl (версія Kubernetes v1.22 або пізніше)
KUBECTL_DEBUG_CUSTOM_PROFILE
Якщо встановлено true, у kubectl debug буде активовано спеціальний прапорець. Цей прапорець використовується для налаштування заздалегідь визначених профілів.
KUBECTL_EXPLAIN_OPENAPIV3
Вмикає чи вимикає використання нового джерела даних OpenAPIv3 для викликів `kubectl explain`. OpenAPIV3 типово увімкнено з версії Kubernetes 1.24.
KUBECTL_ENABLE_CMD_SHADOW
Якщо встановлено true, зовнішні втулки можна використовувати як субкоманди для вбудованих команд, якщо субкоманда не існує. На альфа-стадії ця функція може бути використана лише для команди create (наприклад, kubectl create networkpolicy).
KUBECTL_PORT_FORWARD_WEBSOCKETS
Якщо встановлено true, команда kubectl port-forward спробує передавати дані, використовуючи протокол веб-сокетів. Якщо перехід до веб-сокетів не вдасться, команди повернуться до використання поточного протоколу SPDY.
KUBECTL_REMOTE_COMMAND_WEBSOCKETS
Якщо встановлено true, команди kubectl exec, cp та attach спробують передавати дані, використовуючи протокол веб-сокетів. Якщо перехід до веб-сокетів не вдасться, команди повернуться до використання поточного протоколу SPDY.

Дивіться також

  • kubectl annotate — Оновити анотації на ресурсі
  • kubectl api-resources — Вивести підтримувані API ресурси на сервері
  • kubectl api-versions — Вивести підтримувані API версії на сервері у форматі "група/версія"
  • kubectl apply — Застосувати конфігурацію до ресурсу за імʼям файлу або через stdin
  • kubectl attach — Приєднатися до працюючого контейнера
  • kubectl auth — Перевірити авторизацію
  • kubectl autoscale — Автоматичне масштабування Deployment, ReplicaSet або ReplicationController
  • kubectl certificate — Змінити ресурси сертифікатів
  • kubectl cluster-info — Показати інформацію про кластер
  • kubectl completion — Вивести код автодоповнення для зазначеної оболонки (bash або zsh)
  • kubectl config — Змінити kubeconfig файли
  • kubectl cordon — Позначити вузол як недоступний для планування
  • kubectl cp — Копіювати файли та теки до і з контейнерів
  • kubectl create — Створити ресурс з файлу або stdin
  • kubectl debug — Створити сесії налагодження для виправлення неполадок з робочими навантаженнями та вузлами
  • kubectl delete — Видалити ресурси за допомогою імен файлів, stdin, ресурсів і назв або за допомогою ресурсів і селектора міток
  • kubectl describe — Показати деталі конкретного ресурсу або групи ресурсів
  • kubectl diff — Порівняти живу версію з потенційною версією, яку може бути застосовано
  • kubectl drain — Спорожнити вузол перед обслуговуванням
  • kubectl edit — Редагувати ресурс на сервері
  • kubectl events — Список подій
  • kubectl exec — Виконати команду в контейнері
  • kubectl explain — Документація по ресурсах
  • kubectl expose — Експонувати новий сервіс Kubernetes з replication controller, service, deployment чи pod
  • kubectl get — Показати один або кілька ресурсів
  • kubectl kustomize — Створити kustomization з теки або віддаленого URL
  • kubectl label — Оновити мітки на ресурсі
  • kubectl logs — Вивести логи для контейнера в pod
  • kubectl options — Вивести список прапорців, успадкованих усіма командами
  • kubectl patch — Оновити поле(я) ресурсу
  • kubectl plugin — Надає утиліти для взаємодії з dnekrfvb
  • kubectl port-forward — Gthtyfghfdkznb один або кілька локальних портів до pod
  • kubectl proxy — Запустити проксі до Kubernetes API сервера
  • kubectl replace — Замінити ресурс за імʼям файлу або stdin
  • kubectl rollout — Керувати розгортанням ресурсу
  • kubectl run — Запустити вказаний образ на кластері
  • kubectl scale — Встановити новий розмір для Deployment, ReplicaSet або Replication Controller
  • kubectl set — Встановити конкретні функції на обʼєктах
  • kubectl taint — Оновити taint на одному або кількох вузлах
  • kubectl top — Показати використання ресурсів (CPU/Памʼять/Зберігання)
  • kubectl uncordon — Позначити вузол як доступний для планування
  • kubectl version — Вивести інформацію про клієнтську та серверну версії
  • kubectl wait — Експериментально: Чекати на конкретну умову для одного або кількох ресурсів

11.6 - Підтримка JSONPath

Kubectl підтримує шаблони JSONPath.

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

  1. Використовуйте подвійні лапки для цитування тексту всередині виразів JSONPath.
  2. Використовуйте оператори range, end для ітерації списків.
  3. Використовуйте відʼємні індекси зрізу для кроку назад через список. Відʼємні індекси не "обгортають" список і є дійсними, поки -index + listLength >= 0.
{
  "kind": "List",
  "items":[
    {
      "kind":"None",
      "metadata":{
        "name":"127.0.0.1",
        "labels":{
          "kubernetes.io/hostname":"127.0.0.1"
        }
      },
      "status":{
        "capacity":{"cpu":"4"},
        "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
      }
    },
    {
      "kind":"None",
      "metadata":{"name":"127.0.0.2"},
      "status":{
        "capacity":{"cpu":"8"},
        "addresses":[
          {"type": "LegacyHostIP", "address":"127.0.0.2"},
          {"type": "another", "address":"127.0.0.3"}
        ]
      }
    }
  ],
  "users":[
    {
      "name": "myself",
      "user": {}
    },
    {
      "name": "e2e",
      "user": {"username": "admin", "password": "secret"}
    }
  ]
}
ФункціяОписПрикладРезультат
textзвичайний текстkind is {.kind}kind is List
@поточний обʼєкт{@}той самий, що й вхід
. або []оператор доступу до дочірніх елементів{.kind}, {['kind']} або {['name\.type']}List
..рекурсивний спуск{..name}127.0.0.1 127.0.0.2 myself e2e
*універсальний символ. Отримати всі обʼєкти{.items[*].metadata.name}[127.0.0.1 127.0.0.2]
[start:end:step]оператор індексу{.users[0].name}myself
[,]оператор обʼєднання{.items[*]['metadata.name', 'status.capacity']}127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
?()фільтр{.users[?(@.name=="e2e")].user.password}secret
range, endітерація списку{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
''інтерпретований рядок з лапками{range .items[*]}{.metadata.name}{'\t'}{end}127.0.0.1 127.0.0.2
\символ екранування{.items[0].metadata.labels.kubernetes\.io/hostname}127.0.0.1

Приклади використання kubectl та виразів JSONPath:

kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
kubectl get pods -o=jsonpath='{.items[0].metadata.labels.kubernetes\.io/hostname}'

11.7 - kubectl для користувачів Docker

Ви можете використовувати інструмент командного рядка Kubernetes kubectl для взаємодії з сервером API. Використання kubectl є простим, якщо ви знайомі з інструментом командного рядка Docker. Однак, існує декілька відмінностей між командами Docker і командами kubectl. У наступних розділах показано субкоманду Docker та опис еквівалентної команди kubectl.

docker run

Щоб запустити Deployment nginx і експонувати Deployment, див. kubectl create deployment.

docker:

docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx

55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db

docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   9 seconds ago       Up 9 seconds        0.0.0.0:80->80/tcp   nginx-app

kubectl:

# запуск pod з nginx
kubectl create deployment --image=nginx nginx-app

deployment.apps/nginx-app created

# додати env до nginx-app
kubectl set env deployment/nginx-app  DOMAIN=cluster

deployment.apps/nginx-app env updated

# експонування порта через service
kubectl expose deployment nginx-app --port=80 --name=nginx-http

service "nginx-http" exposed

За допомогою kubectl ви можете створити Deployment, щоб переконатися, що N Podʼів працюють під управлінням nginx, де N — це кількість реплік, вказана у специфікації, типово дорівнює 1. Ви також можете створити Service з селектором, який відповідає міткам Podʼів. Докладні відомості наведено у статті Використання Service для доступу до застосунку у кластері.

Стандартно образи запускаються у фоновому режимі, подібно до docker run -d .... Щоб запустити щось на передньому плані, скористайтеся kubectl run для створення Pod:

kubectl run [-i] [--tty] --attach <name> --image=<image>

На відміну від docker run ..., якщо ви вкажете --attach, то приєднаєте stdin, stdout і stderr. Ви не можете контролювати, які саме потоки буде приєднано (docker -a ...). Щоб відʼєднатися від контейнера, ви можете використатись комбінацією клавіш Ctrl+P, а потім Ctrl+Q.

docker ps

Для виводу переліку того, що працює, скористайтеся командою kubectl get:

docker:

docker ps -a

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                     PORTS                NAMES
14636241935f        ubuntu:16.04        "echo test"              5 seconds ago        Exited (0) 5 seconds ago                        cocky_fermi
55c103fa1296        nginx               "nginx -g 'daemon of…"   About a minute ago   Up About a minute          0.0.0.0:80->80/tcp   nginx-app

kubectl:

kubectl get po

NAME                        READY     STATUS      RESTARTS   AGE
nginx-app-8df569cb7-4gd89   1/1       Running     0          3m
ubuntu                      0/1       Completed   0          20s

docker attach

Щоб приєднати процес, який вже запущено у контейнері, див. kubectl attach.

docker:

docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   5 minutes ago       Up 5 minutes        0.0.0.0:80->80/tcp   nginx-app

docker attach 55c103fa1296
...

kubectl:

kubectl get pods

NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m

kubectl attach -it nginx-app-5jyvm
...

Щоб відʼєднатися від контейнера, ви можете скористатись комбінацією клавіш Ctrl+P, а потім Ctrl+Q.

docker exec

Щоб виконати команду у контейнері, див. kubectl exec.

docker:

docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   6 minutes ago       Up 6 minutes        0.0.0.0:80->80/tcp   nginx-app

docker exec 55c103fa1296 cat /etc/hostname

55c103fa1296

kubectl:

kubectl get po

NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m

kubectl exec nginx-app-5jyvm -- cat /etc/hostname

nginx-app-5jyvm

Використання інтерактивних команд.

docker:

docker exec -ti 55c103fa1296 /bin/sh
# exit

kubectl:

kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit

Докладнішу інформацію наведено у статті Отримання доступу до оболонки запущеного контейнера.

docker logs

Щоб переглянути stdout/stderr запущеного процесу, див. kubectl logs.

docker:

docker logs -f a9e

192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"

kubectl:

kubectl logs -f nginx-app-zibvs

10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

Існує невелика різниця між Podʼами та контейнерами; стандартно Podʼи не завершують роботу, якщо їхні процеси завершуються. Замість цього вони перезапускають процес. Це схоже на параметр запуску docker --restart=always з однією суттєвою відмінністю. У docker вивід для кожного виклику процесу обʼєднується, а у Kubernetes кожен виклик є окремим. Щоб переглянути результати попереднього запуску у Kubernetes, зробіть так:

kubectl logs --previous nginx-app-zibvs

10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

Для отримання додаткової інформації див. Архітектура логування.

docker stop та docker rm

Щоб зупинити і видалити запущений процес, див. kubectl delete.

docker:

docker ps

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                         NAMES
a9ec34d98787        nginx               "nginx -g 'daemon of"  22 hours ago        Up 22 hours         0.0.0.0:80->80/tcp, 443/tcp   nginx-app

docker stop a9ec34d98787

a9ec34d98787

docker rm a9ec34d98787

a9ec34d98787

kubectl:

kubectl get deployment nginx-app

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx-app    1/1     1            1           2m

kubectl get po -l app=nginx-app

NAME                         READY     STATUS    RESTARTS   AGE
nginx-app-2883164633-aklf7   1/1       Running   0          2m

kubectl delete deployment nginx-app

deployment "nginx-app" deleted

kubectl get po -l app=nginx-app
# Нічого не повертає

docker login

У kubectl немає прямого аналога docker login. Якщо вас цікавить використання Kubernetes з приватним реєстром, див. Використання приватного реєстру.

docker version

Щоб отримати версії клієнта і сервера, див. kubectl version.

docker:

docker version

Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

kubectl:

kubectl version

Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

docker info

Для отримання різноманітної інформації про середовище та конфігурацію див. kubectl cluster-info.

docker:

docker info

Containers: 40
Images: 168
Storage Driver: aufs
 Root Dir: /usr/local/google/docker/aufs
 Backing Filesystem: extfs
 Dirs: 248
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support

kubectl:

kubectl cluster-info

Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy

11.8 - Правила використання kubectl

Рекомендовані правила використання kubectl.

Використання kubectl у багаторазових скриптах

Для стабільного виводу у скрипті:

  • Використовуйте одну з машинно-орієнтованих форм виводу, таких як -o name, -o json, -o yaml, -o go-template, або -o jsonpath.
  • Повністю вказуйте версію. Наприклад, jobs.v1.batch/myjob. Це гарантує, що kubectl не використовуватиме свою стандартну версію, яка може змінюватися з часом.
  • Не покладайтеся на контекст, налаштування або інші неявні стани.

Субресурси

  • Ви можете використовувати бета-прапорець --subresource для команд kubectl, таких як get, patch, edit та replace для отримання та оновлення субресурсів для всіх ресурсів, які їх підтримують. На цей момент підтримуються лише субресурси status та scale.
    • Для kubectl edit, субресурс scale не підтримується. Якщо ви використовуєте --subresource з kubectl edit і вказуєте scale як субресурс, команда викличе помилку.
  • Контракт API для субресурсу ідентичний до повного ресурсу. Оновлюючи субресурс status до нового значення, майте на увазі, що субресурс може бути потенційно узгоджений контролером до іншого значення.

Рекомендації

kubectl run

Для того, щоб kubectl run відповідав принципу інфраструктури як код:

  • Присвойте образу версію зі специфічним теґом і не переносіть цей теґ на нову версію. Наприклад, використовуйте :v1234, v1.2.3, r03062016-1-4, а не :latest (Для отримання додаткової інформації дивіться Поради щодо конфігурації).
  • Перевірте в скрипті наявність образу з великою кількістю параметрів.
  • Перейдіть до файлів конфігурації, перевірених у контролі вихідного коду, для отримання можливостей, які є необхідними, але не можуть бути виражені за допомогою прапорців kubectl run.

Ви можете використовувати прапорець --dry-run=client, щоб переглянути обʼєкт, який буде відправлений до вашого кластера, без реального його надсилання.

kubectl apply

  • Ви можете використовувати kubectl apply для створення або оновлення ресурсів. Для отримання додаткової інформації про використання kubectl apply для оновлення ресурсів, дивіться Kubectl Book.

12 - Компоненти інструментів

12.1 - Функціональні можливості

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

Дивіться функціональні стадії для пояснення стадій функції.

Огляд

Функціональні можливості — це набір пар ключ=значення, які описують функції Kubernetes. Ви можете увімкнути або вимкнути ці функції, використовуючи прапорець командного рядка --feature-gates на кожному компоненті Kubernetes.

Кожен компонент Kubernetes дозволяє вам увімкнути або вимкнути набір функціональних можливостей, які стосуються цього компонента. Використовуйте прапорець -h, щоб побачити повний набір функціональних можливостей для всіх компонентів. Щоб встановити функціональні можливості для компонента, такого як kubelet, використовуйте прапорець --feature-gates, призначений для списку пар функцій:

--feature-gates=...,GracefulNodeShutdown=true

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

Функціональні можливості для функцій Alpha або Beta

Функціональні можливості для функцій у стані Alpha або Beta
ВластивістьСтандартноСтадіяПочинаючи зДо
AnonymousAuthConfigurableEndpointsfalseAlpha1.31–
AnyVolumeDataSourcefalseAlpha1.181.23
AnyVolumeDataSourcetrueBeta1.24–
APIResponseCompressionfalseAlpha1.71.15
APIResponseCompressiontrueBeta1.16–
APIServerIdentityfalseAlpha1.201.25
APIServerIdentitytrueBeta1.26–
APIServerTracingfalseAlpha1.221.26
APIServerTracingtrueBeta1.27–
AuthorizeNodeWithSelectorsfalseAlpha1.31–
AuthorizeWithSelectorsfalseAlpha1.31–
CloudControllerManagerWebhookfalseAlpha1.27–
ClusterTrustBundlefalseAlpha1.27–
ClusterTrustBundleProjectionfalseAlpha1.29–
ComponentSLIsfalseAlpha1.261.26
ComponentSLIstrueBeta1.27–
ConsistentListFromCachefalseAlpha1.281.30
ConsistentListFromCachetrueBeta1.31–
ContainerCheckpointfalseAlpha1.251.29
ContainerCheckpointtrueBeta1.30–
ContextualLoggingfalseAlpha1.24–
ContextualLoggingtrueBeta1.30–
CoordinatedLeaderElectionfalseAlpha1.31–
CPUManagerPolicyAlphaOptionsfalseAlpha1.23–
CPUManagerPolicyBetaOptionstrueBeta1.23–
CPUManagerPolicyOptionsfalseAlpha1.221.22
CPUManagerPolicyOptionstrueBeta1.23–
CRDValidationRatchetingfalseAlpha1.281.29
CRDValidationRatchetingtrueBeta1.30–
CronJobsScheduledAnnotationtrueBeta1.28–
CrossNamespaceVolumeDataSourcefalseAlpha1.26–
CSIMigrationPortworxfalseAlpha1.231.24
CSIMigrationPortworxfalseBeta1.25–
CSIVolumeHealthfalseAlpha1.21–
CustomCPUCFSQuotaPeriodfalseAlpha1.12–
CustomResourceFieldSelectorsfalseAlpha1.301.30
CustomResourceFieldSelectorstrueBeta1.31–
DisableCloudProvidersfalseAlpha1.221.28
DisableCloudProviderstrueBeta1.29–
DisableKubeletCloudCredentialProvidersfalseAlpha1.231.28
DisableKubeletCloudCredentialProviderstrueBeta1.29–
DisableNodeKubeProxyVersionfalseAlpha1.291.30
DisableNodeKubeProxyVersiontrueBeta1.31–
DRAControlPlaneControllerfalseAlpha1.26–
DynamicResourceAllocationfalseAlpha1.30–
EventedPLEGfalseAlpha1.25–
GracefulNodeShutdownfalseAlpha1.201.20
GracefulNodeShutdowntrueBeta1.21–
GracefulNodeShutdownBasedOnPodPriorityfalseAlpha1.231.23
GracefulNodeShutdownBasedOnPodPrioritytrueBeta1.24–
HonorPVReclaimPolicyfalseAlpha1.231.30
HonorPVReclaimPolicytrueBeta1.31–
HPAScaleToZerofalseAlpha1.16–
ImageMaximumGCAgefalseAlpha1.291.29
ImageMaximumGCAgetrueBeta1.30–
ImageVolumefalseAlpha1.31–
InPlacePodVerticalScalingfalseAlpha1.27–
InTreePluginPortworxUnregisterfalseAlpha1.23–
JobBackoffLimitPerIndexfalseAlpha1.281.28
JobBackoffLimitPerIndextrueBeta1.29–
JobManagedByfalseAlpha1.30–
JobPodReplacementPolicyfalseAlpha1.281.28
JobPodReplacementPolicytrueBeta1.29–
JobSuccessPolicyfalseAlpha1.301.30
JobSuccessPolicytrueBeta1.31–
KubeletCgroupDriverFromCRIfalseAlpha1.281.30
KubeletCgroupDriverFromCRItrueBeta1.31–
KubeletInUserNamespacefalseAlpha1.22–
KubeletPodResourcesDynamicResourcesfalseAlpha1.27–
KubeletPodResourcesDynamicResourcesfalseAlpha1.27–
KubeletPodResourcesGetfalseAlpha1.27–
KubeletSeparateDiskGCfalseAlpha1.291.30
KubeletSeparateDiskGCtrueBeta1.31–
KubeletTracingfalseAlpha1.251.26
KubeletTracingtrueBeta1.27–
LoadBalancerIPModefalseAlpha1.291.30
LoadBalancerIPModetrueBeta1.30–
LocalStorageCapacityIsolationFSQuotaMonitoringfalseAlpha1.151.30
LocalStorageCapacityIsolationFSQuotaMonitoringfalseBeta1.31–
LoggingAlphaOptionsfalseAlpha1.24–
LoggingBetaOptionstrueBeta1.24–
MatchLabelKeysInPodAffinityfalseAlpha1.291.30
MatchLabelKeysInPodAffinitytrueBeta1.31–
MatchLabelKeysInPodTopologySpreadfalseAlpha1.251.26
MatchLabelKeysInPodTopologySpreadtrueBeta1.27–
MaxUnavailableStatefulSetfalseAlpha1.24–
MemoryManagerfalseAlpha1.211.21
MemoryManagertrueBeta1.22–
MemoryQoSfalseAlpha1.22–
MultiCIDRServiceAllocatorfalseAlpha1.271.30
MultiCIDRServiceAllocatorfalseBeta1.31–
MutatingAdmissionPolicyfalseAlpha1.30–
NFTablesProxyModefalseAlpha1.291.30
NFTablesProxyModetrueBeta1.31–
NodeInclusionPolicyInPodTopologySpreadfalseAlpha1.251.25
NodeInclusionPolicyInPodTopologySpreadtrueBeta1.26–
NodeLogQueryfalseAlpha1.271.29
NodeLogQueryfalseBeta1.30–
NodeSwapfalseAlpha1.221.27
NodeSwapfalseBeta1.281.29
NodeSwaptrueBeta1.30–
OpenAPIEnumsfalseAlpha1.231.23
OpenAPIEnumstrueBeta1.24–
PodAndContainerStatsFromCRIfalseAlpha1.23–
PodDeletionCostfalseAlpha1.211.21
PodDeletionCosttrueBeta1.22–
PodIndexLabeltrueBeta1.28–
PodLifecycleSleepActionfalseAlpha1.291.29
PodLifecycleSleepActiontrueBeta1.30–
PodReadyToStartContainersConditionfalseAlpha1.281.28
PodReadyToStartContainersConditiontrueBeta1.29–
PortForwardWebsocketsfalseAlpha1.301.30
PortForwardWebsocketstrueBeta1.31–
ProcMountTypefalseAlpha1.12–
QOSReservedfalseAlpha1.11–
RecoverVolumeExpansionFailurefalseAlpha1.23–
RecursiveReadOnlyMountsfalseAlpha1.301.30
RecursiveReadOnlyMountstrueBeta1.31–
RelaxedEnvironmentVariableValidationfalseAlpha1.30–
ResilientWatchCacheInitializationtrueBeta1.31–
ResourceHealthStatusfalseAlpha1.31–
RetryGenerateNamefalseAlpha1.30–
RetryGenerateNamefalseAlpha1.30–
RotateKubeletServerCertificatefalseAlpha1.71.11
RotateKubeletServerCertificatetrueBeta1.12–
RuntimeClassInImageCriApifalseAlpha1.29–
SchedulerQueueingHintstrueBeta1.281.28
SchedulerQueueingHintsfalseBeta1.29–
SELinuxMountfalseAlpha1.30–
SELinuxMountReadWriteOncePodfalseAlpha1.251.26
SELinuxMountReadWriteOncePodfalseBeta1.271.27
SELinuxMountReadWriteOncePodtrueBeta1.28–
SeparateTaintEvictionControllertrueBeta1.29–
ServiceAccountTokenJTIfalseAlpha1.291.29
ServiceAccountTokenJTItrueBeta1.30–
ServiceAccountTokenNodeBindingfalseAlpha1.291.30
ServiceAccountTokenNodeBindingtrueBeta1.31–
ServiceAccountTokenNodeBindingValidationfalseAlpha1.291.29
ServiceAccountTokenNodeBindingValidationtrueBeta1.30–
ServiceAccountTokenPodNodeInfofalseAlpha1.291.29
ServiceAccountTokenPodNodeInfotrueBeta1.30–
ServiceTrafficDistributionfalseAlpha1.301.30
ServiceTrafficDistributiontrueBeta1.31–
SidecarContainersfalseAlpha1.281.28
SidecarContainerstrueBeta1.29–
SizeMemoryBackedVolumesfalseAlpha1.201.21
SizeMemoryBackedVolumestrueBeta1.22–
StatefulSetAutoDeletePVCfalseAlpha1.231.26
StatefulSetAutoDeletePVCtrueBeta1.27–
StorageVersionAPIfalseAlpha1.20–
StorageVersionHashfalseAlpha1.141.14
StorageVersionHashtrueBeta1.15–
StorageVersionMigratorfalseAlpha1.301.32
StructuredAuthenticationConfigurationfalseAlpha1.291.29
StructuredAuthenticationConfigurationtrueBeta1.30–
StructuredAuthorizationConfigurationfalseAlpha1.291.29
StructuredAuthorizationConfigurationtrueBeta1.30–
SupplementalGroupsPolicyfalseAlpha1.31–
TopologyAwareHintsfalseAlpha1.211.22
TopologyAwareHintsfalseBeta1.231.23
TopologyAwareHintstrueBeta1.24–
TopologyManagerPolicyAlphaOptionsfalseAlpha1.26–
TopologyManagerPolicyBetaOptionsfalseBeta1.261.27
TopologyManagerPolicyBetaOptionstrueBeta1.28–
TopologyManagerPolicyOptionsfalseAlpha1.261.27
TopologyManagerPolicyOptionstrueBeta1.28–
TranslateStreamCloseWebsocketRequeststrueBeta1.30–
UnauthenticatedHTTP2DOSMitigationfalseBeta1.281.28
UnauthenticatedHTTP2DOSMitigationtrueBeta1.29–
UnknownVersionInteroperabilityProxyfalseAlpha1.28–
UserNamespacesPodSecurityStandardsfalseAlpha1.29–
UserNamespacesSupportfalseAlpha1.281.29
UserNamespacesSupportfalseBeta1.30–
VolumeAttributesClassfalseAlpha1.291.30
VolumeAttributesClassfalseBeta1.31–
VolumeCapacityPriorityfalseAlpha1.21–
WatchCacheInitializationPostStartHookfalseBeta1.31–
WatchFromStorageWithoutResourceVersionfalseBeta1.30–
WatchListfalseAlpha1.27–
WindowsHostNetworktrueAlpha1.26–
WinDSRfalseAlpha1.14–
WinOverlayfalseAlpha1.141.19
WinOverlaytrueBeta1.20–

Функціональні можливості для стабільних або застарілих функцій

Функціональні можливості для стабільних або застарілих функцій
ВластивістьСтандартноСтадіяПочинаючи зДо
AdmissionWebhookMatchConditionsfalseAlpha1.271.27
AdmissionWebhookMatchConditionstrueBeta1.281.29
AdmissionWebhookMatchConditionstrueGA1.30–
AggregatedDiscoveryEndpointfalseAlpha1.261.26
AggregatedDiscoveryEndpointtrueBeta1.271.29
AggregatedDiscoveryEndpointtrueGA1.30–
AllowServiceLBStatusOnNonLBfalseDeprecated1.29–
APIListChunkingfalseAlpha1.81.8
APIListChunkingtrueBeta1.91.28
APIListChunkingtrueGA1.29–
AppArmortrueBeta1.41.30
AppArmortrueGA1.31–
CloudDualStackNodeIPsfalseAlpha1.271.28
CloudDualStackNodeIPstrueBeta1.291.29
CloudDualStackNodeIPstrueGA1.30–
CPUManagerfalseAlpha1.81.9
CPUManagertrueBeta1.101.25
CPUManagertrueGA1.26–
DefaultHostNetworkHostPortsInPodTemplatesfalseDeprecated1.28–
DevicePluginCDIDevicesfalseAlpha1.281.28
DevicePluginCDIDevicestrueBeta1.291.30
DevicePluginCDIDevicestrueGA1.31–
EfficientWatchResumptionfalseAlpha1.201.20
EfficientWatchResumptiontrueBeta1.211.23
EfficientWatchResumptiontrueGA1.24–
ElasticIndexedJobtrueBeta1.271.30
ElasticIndexedJobtrueGA1.31–
ExecProbeTimeouttrueGA1.20–
HPAContainerMetricsfalseAlpha1.201.26
HPAContainerMetricstrueBeta1.271.29
HPAContainerMetricstrueGA1.30–
JobPodFailurePolicyfalseAlpha1.251.25
JobPodFailurePolicytrueBeta1.261.30
JobPodFailurePolicytrueGA1.31–
KMSv1trueDeprecated1.281.28
KMSv1falseDeprecated1.29–
KMSv2falseAlpha1.251.26
KMSv2trueBeta1.271.28
KMSv2trueGA1.29–
KMSv2KDFfalseBeta1.281.28
KMSv2KDFtrueGA1.29–
KubeProxyDrainingTerminatingNodesfalseAlpha1.281.30
KubeProxyDrainingTerminatingNodestrueBeta1.301.30
KubeProxyDrainingTerminatingNodestrueGA1.31–
LegacyServiceAccountTokenCleanUpfalseAlpha1.281.28
LegacyServiceAccountTokenCleanUptrueBeta1.291.29
LegacyServiceAccountTokenCleanUptrueGA1.30–
LogarithmicScaleDownfalseAlpha1.211.21
LogarithmicScaleDowntrueBeta1.221.30
LogarithmicScaleDowntrueGA1.31–
MinDomainsInPodTopologySpreadfalseAlpha1.241.24
MinDomainsInPodTopologySpreadfalseBeta1.251.26
MinDomainsInPodTopologySpreadtrueBeta1.271.29
MinDomainsInPodTopologySpreadtrueGA1.30–
NewVolumeManagerReconstructionfalseBeta1.271.27
NewVolumeManagerReconstructiontrueBeta1.281.29
NewVolumeManagerReconstructiontrueGA1.30–
NodeOutOfServiceVolumeDetachfalseAlpha1.241.25
NodeOutOfServiceVolumeDetachtrueBeta1.261.27
NodeOutOfServiceVolumeDetachtrueGA1.28–
PDBUnhealthyPodEvictionPolicyfalseAlpha1.261.26
PDBUnhealthyPodEvictionPolicytrueBeta1.271.30
PDBUnhealthyPodEvictionPolicytrueGA1.31–
PersistentVolumeLastPhaseTransitionTimefalseAlpha1.281.28
PersistentVolumeLastPhaseTransitionTimetrueBeta1.291.30
PersistentVolumeLastPhaseTransitionTimetrueGA1.31–
PodDisruptionConditionsfalseAlpha1.251.25
PodDisruptionConditionstrueBeta1.261.30
PodDisruptionConditionstrueGA1.31–
PodHostIPsfalseAlpha1.281.28
PodHostIPstrueBeta1.291.30
PodHostIPstrueGA1.30–
PodSchedulingReadinessfalseAlpha1.261.26
PodSchedulingReadinesstrueBeta1.271.29
PodSchedulingReadinesstrueGA1.30–
RemainingItemCountfalseAlpha1.151.15
RemainingItemCounttrueBeta1.161.28
RemainingItemCounttrueGA1.29–
ServerSideApplyfalseAlpha1.141.15
ServerSideApplytrueBeta1.161.21
ServerSideApplytrueGA1.22–
ServerSideFieldValidationfalseAlpha1.231.24
ServerSideFieldValidationtrueBeta1.251.26
ServerSideFieldValidationtrueGA1.27–
StableLoadBalancerNodeSettrueBeta1.271.29
StableLoadBalancerNodeSettrueGA1.30–
StatefulSetStartOrdinalfalseAlpha1.261.26
StatefulSetStartOrdinaltrueBeta1.271.30
StatefulSetStartOrdinaltrueGA1.31–
ValidatingAdmissionPolicyfalseAlpha1.261.27
ValidatingAdmissionPolicyfalseBeta1.281.29
ValidatingAdmissionPolicytrueGA1.30–
WatchBookmarkfalseAlpha1.151.15
WatchBookmarktrueBeta1.161.16
WatchBookmarktrueGA1.17–
ZeroLimitedNominalConcurrencySharesfalseBeta1.291.29
ZeroLimitedNominalConcurrencySharestrueGA1.30–

Використання функцій

Стадії функцій

Кожна функція може бути в стані Alpha, Beta або GA (загальнодоступна).

Alpha означає:

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

Beta означає:

  • Зазвичай функція є типово увімкненою. Бета API групи є типово вимкненими.
  • Функція є добре протестованою. Увімкнення функції вважається безпечним.
  • Підтримка загального функціонала не буде припинена, хоча деталі можуть змінюватися.
  • Схема та/або семантика обʼєктів можуть змінюватися несумісними способами в наступному бета або стабільному випуску. Коли це станеться, ми надамо інструкції для переходу на наступну версію. Це може вимагати видалення, редагування та повторного створення API обʼєктів. Процес редагування може потребувати певних зусиль. Це може вимагати простою для застосунків, які залежать від функції.
  • Рекомендується використовувати лише для некритичних для бізнесу випадків через можливість несумісних змін у наступних випусках. Якщо у вас є кілька кластерів, які можуть бути оновлені незалежно, ви можете послабити це обмеження.

Функція в стані Загальна доступність (GA) також називається стабільною функцією. Це означає:

  • Функція завжди увімкнена; ви не можете її вимкнути.
  • Відповідний перемикач функціональної можливості більше не потрібен.
  • Стабільні версії функцій зʼявлятимуться у випущеному програмному забезпеченні для багатьох наступних версій.

Перелік функціональних можливостей

Кожна функціональна можливість створена для вмикання/вимикання певної функції.

  • AdmissionWebhookMatchConditions: Вмикає умови збігу для модифікації та перевірки вебхуків допуску.

  • AggregatedDiscoveryEndpoint: Вмикає єдину точку доступу до HTTP /discovery/<version>, яка підтримує власне кешування HTTP за допомогою теґів, що містять усі відомі APIResources на сервері API.

  • AllowServiceLBStatusOnNonLB: Дозволяє встановлювати .status.ingress.loadBalancer для сервісів типів, відмінних від LoadBalancer.

  • AnonymousAuthConfigurableEndpoints: Дозволяє увімкнути налаштовувані точки доступу для анонімної автентифікації для сервера API.

  • AnyVolumeDataSource: Дозволити використання будь-якого власного ресурсу як DataSource для PVC.

  • APIListChunking: Дозволяє клієнтам API отримувати (LIST або GET) ресурси з сервера API частинами.

  • APIResponseCompression: Стиснення відповідей API для запитів LIST або GET.

  • APIServerIdentity: Присвоює кожному серверу API ідентифікатор у кластері, використовуючи Lease.

  • APIServerTracing: Додає підтримку розподіленого трасування у сервері API. Докладні відомості наведено у статті Трасування системних компонентів Kubernetes.

  • AppArmor: Вмикає використання примусового контролю доступу AppArmor для Podʼів, що працюють на вузлах Linux. Докладнішу інформацію наведено у Посібнику з AppArmor.

  • AuthorizeNodeWithSelectors: Дозволяє авторизатору вузла використовувати детальну авторизацію за допомогою селекторів. Потрібно увімкнути AuthorizeWithSelectors.

  • AuthorizeWithSelectors: Дозволяє використовувати селектори полів та міток для авторизації. Увімкнення полів fieldSelector та labelSelector в API SubjectAccessReview, передає інформацію про селектори полів і міток до вебхуків авторизації, активує функції fieldSelector та labelSelector у бібліотеці CEL для авторизації, а також дозволяє перевіряти поля fieldSelector і labelSelector в умовах збігу вебхуків авторизації.

  • CloudControllerManagerWebhook: Вмикання веб-хуків у менеджері хмарних контролерів.

  • CloudDualStackNodeIPs: Вмикає двостековий kubelet --node-ip із зовнішніми хмарними провайдерами. Див. статтю Налаштування подвійного стека IPv4/IPv6 для більш детальної інформації.

  • ClusterTrustBundle: Вмикає обʼєкти ClusterTrustBundle та інтеграцію kubelet.

  • ClusterTrustBundleProjection: джерела спроєцьованих томів clusterTrustBundle.

  • ComponentSLIs: Вмикає точку доступу /metrics/slis на таких компонентах Kubernetes як kubelet, kube-scheduler, kube-proxy, kube-controller-manager, cloud-controller-manager що дозволяє вам отримувати метрики перевірки працездатності.

  • ConsistentListFromCache:

    Покращує продуктивність API сервера Kubernetes, обслуговуючи узгоджені запити list безпосередньо з кешу спостереження, що підвищує масштабованість та скорочує час відгуку. Для узгодженого списку з кешу Kubernetes потрібна новіша версія etcd (v3.4.31+ або v3.5.13+), яка містить виправлення для функції запиту на прогрес спостереження. Якщо надана стара версія etcd, Kubernetes автоматично визначить це і повернеться до обслуговування узгоджених читань з etcd. Сповіщення про прогрес забезпечують узгодженість кешу спостереження з etcd, одночасно зменшуючи потребу у витратних читаннях кворуму з etcd.

    Детальніше дивіться у документації Kubernetes про Семантику для get і list.

  • ContainerCheckpoint: Вмикає kubelet checkpoint API. Дивіться Kubelet Checkpoint API для більш детальної інформації.

  • ContextualLogging: Вмикає додаткові деталі у виведенні логів компонентів Kubernetes, які підтримують контекстне ведення логів.

  • CoordinatedLeaderElection: Вмикає поведінку, що підтримує API LeaseCandidate, а також забезпечує детерміноване обрання лідера для панелі управління Kubernetes.

  • CPUManager: Вмикає підтримку спорідненості процесорів на рівні контейнерів, див. Політики керування процесорами.

  • CPUManagerPolicyAlphaOptions: Дозволяє тонко налаштовувати політики CPUManager, експериментальні, альфа-опції якості. Ця функціональна можливість захищає групу опцій CPUManager, які мають рівень якості альфа. Ці функціональні можливості ніколи не будуть переведені у бета-версію або стабільну версію.

  • CPUManagerPolicyBetaOptions: Дозволяє тонко налаштовувати політики CPUManager, експериментальні, бета-опції якості. Ця функціональна можливість захищає групу опцій CPUManager, які мають рівень якості бета. Ці функціональні можливості ніколи не будуть переведені у стабільну версію.

  • CPUManagerPolicyOptions: Дозволяє тонко налаштовувати політики CPUManager.

  • CRDValidationRatcheting: Ввімкнути оновлення власних ресурсів, щоб вони містили порушення їхньої схеми OpenAPI, якщо частини ресурсу, що порушують оновлення не змінилися. Докладніші відомості наведено у статті Проковзування валідації.

  • CronJobsScheduledAnnotation: Встановіть час запланованого завдання як анотацію для завдань, створених від імені CronJob.

  • CrossNamespaceVolumeDataSource: Вмикає використання перехресного простору назв джерела даних тома щоб дозволити вам вказувати простір імен джерела у полі dataSourceRef у PersistentVolumeClaim.

  • CSIMigrationPortworx: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Portworx до втулка Portworx CSI. Вимагає встановлення та налаштування втулка Portworx CSI в кластері.

  • CSIVolumeHealth: Вмикає підтримку моніторингу стану справності томів CSI на вузлі.

  • CustomCPUCFSQuotaPeriod: Дозволяє вузлам змінювати cpuCFSQuotaPeriod в конфігурації kubelet.

  • CustomResourceFieldSelectors: Вмикає selectableFields в API CustomResourceDefinition, щоб дозволити фільтрацію запитів list, watch та deletecollection для власних ресурсів.

  • DefaultHostNetworkHostPortsInPodTemplates:

    Ця функціональна можливість керує моментом, коли стандартне значення для .spec.containers[*].ports[*].hostPort назначається для Podʼів, які використовують hostNetwork: true. Типовим з версії Kubernetes v1.28 є те, що стандартне значення встановлюється лише для Podʼів.

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

  • DevicePluginCDIDevices: Вмикає підтримку ідентифікаторів пристроїв CDI в API Device Plugin.

  • DisableCloudProviders: Вимикає будь-яку функціональність у kube-apiserver, kube-controller-manager та kubelet, повʼязаних з прапорцем компонента --cloud-provider. прапором компонента.

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

  • DisableNodeKubeProxyVersion: Вимикає встановлення поля kubeProxyVersion вузла.

  • DRAControlPlaneController: Дозволяє підтримувати ресурси з власними параметрами та життєвим циклом, який не залежить від Pod. Розподілом ресурсів займається контролер панелі управління драйвера ресурсу.

  • DynamicResourceAllocation: Дозволяє підтримувати ресурси з власними параметрами та життєвим циклом які не залежать від Pod. Розподілом ресурсів займається планувальник Kubernetes використовуючи "структуровані параметри".

  • EfficientWatchResumption: Дозволяє надсилати користувачам події закладок (сповіщення про хід виконання), що походять зі сховища. Застосовується лише до операцій спостереження.

  • ElasticIndexedJob: Дозволяє масштабувати індексовані завдання шляхом зміни параметрів spec.completions та spec.parallelism таким чином, щоб spec.completions == spec.parallelism. Детальніше див. у документації про еластичні індексовані завдання.

  • EventedPLEG: Вмикає підтримку kubelet для отримання подій життєвого циклу контейнера з container runtime через розширення до CRI. (PLEG, скорочення від "Pod lifecycle event generator" — генератор подій життєвого циклу Pod). Щоб ця функція була корисною, вам також потрібно увімкнути підтримку подій життєвого циклу контейнера у кожному середовищі виконання контейнерів, що працює у вашому кластері. Якщо середовище виконання контейнера не оголошує про підтримку подій життєвого циклу контейнера, то kubelet автоматично перемикається на застарілий загальний механізм PLEG, навіть якщо ви увімкнули цю функціональну можливість.

  • ExecProbeTimeout: Переконайтеся, що kubelet дотримується таймаутів exec probe. Ця функція існує на випадок, якщо будь-яке з ваших робочих навантажень залежить від виправленої помилки, коли Kubernetes ігнорував тайм-аути exec probe. Дивіться проби готовності.

  • GracefulNodeShutdown: Вмикає підтримку відповідного завершення роботи у kubelet. Під час вимкнення системи kubelet намагатиметься виявити подію вимкнення і завершити роботу Podʼів, запущених на вузлі, відповідним чином. Докладніші відомості наведено у статті Відповідне вимикання вузла.

  • GracefulNodeShutdownBasedOnPodPriority: Дозволяє kubelet перевіряти пріоритети Pod під час відповідного завершення роботи вузла.

  • HonorPVReclaimPolicy: Дотримуватися політики відновлення постійного тому, коли він має значення Delete, незалежно від впорядкування видалення PV-PVC. Докладніші відомості наведено у документації Завершувач захисту від видалення постійних томів.

  • HPAContainerMetrics: Дозволяє HorizontalPodAutoscalers виконувати масштабування на основі метрик з окремих контейнерів у межах цільових Podʼів.

  • HPAScaleToZero: Дозволяє встановлювати minReplicas у 0 для ресурсів HorizontalPodAutoscaler при використанні власних або зовнішніх метрик.

  • ImageMaximumGCAge: Вмикає поле конфігурації kubelet imageMaximumGCAge, що дозволяє адміністратору вказати вік, після якого образ буде викинуто у смітник.

  • ImageVolume: Дозволити використання джерела тому image у Pod. За допомогою цього джерела томів ви можете змонтувати образ контейнера як том лише для читання.

  • InPlacePodVerticalScaling: Дозволяє вертикальне масштабування Podʼів на місці.

  • InTreePluginPortworxUnregister: Припиняє реєстрацію вбудованого втулка Portworx у kubelet та контролерах томів.

  • JobBackoffLimitPerIndex: Дозволяє вказати максимальну кількість повторних спроб для кожного індексу в проіндексованих завданнях.

  • JobManagedBy: Дозволяє делегувати узгодження обʼєкта Job зовнішньому контролеру.

  • JobPodFailurePolicy: Дозволяє користувачам визначати обробку несправностей контейнерів на основі кодів виходу з контейнера та стану контейнерів.

  • JobPodReplacementPolicy: Дозволяє вказувати заміну для Podʼів, що завершуються, в Job

  • JobSuccessPolicy: Дозволяє користувачам вказувати, коли Job може бути визнаний успішним на основі набору успішних Podʼів.

  • KMSv1: Вмикає API KMS v1 для шифрування у стані спокою. Докладні відомості наведено у статті Використання постачальника KMS для шифрування даних.

  • KMSv2: Вмикає API KMS v2 для шифрування у стані спокою. Докладні відомості наведено у статті Використання постачальника KMS для шифрування даних.

  • KMSv2KDF: Дозволяє KMS v2 генерувати одноразові ключі шифрування даних. Докладні відомості наведено у статті Використання постачальника KMS для шифрування даних. Якщо у вашому кластері не увімкнено елемент KMSv2, значення елемента KMSv2KDF не матиме жодного впливу.

  • KubeletCgroupDriverFromCRI: Вмикає виявлення параметра конфігурації драйвера cgroup kubelet з CRI. Ви можете використовувати цю функціональну можливість на вузлах з kubelet, які її підтримують, і де є середовище виконання контейнерів CRI, що підтримує виклик CRI RuntimeConfig. Якщо як CRI, так і kubelet підтримують цю функцію, kubelet ігнорує налаштування конфігурації cgroupDriver (або застарілий аргумент командного рядка --cgroup-driver). Якщо ви увімкнете цю функціональну можливість, а середовище виконання контейнерів не підтримує її, kubelet повертається до використання драйвера, налаштованого за допомогою параметра конфігурації cgroupDriver. Дивіться Конфігурація драйвера cgroup для отримання додаткової інформації.

  • KubeletInUserNamespace: Вмикає підтримку запуску kubelet у просторі імен користувачів. Див. розділ Запуск компонентів вузла Kubernetes від імені не-root користувача.

  • KubeletPodResourcesDynamicResources: Розширює ресурси gRPC точки доступа Podʼа kublet, щоб включати ресурси, що виділені в ResourceClaims через API DynamicResourceAllocation. Див. звіт про виділення ресурсів для отримання додаткових відомостей. З цією інформацією про ресурси, клієнти можуть належним чином відстежувати вільні обчислювальні ресурси на вузлі.

  • KubeletPodResourcesDynamicResources: Розширює ресурси gRPC точки доступу Podʼа kubelet, щоб включити ресурси, виділені в ResourceClaims через API DynamicResourceAllocation. Див. звіт про виділення ресурсів для отримання додаткової інформації, інформацією про доступні ресурси, що дозволяє клієнтам належним чином відстежувати вільні обчислювальні ресурси на вузлі.

  • KubeletPodResourcesGet: Вмикає точку доступу Get gRPC в kubeletʼах для ресурсів Pod. Цей API доповнює звіт про розподіл ресурсів.

  • KubeletSeparateDiskGC: Функція розділеної файлової системи образів дозволяє kubelet виконувати збір сміття образів (шарів лише для читання) та/або контейнерів (шарів для запису), розгорнутих на окремих файлових системах.

  • KubeletTracing: Додавання підтримки розподіленого трасування в kubelet. Якщо увімкнено, інтерфейс CRI kubelet та автентифіковані http-сервери використовуються для генерації відрізків трасування OpenTelemetry. Дивіться Трасування для системних компонентів Kubernetes для більш детальної інформації.

  • KubeProxyDrainingTerminatingNodes: Реалізація очищення зʼєднань для термінальних вузлів для сервісів externalTrafficPolicy: Cluster.

  • LegacyServiceAccountTokenCleanUp: Вмикає очищення токенів службових облікових записів, що базуються на Secret, коли вони не використовуються протягом певного часу (стандартно — один рік).

  • LoadBalancerIPMode: Дозволяє встановити ipMode для сервісів, де type встановлено у LoadBalancer. Докладнішу інформацію наведено у статті Визначення IPMode статусу балансувальника навантаження.

  • LocalStorageCapacityIsolationFSQuotaMonitoring: Якщо LocalStorageCapacityIsolation увімкнено для локального ефемерного сховища, резервна файлова система для томів emptyDir підтримує квоти проєктів і UserNamespacesSupport увімкнено, квоти проєктів використовуються для моніторингу споживання сховища томів emptyDir, а не шляхом проходу файловою системою, що забезпечує кращу продуктивність і точність.

  • LogarithmicScaleDown: Вмикає напіввипадковий вибір Podʼів для виселення при зменшенні масштабу контролера на основі логарифмічного обʼєднання міток часу Podʼів.

  • LoggingAlphaOptions: Дозволяє тонко налаштовувати експериментальні, альфа-якості параметрів логування.

  • LoggingBetaOptions: Дозволяє тонко налаштовувати експериментальні, бета-якості параметрів логування.

  • MatchLabelKeysInPodAffinity: Вмикає поля matchLabelKeys та mismatchLabelKeys для pod (anti)affinity.

  • MatchLabelKeysInPodTopologySpread: Вмикає поле matchLabelKeys для Обмеження поширення топології Podʼів.

  • MaxUnavailableStatefulSet: Дозволяє встановити поле maxUnavailable для rolling update strategy набору StatefulSet. Поле визначає максимальну кількість Podʼів, які можуть бути недоступні під час оновлення.

  • MemoryManager: Дозволяє встановити спорідненість памʼяті для контейнера на основі топології NUMA.

  • MemoryQoS: Вмикає захист памʼяті та обмеження використання памʼяті на pod/контейнер за допомогою контролера памʼяті cgroup v2.

  • MinDomainsInPodTopologySpread: Вмикає minDomains в Обмеженнях поширення топології Pod.

  • MultiCIDRServiceAllocator: Відстежуйте розподіл IP-адрес для IP кластера сервісів за допомогою обʼєктів IPAddress.

  • MutatingAdmissionPolicy: У Kubernetes 1.31 цей елемент не має ефекту. У майбутньому випуску Kubernetes цей елемент може бути використано для увімкнення MutatingAdmissionPolicy у ланцюжку допусків.

  • NewVolumeManagerReconstruction:

    Дозволяє покращити виявлення змонтованих томів під час запуску kubelet. Оскільки відповідний код було суттєво перероблено, у версіях Kubernetes від 1.25 до 1.29 можна було вимкнути цю функцію у випадку, якщо kubelet застряг під час запуску або не розмонтував томи з завершених Podʼів.

    Цей рефакторинг лежав в основі функції SELinuxMountReadWriteOncePod у версіях Kubernetes 1.25 та 1.26.

  • NFTablesProxyMode: Дозволяє запуск kube-proxy у режимі nftables.

  • NodeInclusionPolicyInPodTopologySpread: Вмикає використання nodeAffinityPolicy та nodeTaintsPolicy в Обмеження поширення топології Podʼів при обчисленні відхилення розповсюдження топології вузлів.

  • NodeLogQuery: Дозволяє запитувати логи сервісів вузла за допомогою точки доступу /logs.

  • NodeOutOfServiceVolumeDetach: Коли вузол позначено як такий, що не працює, за допомогою taint node.kubernetes.io/out-of-service, то Podʼи на цьому вузлі будуть примусово видалені, якщо вони не можуть толерувати цю позначку, а операції відʼєднання томів для Podʼів, що завершують роботу на цьому вузлі, будуть виконані негайно. Видалені Podʼи можуть бути швидко відновлені на інших вузлах.

  • NodeSwap: Дозволяє kubelet виділяти памʼять підкачки для робочих навантажень Kubernetes на вузлі. Має використовуватися з KubeletConfiguration.failSwapOn, встановленим у false. За більш детальною інформацією зверніться до swap memory

  • OpenAPIEnums: Дозволяє заповнювати поля "enum" схем OpenAPI у специфікації, що повертається від сервера API.

  • PDBUnhealthyPodEvictionPolicy: Вмикає поле unhealthyPodEvictionPolicy в полі PodDisruptionBudget. Визначає, коли слід розглядати можливість виселення несправних Podʼів. Будь ласка, дивіться Політику виселення несправних Podʼів для більш детальної інформації.

  • PersistentVolumeLastPhaseTransitionTime: Додає нове поле до PersistentVolume, яке містить мітку часу, коли том востаннє змінював свою фазу.

  • PodAndContainerStatsFromCRI: Налаштуйте kubelet на збір статистики контейнерів і Podʼів під час виконання CRI-контейнера, а не на збір статистики з cAdvisor. Починаючи з версії 1.26, це також включає збір метрик з CRI та надсилання їх за допомогою /metrics/cadvisor (замість того, щоб cAdvisor відправляв їх безпосередньо).

  • PodDeletionCost: Вмикає функцію Pod Deletion Cost, яка дозволяє користувачам впливати на порядок зменшення масштабу ReplicaSet.

  • PodDisruptionConditions: Вмикає підтримку додавання спеціальної умови, яка вказує на те, що Pod видаляється через збій.

  • PodHostIPs: Вмикає поле status.hostIPs для Podʼів та downward API. Це поле дозволяє вам показувати IP-адреси хостів робочим навантаженням.

  • PodIndexLabel: Дозволяє контролеру Job і контролеру StatefulSet додавати індекс Podʼів як мітку під час створення нових Podʼів. Докладніше дивіться в документах Режим завершення завдання та Мітка індексу Podʼів StatefulSet.

  • PodLifecycleSleepAction: Вмикає дію sleep в хуках життєвого циклу контейнера.

  • PodReadyToStartContainersCondition:

    Дозволяє kubelet позначати стан PodReadyToStartContainers для контейнерів Podʼів.

    Раніше ця функціональна можливість була відома як PodHasNetworkCondition, а повʼязана з нею умова називалася PodHasNetwork.

  • PodSchedulingReadiness: Дозволяє встановлювати поле SchedulingGates для керування готовністю до виселення за розкладом.

  • PortForwardWebsockets: Дозволити потокове передавання WebSocket підпротоколу portforward (port-forward) від клієнтів, які запитують версію v2 (v2.portforward.k8s.io) підпротоколу.

  • ProcMountType: Дозволяє керувати типом монтування proc для контейнерів, встановлюючи поле procMount у SecurityContext.

  • QOSReserved: Дозволяє резервувати ресурси на рівні QoS, запобігаючи тим самим тому, щоб підсистеми на рівнях QoS нижчого рівня виходили за межі ресурсів, запитаних на рівнях QoS вищого рівня (наразі лише памʼять).

  • RecoverVolumeExpansionFailure: Дозволяє користувачам редагувати свої PVC до менших розмірів, щоб можна було відновити їх після попередніх збоїв під час розширення томів. Докладні відомості див. у статті Відновлення після збою під час розширення томів.

  • RecursiveReadOnlyMounts: Вмикає підтримку рекурсивних монтувань лише для читання. Докладні відомості наведено у статті монтування лише для читання.

  • RelaxedEnvironmentVariableValidation: Дозволити майже всі друковані символи ASCII у змінних оточення.

  • RemainingItemCount: Дозволити серверам API показувати кількість елементів, що залишилися, у відповіді на запит chunking list request.

  • ResilientWatchCacheInitialization: Дозволяє відмовостійку ініціалізацію кешу watch, щоб уникнути перевантаження панелі управління.

  • ResourceHealthStatus: Вмикає поле allocatedResourcesStatus у файлі .status для Pod. У полі буде показано додаткові відомості для кожного контейнера у Pod, а також інформацію про стан кожного пристрою, призначеного для Pod. Докладні відомості наведено у статті Втулок пристрою та несправні пристрої.

  • RetryGenerateName: Дозволяє повторити спробу створення обʼєкта, коли API server очікується, що сервер API server згенерує name. Якщо цю можливість увімкнено, запити з використанням generateName будуть автоматично повторюватися, якщо панель управління виявить конфлікт імен з наявним обʼєктом, але не більше 8 спроб.

  • RetryGenerateName: Дозволяє повторити спробу створення обʼєкта, коли очікується, що API server створить name. Коли цю можливість увімкнено, запити з використанням generateName автоматично повторюються у випадку, якщо панель управління виявляє конфлікт імен з наявним обʼєктом, до обмеження у 8 спроб.

  • RotateKubeletServerCertificate: Вмикає ротацію серверного TLS-сертифікату в kubelet. Дивіться kubelet configuration для більш детальної інформації.

  • RuntimeClassInImageCriApi: Дозволяє витягувати зображення на основі класу виконання Podʼів, які посилаються на них.

  • SchedulerQueueingHints: Дозволяє покращення підказок планувальника, що дозволяє зменшити кількість марних перезапитів. Планувальник повторно спробує запланувати Podʼи, якщо щось зміниться у кластері, що може призвести до того, що Pod буде заплановано. Підказки щодо черги — це внутрішні сигнали, які дозволяють планувальнику відфільтрувати зміни у кластері, які мають відношення до незапланованого Podʼа, на основі попередніх спроб планування.

  • SELinuxMount:

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

    Для увімкнення SELinuxMount потрібно, щоб було увімкнено SELinuxMountReadWriteOncePod.

  • SELinuxMountReadWriteOncePod: Прискорює запуск контейнера, дозволяючи kubelet монтувати томи для Pod безпосередньо з правильною міткою SELinux замість того, щоб рекурсивно змінювати кожен файл на томах. Початкова реалізація була зосереджена на томах ReadWriteOncePod.

  • SeparateTaintEvictionController: Дозволяє запуск TaintEvictionController, який виконує Taint-based Evictions, у контролері, відокремленому від NodeLifecycleController. Коли цю можливість увімкнено, користувачі можуть за бажанням вимкнути виселення на основі Taint, встановивши прапорець --controllers=-taint-eviction-controller у kube-controller-manager.

  • ServerSideApply: Вмикає функцію Server Side Apply (SSA) на сервері API.

  • ServerSideFieldValidation: Вмикає перевірку полів на стороні сервера. Це означає, що перевірка схеми ресурсів виконується на стороні сервера API, а не на стороні клієнта (наприклад, командний рядок kubectl create або kubectl apply).

  • ServiceAccountTokenJTI: Контролює, чи вбудовуються JTI (UUID) у згенеровані токени службових облікових записів, і чи записуються ці JTI до логу аудиту Kubernetes для майбутніх запитів, зроблених цими токенами.

  • ServiceAccountTokenNodeBinding: Контролює, чи дозволяє сервер API привʼязувати токени службових облікових записів до обʼєктів Node.

  • ServiceAccountTokenNodeBindingValidation: Керує тим, чи буде apiserver перевіряти посилання на Node у токенах службових облікових записів.

  • ServiceAccountTokenPodNodeInfo: Керує тим, чи вбудовувати імʼя вузла та uid для повʼязаного з ним вузла при видачі токенів службових облікових записів, привʼязаних до обʼєктів Pod.

  • ServiceTrafficDistribution: Дозволяє використовувати необовʼязкове поле spec.trafficDistribution у Services. У цьому полі можна вказати параметри розподілу трафіку між точками доступу Service.

  • SidecarContainers: Дозволити встановлювати restartPolicy контейнера init значення Always, щоб контейнер ставав sidecar-контейнером (контейнери init, які можна перезапустити). Дивіться Контейнери Sidecar та restartPolicy для отримання більш детальної інформації.

  • SizeMemoryBackedVolumes: Дозволяє kubelet визначати обмеження розміру для памʼяті, яка використовується для томів (головним чином для томів emptyDir).

  • StableLoadBalancerNodeSet: Дозволяє зменшити кількість переконфігурацій балансувальника навантаження контролером послуг (KCCM) внаслідок зміни стану вузла.

  • StatefulSetAutoDeletePVC: Дозволяє використовувати необовʼязкове поле .spec.persistentVolumeClaimRetentionPolicy, що забезпечує контроль над видаленням PVC у життєвому циклі StatefulSet. Дивіться PersistentVolumeClaim retention для більш детальної інформації.

  • StatefulSetStartOrdinal: Дозволити налаштування порядкового номера старту у StatefulSet. Дивіться Початковий порядковий номер для більш детальної інформації.

  • StorageVersionAPI: Вмикає API версії зберігання.

  • StorageVersionHash: Дозволити API-серверам показувати хеш версії сховища при відкритті.

  • StorageVersionMigrator: Вмикає міграцію версій сховища. Докладні відомості наведено у статті Міграція обʼєктів Kubernetes за допомогою міграції версій сховища.

  • StructuredAuthenticationConfiguration: Вмикає конфігурацію структурованої автентифікації для сервера API.

  • StructuredAuthorizationConfiguration: Вмикає структуровану конфігурацію авторизації, щоб адміністратори кластера могли вказати більше одного webhook авторизації в ланцюжку обробників серверів API.

  • SupplementalGroupsPolicy: Вмикає підтримку детального контролю SupplementalGroups. Докладні відомості див. у статті Налаштування детального контролю SupplementalGroups для Podʼа.

  • TopologyAwareHints: Вмикає маршрутизацію з урахуванням топології на основі підказок топології у EndpointSlices. Див. статтю Підказки з урахуванням топології для отримання детальнішої інформації.

  • TopologyManagerPolicyAlphaOptions: Дозволяє тонке налаштування політик менеджера топології, експериментальні варіанти з альфа-якістю. Ця функціональна можливість захищає групу параметрів менеджера топології, рівень якості яких є альфа. Ця функціональна можливість ніколи не перейде до бета-версії або стабільної версії.

  • TopologyManagerPolicyBetaOptions: Дозволяє тонке налаштування політик менеджера топології, експериментальні варіанти з бета-якістю. Ця функціональна можливість захищає групу параметрів менеджера топології, рівень якості яких є бета. Ця функціональна можливість ніколи не перейде до стабільної версії.

  • TopologyManagerPolicyOptions: Вмикає тонке налаштування політик менеджера топології.

  • TranslateStreamCloseWebsocketRequests: Дозволити WebSocket потік підпротоколу віддалених команд (exec, cp, attach) від клієнтів, які запитують версію 5 (v5) підпротоколу.

  • UnauthenticatedHTTP2DOSMitigation: Вмикає помʼякшення наслідків відмови в обслуговуванні (DoS) HTTP/2 для неавторизованих клієнтів. У версіях Kubernetes від 1.28.0 до 1.28.2 ця функція не включена.

  • UnknownVersionInteroperabilityProxy: Проксі-запити ресурсів до правильного однорангового kube-apiserver, коли існує декілька kube-апісерверів у різних версіях. Докладнішу інформацію наведено у статті Проксі змішаних версій.

  • UserNamespacesPodSecurityStandards: Дозволити помʼякшення політик стандартів безпеки для Podʼів, які працюють з просторами імен. Ви маєте встановити значення цієї можливості узгоджено на всіх вузлах кластера, а також увімкнути UserNamespacesSupport, щоб використовувати цю можливість.

  • UserNamespacesSupport: Вмикання підтримки простору імен користувача для Podʼів.

  • ValidatingAdmissionPolicy: Вмикання підтримки ValidatingAdmissionPolicy для використання валідації CEL у контролі допуску.

  • VolumeAttributesClass: Вмикання підтримки класів VolumeAttributesClasses. Докладні відомості див. у статті Класи атрибутів томів.

  • VolumeCapacityPriority: Вмикання підтримки пріоритезації вузлів у різних топологіях на основі доступної місткості PV.

  • WatchBookmark: Вмикає підтримку подій закладок для спостереження.

  • WatchCacheInitializationPostStartHook: Вмикає post-start-hook для ініціалізації watchcache як частину readyz (з таймаутом).

  • WatchFromStorageWithoutResourceVersion: Дозволяє watch без resourceVersion працювати зі сховища.

  • WatchList: Вмикання підтримки потокового передавання початкового стану обʼєктів у запитах на спостереження.

  • WindowsHostNetwork: Вмикає підтримку приєднання контейнерів Windows до мережевого простору імен хостів.

  • WinDSR: Дозволяє kube-proxy створювати DSR-балансувальники навантаження для Windows.

  • WinOverlay: Дозволяє kube-proxy працювати в режимі оверлею для Windows.

  • ZeroLimitedNominalConcurrencyShares: Дозволити priority & fairness на сервері API використовувати нульове значення для поля nominalConcurrencyShares секції limited рівня пріоритету.

Що далі

  • У Політиці застарівання Kubernetes пояснюється підхід проєкту до видалення функцій та компонентів.
  • Починаючи з Kubernetes 1.24, нові бета-версії API стандартно не увімкнені. При увімкненні бета-версії вам також потрібно буде увімкнути всі повʼязані з цим API ресурси. Наприклад, щоб увімкнути певний ресурс, наприклад storage.k8s.io/v1beta1/csistoragecapacities, встановіть --runtime-config=storage.k8s.io/v1beta1/csistoragecapacities. Докладнішу інформацію про прапорці командного рядка наведено в Версіювання API.

12.2 - Функціональні можливості (вилучені)

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

Для отримання інформації про функціональні можливості, які все ще розпізнаються компонентами Kubernetes, зверніться до Таблиці функціональних можливостей Alpha/Beta або Таблиці функціональних можливостей Graduated/Deprecated.

Вилучені функціональні можливості

В наступній таблиці:

  • У стовпчику "З" вказано реліз Kubernetes, у якому зʼявилася функція або змінено стадію її випуску.
  • Стовпець "До", якщо він не порожній, містить останній випуск Kubernetes, у якому ви все ще можете використовувати функціональні можливості. Якщо стадія функції "Deprecated" або "GA", стовпець "До" вказує на випуск Kubernetes, з якого функцію було вилучено.
Feature Gates Removed
ВластивістьСтандартноСтадіяЗДо
AcceleratorsfalseAlpha1.61.10
Accelerators–Deprecated1.111.11
AdvancedAuditingfalseAlpha1.71.7
AdvancedAuditingtrueBeta1.81.11
AdvancedAuditingtrueGA1.121.27
AffinityInAnnotationsfalseAlpha1.61.7
AffinityInAnnotations–Deprecated1.81.8
AllowExtTrafficLocalEndpointsfalseBeta1.41.6
AllowExtTrafficLocalEndpointstrueGA1.71.9
AllowInsecureBackendProxytrueBeta1.171.20
AllowInsecureBackendProxytrueGA1.211.25
APIPriorityAndFairnessfalseAlpha1.181.19
APIPriorityAndFairnesstrueBeta1.201.28
APIPriorityAndFairnesstrueGA1.291.30
APISelfSubjectReviewfalseAlpha1.261.26
APISelfSubjectReviewtrueBeta1.271.27
APISelfSubjectReviewtrueGA1.281.29
AttachVolumeLimitfalseAlpha1.111.11
AttachVolumeLimittrueBeta1.121.16
AttachVolumeLimittrueGA1.171.21
BalanceAttachedNodeVolumesfalseAlpha1.111.21
BalanceAttachedNodeVolumesfalseDeprecated1.221.22
BlockVolumefalseAlpha1.91.12
BlockVolumetrueBeta1.131.17
BlockVolumetrueGA1.181.21
BoundServiceAccountTokenVolumefalseAlpha1.131.20
BoundServiceAccountTokenVolumetrueBeta1.211.21
BoundServiceAccountTokenVolumetrueGA1.221.23
ConfigurableFSGroupPolicyfalseAlpha1.181.19
ConfigurableFSGroupPolicytrueBeta1.201.22
ConfigurableFSGroupPolicytrueGA1.231.25
ConsistentHTTPGetHandlerstrueGA1.251.30
ControllerManagerLeaderMigrationfalseAlpha1.211.21
ControllerManagerLeaderMigrationtrueBeta1.221.23
ControllerManagerLeaderMigrationtrueGA1.241.26
CRIContainerLogRotationfalseAlpha1.101.10
CRIContainerLogRotationtrueBeta1.111.20
CRIContainerLogRotationtrueGA1.211.22
CronJobControllerV2falseAlpha1.201.20
CronJobControllerV2trueBeta1.211.21
CronJobControllerV2trueGA1.221.23
CronJobTimeZonefalseAlpha1.241.24
CronJobTimeZonetrueBeta1.251.26
CronJobTimeZonetrueGA1.271.28
CSIBlockVolumefalseAlpha1.111.13
CSIBlockVolumetrueBeta1.141.17
CSIBlockVolumetrueGA1.181.21
CSIDriverRegistryfalseAlpha1.121.13
CSIDriverRegistrytrueBeta1.141.17
CSIDriverRegistrytrueGA1.181.21
CSIInlineVolumefalseAlpha1.151.15
CSIInlineVolumetrueBeta1.161.24
CSIInlineVolumetrueGA1.251.26
CSIMigrationfalseAlpha1.141.16
CSIMigrationtrueBeta1.171.24
CSIMigrationtrueGA1.251.26
CSIMigrationAWSfalseAlpha1.141.16
CSIMigrationAWSfalseBeta1.171.22
CSIMigrationAWStrueBeta1.231.24
CSIMigrationAWStrueGA1.251.26
CSIMigrationAWSCompletefalseAlpha1.171.20
CSIMigrationAWSComplete–Deprecated1.211.21
CSIMigrationAzureDiskfalseAlpha1.151.18
CSIMigrationAzureDiskfalseBeta1.191.22
CSIMigrationAzureDisktrueBeta1.231.23
CSIMigrationAzureDisktrueGA1.241.26
CSIMigrationAzureDiskCompletefalseAlpha1.171.20
CSIMigrationAzureDiskComplete–Deprecated1.211.21
CSIMigrationAzureFilefalseAlpha1.151.20
CSIMigrationAzureFilefalseBeta1.211.23
CSIMigrationAzureFiletrueBeta1.241.25
CSIMigrationAzureFiletrueGA1.261.29
CSIMigrationAzureFileCompletefalseAlpha1.171.20
CSIMigrationAzureFileComplete–Deprecated1.211.21
CSIMigrationGCEfalseAlpha1.141.16
CSIMigrationGCEfalseBeta1.171.22
CSIMigrationGCEtrueBeta1.231.24
CSIMigrationGCEtrueGA1.251.27
CSIMigrationGCECompletefalseAlpha1.171.20
CSIMigrationGCEComplete–Deprecated1.211.21
CSIMigrationOpenStackfalseAlpha1.141.17
CSIMigrationOpenStacktrueBeta1.181.23
CSIMigrationOpenStacktrueGA1.241.25
CSIMigrationOpenStackCompletefalseAlpha1.171.20
CSIMigrationOpenStackComplete–Deprecated1.211.21
CSIMigrationRBDfalseAlpha1.231.27
CSIMigrationRBDfalseDeprecated1.281.30
CSIMigrationvSpherefalseAlpha1.181.18
CSIMigrationvSpherefalseBeta1.191.24
CSIMigrationvSpheretrueBeta1.251.25
CSIMigrationvSpheretrueGA1.261.28
CSIMigrationvSphereCompletefalseBeta1.191.21
CSIMigrationvSphereComplete–Deprecated1.221.22
CSINodeExpandSecretfalseAlpha1.251.26
CSINodeExpandSecrettrueBeta1.271.28
CSINodeExpandSecrettrueGA1.291.30
CSINodeInfofalseAlpha1.121.13
CSINodeInfotrueBeta1.141.16
CSINodeInfotrueGA1.171.22
CSIPersistentVolumefalseAlpha1.91.9
CSIPersistentVolumetrueBeta1.101.12
CSIPersistentVolumetrueGA1.131.16
CSIServiceAccountTokenfalseAlpha1.201.20
CSIServiceAccountTokentrueBeta1.211.21
CSIServiceAccountTokentrueGA1.221.24
CSIStorageCapacityfalseAlpha1.191.20
CSIStorageCapacitytrueBeta1.211.23
CSIStorageCapacitytrueGA1.241.27
CSIVolumeFSGroupPolicyfalseAlpha1.191.19
CSIVolumeFSGroupPolicytrueBeta1.201.22
CSIVolumeFSGroupPolicytrueGA1.231.25
CSRDurationtrueBeta1.221.23
CSRDurationtrueGA1.241.25
CustomPodDNSfalseAlpha1.91.9
CustomPodDNStrueBeta1.101.13
CustomPodDNStrueGA1.141.16
CustomResourceDefaultingfalseAlpha1.151.15
CustomResourceDefaultingtrueBeta1.161.16
CustomResourceDefaultingtrueGA1.171.18
CustomResourcePublishOpenAPIfalseAlpha1.141.14
CustomResourcePublishOpenAPItrueBeta1.151.15
CustomResourcePublishOpenAPItrueGA1.161.18
CustomResourceSubresourcesfalseAlpha1.101.10
CustomResourceSubresourcestrueBeta1.111.15
CustomResourceSubresourcestrueGA1.161.18
CustomResourceValidationfalseAlpha1.81.8
CustomResourceValidationtrueBeta1.91.15
CustomResourceValidationtrueGA1.161.18
CustomResourceValidationExpressionsfalseAlpha1.231.24
CustomResourceValidationExpressionstrueBeta1.251.28
CustomResourceValidationExpressionstrueGA1.291.30
CustomResourceWebhookConversionfalseAlpha1.131.14
CustomResourceWebhookConversiontrueBeta1.151.15
CustomResourceWebhookConversiontrueGA1.161.18
DaemonSetUpdateSurgefalseAlpha1.211.21
DaemonSetUpdateSurgetrueBeta1.221.24
DaemonSetUpdateSurgetrueGA1.251.28
DefaultPodTopologySpreadfalseAlpha1.191.19
DefaultPodTopologySpreadtrueBeta1.201.23
DefaultPodTopologySpreadtrueGA1.241.25
DelegateFSGroupToCSIDriverfalseAlpha1.221.22
DelegateFSGroupToCSIDrivertrueBeta1.231.25
DelegateFSGroupToCSIDrivertrueGA1.261.27
DevicePluginsfalseAlpha1.81.9
DevicePluginstrueBeta1.101.25
DevicePluginstrueGA1.261.27
DisableAcceleratorUsageMetricsfalseAlpha1.191.19
DisableAcceleratorUsageMetricstrueBeta1.201.24
DisableAcceleratorUsageMetricstrueGA1.251.27
DownwardAPIHugePagesfalseAlpha1.201.20
DownwardAPIHugePagesfalseBeta1.211.21
DownwardAPIHugePagestrueBeta1.221.26
DownwardAPIHugePagestrueGA1.271.28
DryRunfalseAlpha1.121.12
DryRuntrueBeta1.131.18
DryRuntrueGA1.191.27
DynamicAuditingfalseAlpha1.131.18
DynamicAuditing–Deprecated1.191.19
DynamicKubeletConfigfalseAlpha1.41.10
DynamicKubeletConfigtrueBeta1.111.21
DynamicKubeletConfigfalseDeprecated1.221.25
DynamicProvisioningSchedulingfalseAlpha1.111.11
DynamicProvisioningScheduling–Deprecated1.12–
DynamicVolumeProvisioningtrueAlpha1.31.7
DynamicVolumeProvisioningtrueGA1.81.12
EnableAggregatedDiscoveryTimeouttrueDeprecated1.161.17
EnableEquivalenceClassCachefalseAlpha1.81.12
EnableEquivalenceClassCache–Deprecated1.131.23
EndpointSlicefalseAlpha1.161.16
EndpointSlicefalseBeta1.171.17
EndpointSlicetrueBeta1.181.20
EndpointSlicetrueGA1.211.24
EndpointSliceNodeNamefalseAlpha1.201.20
EndpointSliceNodeNametrueGA1.211.24
EndpointSliceProxyingfalseAlpha1.181.18
EndpointSliceProxyingtrueBeta1.191.21
EndpointSliceProxyingtrueGA1.221.24
EndpointSliceTerminatingConditionfalseAlpha1.201.21
EndpointSliceTerminatingConditiontrueBeta1.221.25
EndpointSliceTerminatingConditiontrueGA1.261.27
EphemeralContainersfalseAlpha1.161.22
EphemeralContainerstrueBeta1.231.24
EphemeralContainerstrueGA1.251.26
EvenPodsSpreadfalseAlpha1.161.17
EvenPodsSpreadtrueBeta1.181.18
EvenPodsSpreadtrueGA1.191.21
ExpandCSIVolumesfalseAlpha1.141.15
ExpandCSIVolumestrueBeta1.161.23
ExpandCSIVolumestrueGA1.241.26
ExpandedDNSConfigfalseAlpha1.221.25
ExpandedDNSConfigtrueBeta1.261.27
ExpandedDNSConfigtrueGA1.281.29
ExpandInUsePersistentVolumesfalseAlpha1.111.14
ExpandInUsePersistentVolumestrueBeta1.151.23
ExpandInUsePersistentVolumestrueGA1.241.26
ExpandPersistentVolumesfalseAlpha1.81.10
ExpandPersistentVolumestrueBeta1.111.23
ExpandPersistentVolumestrueGA1.241.26
ExperimentalCriticalPodAnnotationfalseAlpha1.51.12
ExperimentalCriticalPodAnnotationfalseDeprecated1.131.16
ExperimentalHostUserNamespaceDefaultingfalseBeta1.51.27
ExperimentalHostUserNamespaceDefaultingfalseDeprecated1.281.29
ExternalPolicyForExternalIPtrueGA1.181.22
GCERegionalPersistentDisktrueBeta1.101.12
GCERegionalPersistentDisktrueGA1.131.16
GenericEphemeralVolumefalseAlpha1.191.20
GenericEphemeralVolumetrueBeta1.211.22
GenericEphemeralVolumetrueGA1.231.24
GRPCContainerProbefalseAlpha1.231.23
GRPCContainerProbetrueBeta1.241.26
GRPCContainerProbetrueGA1.271.28
HugePagesfalseAlpha1.81.9
HugePagestrueBeta1.101.13
HugePagestrueGA1.141.16
HugePageStorageMediumSizefalseAlpha1.181.18
HugePageStorageMediumSizetrueBeta1.191.21
HugePageStorageMediumSizetrueGA1.221.24
HyperVContainerfalseAlpha1.101.19
HyperVContainerfalseDeprecated1.201.20
IdentifyPodOSfalseAlpha1.231.23
IdentifyPodOStrueBeta1.241.24
IdentifyPodOStrueGA1.251.26
ImmutableEphemeralVolumesfalseAlpha1.181.18
ImmutableEphemeralVolumestrueBeta1.191.20
ImmutableEphemeralVolumestrueGA1.211.24
IndexedJobfalseAlpha1.211.21
IndexedJobtrueBeta1.221.23
IndexedJobtrueGA1.241.25
IngressClassNamespacedParamsfalseAlpha1.211.21
IngressClassNamespacedParamstrueBeta1.221.22
IngressClassNamespacedParamstrueGA1.231.24
InitializersfalseAlpha1.71.13
Initializers–Deprecated1.141.14
InTreePluginAWSUnregisterfalseAlpha1.211.30
InTreePluginAzureDiskUnregisterfalseAlpha1.211.30
InTreePluginAzureFileUnregisterfalseAlpha1.211.30
InTreePluginGCEUnregisterfalseAlpha1.211.30
InTreePluginOpenStackUnregisterfalseAlpha1.211.30
InTreePluginRBDUnregisterfalseAlpha1.231.27
InTreePluginRBDUnregisterfalseDeprecated1.281.30
InTreePluginvSphereUnregisterfalseAlpha1.211.30
IPTablesOwnershipCleanupfalseAlpha1.251.26
IPTablesOwnershipCleanuptrueBeta1.271.27
IPTablesOwnershipCleanuptrueGA1.281.29
IPv6DualStackfalseAlpha1.151.20
IPv6DualStacktrueBeta1.211.22
IPv6DualStacktrueGA1.231.24
JobMutableNodeSchedulingDirectivestrueBeta1.231.26
JobMutableNodeSchedulingDirectivestrueGA1.271.28
JobReadyPodsfalseAlpha1.231.23
JobReadyPodstrueBeta1.241.28
JobReadyPodstrueGA1.291.30
JobTrackingWithFinalizersfalseAlpha1.221.22
JobTrackingWithFinalizersfalseBeta1.231.24
JobTrackingWithFinalizerstrueBeta1.251.25
JobTrackingWithFinalizerstrueGA1.261.28
KubeletConfigFilefalseAlpha1.81.9
KubeletConfigFile–Deprecated1.101.10
KubeletCredentialProvidersfalseAlpha1.201.23
KubeletCredentialProviderstrueBeta1.241.25
KubeletCredentialProviderstrueGA1.261.28
KubeletPluginsWatcherfalseAlpha1.111.11
KubeletPluginsWatchertrueBeta1.121.12
KubeletPluginsWatchertrueGA1.131.16
KubeletPodResourcesfalseAlpha1.131.14
KubeletPodResourcestrueBeta1.151.27
KubeletPodResourcestrueGA1.281.29
KubeletPodResourcesGetAllocatablefalseAlpha1.211.22
KubeletPodResourcesGetAllocatabletrueBeta1.231.27
KubeletPodResourcesGetAllocatabletrueGA1.281.29
LegacyNodeRoleBehaviorfalseAlpha1.161.18
LegacyNodeRoleBehaviortrueBeta1.191.20
LegacyNodeRoleBehaviorfalseGA1.211.22
LegacyServiceAccountTokenNoAutoGenerationtrueBeta1.241.25
LegacyServiceAccountTokenNoAutoGenerationtrueGA1.261.28
LegacyServiceAccountTokenTrackingfalseAlpha1.261.26
LegacyServiceAccountTokenTrackingtrueBeta1.271.27
LegacyServiceAccountTokenTrackingtrueGA1.281.29
LocalStorageCapacityIsolationfalseAlpha1.71.9
LocalStorageCapacityIsolationtrueBeta1.101.24
LocalStorageCapacityIsolationtrueGA1.251.26
MinimizeIPTablesRestorefalseAlpha1.261.26
MinimizeIPTablesRestoretrueBeta1.271.27
MinimizeIPTablesRestoretrueGA1.281.29
MixedProtocolLBServicefalseAlpha1.201.23
MixedProtocolLBServicetrueBeta1.241.25
MixedProtocolLBServicetrueGA1.261.27
MountContainersfalseAlpha1.91.16
MountContainersfalseDeprecated1.171.17
MountPropagationfalseAlpha1.81.9
MountPropagationtrueBeta1.101.11
MountPropagationtrueGA1.121.14
MultiCIDRRangeAllocatorfalseAlpha1.251.28
NamespaceDefaultLabelNametrueBeta1.211.21
NamespaceDefaultLabelNametrueGA1.221.23
NetworkPolicyEndPortfalseAlpha1.211.21
NetworkPolicyEndPorttrueBeta1.221.24
NetworkPolicyEndPorttrueGA1.251.26
NetworkPolicyStatusfalseAlpha1.241.27
NodeDisruptionExclusionfalseAlpha1.161.18
NodeDisruptionExclusiontrueBeta1.191.20
NodeDisruptionExclusiontrueGA1.211.22
NodeLeasefalseAlpha1.121.13
NodeLeasetrueBeta1.141.16
NodeLeasetrueGA1.171.23
NonPreemptingPriorityfalseAlpha1.151.18
NonPreemptingPrioritytrueBeta1.191.23
NonPreemptingPrioritytrueGA1.241.25
OpenAPIV3falseAlpha1.231.23
OpenAPIV3trueBeta1.241.26
OpenAPIV3trueGA1.271.28
PersistentLocalVolumesfalseAlpha1.71.9
PersistentLocalVolumestrueBeta1.101.13
PersistentLocalVolumestrueGA1.141.16
PodAffinityNamespaceSelectorfalseAlpha1.211.21
PodAffinityNamespaceSelectortrueBeta1.221.23
PodAffinityNamespaceSelectortrueGA1.241.25
PodDisruptionBudgetfalseAlpha1.31.4
PodDisruptionBudgettrueBeta1.51.20
PodDisruptionBudgettrueGA1.211.25
PodHasNetworkConditionfalseAlpha1.251.27
PodOverheadfalseAlpha1.161.17
PodOverheadtrueBeta1.181.23
PodOverheadtrueGA1.241.25
PodPriorityfalseAlpha1.81.10
PodPrioritytrueBeta1.111.13
PodPrioritytrueGA1.141.18
PodReadinessGatesfalseAlpha1.111.11
PodReadinessGatestrueBeta1.121.13
PodReadinessGatestrueGA1.141.16
PodSecurityfalseAlpha1.221.22
PodSecuritytrueBeta1.231.24
PodSecuritytrueGA1.251.27
PodShareProcessNamespacefalseAlpha1.101.11
PodShareProcessNamespacetrueBeta1.121.16
PodShareProcessNamespacetrueGA1.171.19
PreferNominatedNodefalseAlpha1.211.21
PreferNominatedNodetrueBeta1.221.23
PreferNominatedNodetrueGA1.241.25
ProbeTerminationGracePeriodfalseAlpha1.211.21
ProbeTerminationGracePeriodfalseBeta1.221.24
ProbeTerminationGracePeriodtrueBeta1.251.27
ProbeTerminationGracePeriodtrueGA1.281.28
ProxyTerminatingEndpointsfalseAlpha1.221.25
ProxyTerminatingEndpointstrueBeta1.261.27
ProxyTerminatingEndpointstrueGA1.281.29
PVCProtectionfalseAlpha1.91.9
PVCProtection–Deprecated1.101.10
ReadOnlyAPIDataVolumestrueBeta1.81.9
ReadOnlyAPIDataVolumes–GA1.101.10
ReadWriteOncePodfalseAlpha1.221.26
ReadWriteOncePodtrueBeta1.271.28
ReadWriteOncePodtrueGA1.291.30
RemoveSelfLinkfalseAlpha1.161.19
RemoveSelfLinktrueBeta1.201.23
RemoveSelfLinktrueGA1.241.29
RequestManagementfalseAlpha1.151.16
RequestManagement–Deprecated1.171.17
ResourceLimitsPriorityFunctionfalseAlpha1.91.18
ResourceLimitsPriorityFunction–Deprecated1.191.19
ResourceQuotaScopeSelectorsfalseAlpha1.111.11
ResourceQuotaScopeSelectorstrueBeta1.121.16
ResourceQuotaScopeSelectorstrueGA1.171.18
RetroactiveDefaultStorageClassfalseAlpha1.251.25
RetroactiveDefaultStorageClasstrueBeta1.261.27
RetroactiveDefaultStorageClasstrueGA1.281.28
RootCAConfigMapfalseAlpha1.131.19
RootCAConfigMaptrueBeta1.201.20
RootCAConfigMaptrueGA1.211.22
RotateKubeletClientCertificatetrueBeta1.81.18
RotateKubeletClientCertificatetrueGA1.191.21
RunAsGrouptrueBeta1.141.20
RunAsGrouptrueGA1.211.22
RuntimeClassfalseAlpha1.121.13
RuntimeClasstrueBeta1.141.19
RuntimeClasstrueGA1.201.24
ScheduleDaemonSetPodsfalseAlpha1.111.11
ScheduleDaemonSetPodstrueBeta1.121.16
ScheduleDaemonSetPodstrueGA1.171.18
SCTPSupportfalseAlpha1.121.18
SCTPSupporttrueBeta1.191.19
SCTPSupporttrueGA1.201.22
SeccompDefaultfalseAlpha1.221.24
SeccompDefaulttrueBeta1.251.26
SeccompDefaulttrueGA1.271.28
SecurityContextDenyfalseAlpha1.271.29
SelectorIndexfalseAlpha1.181.18
SelectorIndextrueBeta1.191.19
SelectorIndextrueGA1.201.25
ServiceAccountIssuerDiscoveryfalseAlpha1.181.19
ServiceAccountIssuerDiscoverytrueBeta1.201.20
ServiceAccountIssuerDiscoverytrueGA1.211.23
ServiceAppProtocolfalseAlpha1.181.18
ServiceAppProtocoltrueBeta1.191.19
ServiceAppProtocoltrueGA1.201.22
ServiceInternalTrafficPolicyfalseAlpha1.211.21
ServiceInternalTrafficPolicytrueBeta1.221.25
ServiceInternalTrafficPolicytrueGA1.261.27
ServiceIPStaticSubrangefalseAlpha1.241.24
ServiceIPStaticSubrangetrueBeta1.251.25
ServiceIPStaticSubrangetrueGA1.261.27
ServiceLBNodePortControlfalseAlpha1.201.21
ServiceLBNodePortControltrueBeta1.221.23
ServiceLBNodePortControltrueGA1.241.25
ServiceLoadBalancerClassfalseAlpha1.211.21
ServiceLoadBalancerClasstrueBeta1.221.23
ServiceLoadBalancerClasstrueGA1.241.25
ServiceLoadBalancerFinalizerfalseAlpha1.151.15
ServiceLoadBalancerFinalizertrueBeta1.161.16
ServiceLoadBalancerFinalizertrueGA1.171.20
ServiceNodeExclusionfalseAlpha1.81.18
ServiceNodeExclusiontrueBeta1.191.20
ServiceNodeExclusiontrueGA1.211.22
ServiceNodePortStaticSubrangefalseAlpha1.271.27
ServiceNodePortStaticSubrangetrueBeta1.281.28
ServiceNodePortStaticSubrangetrueGA1.291.30
ServiceTopologyfalseAlpha1.171.19
ServiceTopologyfalseDeprecated1.201.22
SetHostnameAsFQDNfalseAlpha1.191.19
SetHostnameAsFQDNtrueBeta1.201.21
SetHostnameAsFQDNtrueGA1.221.24
SkipReadOnlyValidationGCEfalseAlpha1.281.28
SkipReadOnlyValidationGCEtrueDeprecated1.291.30
StartupProbefalseAlpha1.161.17
StartupProbetrueBeta1.181.19
StartupProbetrueGA1.201.23
StatefulSetMinReadySecondsfalseAlpha1.221.22
StatefulSetMinReadySecondstrueBeta1.231.24
StatefulSetMinReadySecondstrueGA1.251.26
StorageObjectInUseProtectiontrueBeta1.101.10
StorageObjectInUseProtectiontrueGA1.111.24
StreamingProxyRedirectsfalseBeta1.51.5
StreamingProxyRedirectstrueBeta1.61.17
StreamingProxyRedirectstrueDeprecated1.181.21
StreamingProxyRedirectsfalseDeprecated1.221.24
SupportIPVSProxyModefalseAlpha1.81.8
SupportIPVSProxyModefalseBeta1.91.9
SupportIPVSProxyModetrueBeta1.101.10
SupportIPVSProxyModetrueGA1.111.20
SupportNodePidsLimitfalseAlpha1.141.14
SupportNodePidsLimittrueBeta1.151.19
SupportNodePidsLimittrueGA1.201.23
SupportPodPidsLimitfalseAlpha1.101.13
SupportPodPidsLimittrueBeta1.141.19
SupportPodPidsLimittrueGA1.201.23
SuspendJobfalseAlpha1.211.21
SuspendJobtrueBeta1.221.23
SuspendJobtrueGA1.241.25
SysctlstrueBeta1.111.20
SysctlstrueGA1.211.22
TaintBasedEvictionsfalseAlpha1.61.12
TaintBasedEvictionstrueBeta1.131.17
TaintBasedEvictionstrueGA1.181.20
TaintNodesByConditionfalseAlpha1.81.11
TaintNodesByConditiontrueBeta1.121.16
TaintNodesByConditiontrueGA1.171.18
TokenRequestfalseAlpha1.101.11
TokenRequesttrueBeta1.121.19
TokenRequesttrueGA1.201.21
TokenRequestProjectionfalseAlpha1.111.11
TokenRequestProjectiontrueBeta1.121.19
TokenRequestProjectiontrueGA1.201.21
TopologyManagerfalseAlpha1.161.17
TopologyManagertrueBeta1.181.26
TopologyManagertrueGA1.271.28
TTLAfterFinishedfalseAlpha1.121.20
TTLAfterFinishedtrueBeta1.211.22
TTLAfterFinishedtrueGA1.231.24
UserNamespacesStatelessPodsSupportfalseAlpha1.251.27
ValidateProxyRedirectsfalseAlpha1.121.13
ValidateProxyRedirectstrueBeta1.141.21
ValidateProxyRedirectstrueDeprecated1.221.24
VolumePVCDataSourcefalseAlpha1.151.15
VolumePVCDataSourcetrueBeta1.161.17
VolumePVCDataSourcetrueGA1.181.21
VolumeSchedulingfalseAlpha1.91.9
VolumeSchedulingtrueBeta1.101.12
VolumeSchedulingtrueGA1.131.16
VolumeSnapshotDataSourcefalseAlpha1.121.16
VolumeSnapshotDataSourcetrueBeta1.171.19
VolumeSnapshotDataSourcetrueGA1.201.22
VolumeSubpathtrueGA1.101.24
VolumeSubpathEnvExpansionfalseAlpha1.141.14
VolumeSubpathEnvExpansiontrueBeta1.151.16
VolumeSubpathEnvExpansiontrueGA1.171.24
WarningHeaderstrueBeta1.191.21
WarningHeaderstrueGA1.221.24
WindowsEndpointSliceProxyingfalseAlpha1.191.20
WindowsEndpointSliceProxyingtrueBeta1.211.21
WindowsEndpointSliceProxyingtrueGA1.221.24
WindowsGMSAfalseAlpha1.141.15
WindowsGMSAtrueBeta1.161.17
WindowsGMSAtrueGA1.181.20
WindowsHostProcessContainersfalseAlpha1.221.22
WindowsHostProcessContainerstrueBeta1.231.25
WindowsHostProcessContainerstrueGA1.261.27
WindowsRunAsUserNamefalseAlpha1.161.16
WindowsRunAsUserNametrueBeta1.171.17
WindowsRunAsUserNametrueGA1.181.20

Опис вилучених функціональних можливостей

  • Accelerators: Надавав ранню форму втулка для ввімкнення підтримки графічного процесора Nvidia під час використання Docker Engine; більше не доступний. Див. Втулки пристроїв для альтернатив.

  • AdvancedAuditing: Вмикає розширений аудит

  • AffinityInAnnotations: Вмикає встановлення Спорідненість та антиспорідненість Podʼів.

  • AllowExtTrafficLocalEndpoints: Вмикає сервіс для маршрутизації зовнішніх запитів до локальних точок доступу вузла.

  • AllowInsecureBackendProxy: Дозволяє користувачам пропускати перевірку TLS для kubelet на запитах до логів Pod.

  • APIPriorityAndFairness: Дозволяє керувати паралельністю запитів за допомоги приорітезації та справедливості на кожному сервері. (Перейменовано з RequestManagement)

  • APISelfSubjectReview: Вмикає API SelfSubjectReview, який дозволяє користувачам бачити автентифікаційну інформацію субʼєкта запиту. Дивіться API доступу до автентифікаційної інформації для клієнта для більш детальної інформації.

  • AttachVolumeLimit: Вмикає втулки томів, щоб повідомляти про обмеження на кількість томів які може бути приєднано до вузла. Див. розділ динамічні обмеження тому для детальнішої інформації.

  • BalanceAttachedNodeVolumes: Включити підрахунок volume на вузлі, який слід враховувати для збалансованого розподілу ресурсів при плануванні. Вузлу, який має ближче завантаження процесора, завантаження памʼяті та кількість томів, віддається перевага при прийнятті рішень планувальником.

  • BlockVolume: Увімкніть визначення та споживання необроблених блокових пристроїв у Podʼах. Див. статтю Підтримка необроблених блокових томів для більш детальної інформації.

  • BoundServiceAccountTokenVolume:

    Переносить томи ServiceAccount для використання спроєцьованого тому, що складається з ServiceAccountTokenVolumeProjection. Адміністратори кластера можуть використовувати метрику serviceaccount_stale_tokens_total для моніторингу робочих навантажень, які залежать від розширених токенів. Якщо таких навантажень немає, вимкніть розширені токени, запустивши kube-apiserver з прапорцем --service-account-extend-token-expiration=false.

    Ознайомтеся зі статтею Привʼязані токени службових облікових записів для більш детальної інформації.

  • ConfigurableFSGroupPolicy: Дозволяє користувачеві налаштувати політику зміни дозволів на томи для fsGroups під час монтування тому в Pod. Див. Налаштування політики зміни дозволів на томи та права власності для Podʼів для більш детальної інформації.

  • ConsistentHTTPGetHandlers: Нормалізувати передачу URL-адреси та заголовка HTTP-запиту для життєвого циклу обробників з пробами.

  • ControllerManagerLeaderMigration: Вмикає міграцію лідерів для kube-controller-manager та cloud-controller-manager що дозволяє оператору кластера в реальному часі мігрувати контролери з kube-controller-manager у зовнішній контролер-менеджер (наприклад, cloud-controller-manager) у кластері HA без простоїв.

  • CRIContainerLogRotation: Вмикає ротацію логів контейнера для середовища виконання контейнерів CRI. Стандартний максимальний розмір файлу логу становить 10 МБ, а максимальна кількість файлів логу для контейнера — 5. Ці значення можна налаштувати у конфігурації kubelet. Див. статтю ведення логів на рівні вузла для більш детальної інформації.

  • CronJobControllerV2: Використовуйте альтернативну реалізацію контролера CronJob. В іншому випадку буде обрано версію 1 цього ж контролера.

  • CronJobTimeZone: Дозволити використання необовʼязкового поля timeZone у CronJobs

  • CSIBlockVolume: Вмикає підтримку блочного сховища зовнішніми драйверами томів CSI. Див. статтю Підтримка CSI для блочних томів для детальнішої інформації.

  • CSIDriverRegistry: Вмикає всю логіку, повʼязану з обʼєктом CSIDriver API в csi.storage.k8s.io.

  • CSIInlineVolume: Увімкніть підтримку томів CSI Inline для Podʼів.

  • CSIMigration: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка до втулка CSI.

  • CSIMigrationAWS: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка AWS-EBS до втулка EBS CSI. Підтримує відновлення до втулка EBS для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок EBS CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований.

  • CSIMigrationAWSComplete: Припиняє реєстрування вбудованих втулків EBS в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка EBS AWS до втулка EBS CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationAWS та встановленого та налаштованого втулка EBS CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginAWSUnregister, який перешкоджає реєстрації вбудованого втулка EBS.

  • CSIMigrationAzureDisk: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Azure-Disk до втулка AzureDisk CSI. Підтримує відновлення до втулка AzureDisk для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок AzureDisk CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationAzureDiskComplete: Припиняє реєстрування вбудованих втулків Azure-Disk в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка Azure-Disk до втулка AzureDisk CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationAzureDisk та встановленого та налаштованого втулка AzureDisk CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginAzureDiskUnregister, який перешкоджає реєстрації вбудованого втулка AzureDisk.

  • CSIMigrationAzureFile: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Azure-File до втулка AzureFile CSI. Підтримує відновлення до втулка AzureFile для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок AzureFile CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationAzureFileComplete: Припиняє реєстрування вбудованих втулків Azure-File в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка Azure-File до втулка AzureFile CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationAzureFile та встановленого та налаштованого втулка AzureFile CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginAzureFileUnregister, який перешкоджає реєстрації вбудованого втулка AzureFile.

  • CSIMigrationGCE: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка GCE-PD до втулка PD CSI. Підтримує відновлення до втулка PD для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок PD CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationGCEComplete: Припиняє реєстрування вбудованих втулків GCE-PD в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка GCE-PD до втулка GCE-PD CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationGCE та встановленого та налаштованого втулка GCE-PD CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginGCEUnregister, який перешкоджає реєстрації вбудованого втулка GCE-PD.

  • CSIMigrationOpenStack: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Cinder до втулка Cinder CSI. Підтримує відновлення до втулка Cinder для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок Cinder CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationOpenStackComplete: Припиняє реєстрування вбудованих втулків Cinder в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка Cinder до втулка Cinder CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationOpenStack та встановленого та налаштованого втулка Cinder CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginOpenStackUnregister, який перешкоджає реєстрації вбудованого втулка Cinder OpenStack.

  • CSIMigrationRBD:

    Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка RBD до втулка Ceph RBD CSI. Вимагає увімкнення функціональної можливості CSIMigration та встановлення та налаштування втулка Ceph CSI в кластері.

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

  • CSIMigrationvSphere: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка vSphere до втулка vSphere CSI. Підтримує відновлення до втулка vSphere для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок vSphere CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationvSphereComplete: Припиняє реєстрацію вбудованого втулка vSphere в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка vSphere до втулка vSphere CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationvSphere та встановленого та налаштованого втулка vSphere CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginvSphereUnregister, який перешкоджає реєстрації вбудованого втулка vSphere.

  • CSINodeExpandSecret: Вмикає передачу секретних даних автентифікації до втулка CSI для використання під час операції NodeExpandVolume CSI.

  • CSINodeInfo: Вмикає всю логіку, повʼязану з обʼєктом API CSINodeInfo в csi.storage.k8s.io.

  • CSIPersistentVolume: Вмикає виявлення та монтування томів, які надаються через сумісний втулок томів CSI (Container Storage Interface).

  • CSIServiceAccountToken: Дозволяє CSI-драйверам отримувати токен службового облікового запису для Podʼів, для яких вони монтували томи. Див. Запити токенів.

  • CSIStorageCapacity: Вмикає втулок CSI для публікації інформації про обсяг сховища та використання цієї інформації планувальником Kubernetes під час планування Podʼів. Див. Обсяг сховища. Для отримання додаткових відомостей див. документацію про типи томів csi.

  • CSIVolumeFSGroupPolicy: Дозволяє CSIDrivers використовувати поле fsGroupPolicy. Це поле керує тим, чи підтримують томи, створені CSIDriver, власність томів та зміни дозволів, коли ці томи монтуються.

  • CSRDuration: Дозволяє клієнтам запитувати час дії для сертифікатів, виданих через Kubernetes CSR API.

  • CustomPodDNS: Дозволяє змінювати налаштування DNS для Pod за допомогою властивості dnsConfig. Для отримання додаткової інформації див. DNS-налаштування Pod.

  • CustomResourceDefaulting: Вмикає підтримку CRD для стандартних значень в схемах перевірки OpenAPI v3.

  • CustomResourcePublishOpenAPI: Вмикає публікацію специфікацій CRD OpenAPI.

  • CustomResourceSubresources: Вмикає субресурси /status та /scale для ресурсів, створених з CustomResourceDefinition.

  • CustomResourceValidation: Вмикає перевірку на основі схеми для ресурсів, створених з CustomResourceDefinition.

  • CustomResourceValidationExpressions: Вмикає перевірку мови виразів у CRD, яка буде перевіряти власний ресурс клієнта на основі правил валідації, написаних у розширенні x-kubernetes-validations.

  • CustomResourceWebhookConversion: Вмикає конверсію на основі webhook для ресурсів, створених з CustomResourceDefinition.

  • DaemonSetUpdateSurge: Дозволяє робочим навантаженням DaemonSet зберігати доступність під час оновлення на кожному вузлі. Див. Виконання поетапного оновлення DaemonSet.

  • DefaultPodTopologySpread: Дозволяє використовувати втулок планування PodTopologySpread для виконання стандартного розподілу.

  • DelegateFSGroupToCSIDriver: Якщо підтримується драйвером CSI, делегує роль застосовуючи fsGroup з securityContext Pod до драйвера, передаючи fsGroup через виклики CSI NodeStageVolume та NodePublishVolume.

  • DevicePlugins: Вмикає device-plugins на основі виділення ресурсів на вузлах.

  • DisableAcceleratorUsageMetrics: Вимкнути метрики акселератора, що збираються kubelet.

  • DownwardAPIHugePages: Вмикає використання великих сторінок (hugepages) у downward API.

  • DryRun: Вмикає запити dry rin на боці сервера, щоб можна було тестувати валідацію, злиття та мутацію без впровадження змін.

  • DynamicAuditing: Використовувалося для увімкнення динамічного аудиту до версії 1.19.

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

  • DynamicProvisioningScheduling: Розширює стандартний планувальник, щоб врахувати топологію тома і обробляти виділення PV. Цю функцію було замінено функцією VolumeScheduling у версії 1.12.

  • DynamicVolumeProvisioning: Вмикає динамічне виділення постійних томів для Podʼів.

  • EnableAggregatedDiscoveryTimeout: Вмикає пʼятисекундний тайм-аут для агрегованих викликів виявлення.

  • EnableEquivalenceClassCache: Дозволяє планувальнику кешувати еквівалентність вузлів при плануванні Podʼів.

  • EndpointSlice: Вмикає EndpointSlices для більш масштабованих і розширюваних мережевих точок доступу. Див. статтю Увімкнення EndpointSlices.

  • EndpointSliceNodeName: Вмикає поле EndpointSlice nodeName.

  • EndpointSliceProxying: Якщо цю опцію увімкнено, kube-proxy на Linux використовуватиме EndpointSlices як основне джерело даних замість точок доступу, що дає змогу підвищити масштабованість і продуктивність. Див. статтю Увімкнення Endpoint Slices.

  • EndpointSliceTerminatingCondition: Вмикає поля умов terminating та serving EndpointSlice.

  • EphemeralContainers: Вмикає можливість додавання ефемерних контейнерів до запущених Podʼів.

  • EvenPodsSpread: Увімкнення рівномірного планування Podʼів у всіх топологіях доменів. Див. розділ Обмеження поширення топології Podʼів.

  • ExpandCSIVolumes: Дозволяє розширення томів CSI.

  • ExpandedDNSConfig: Дозволяє використовувати kubelet і kube-apiserver, щоб отримати більше шляхів пошуку DNS і довший список шляхів пошуку DNS. Ця функція потребує підтримки середовища виконання контейнерів (Containerd: v1.5.6 або новішої версії, CRI-O: v1.22 або новішої версії). Див. статтю Розширена конфігурація DNS.

  • ExpandInUsePersistentVolumes: Дозволяє розширювати використовувані постійні томи. Див. статтю Зміна розміру PersistentVolumeClaim.

  • ExpandPersistentVolumes: Дозволяє розширювати постійні томи. Див. статтю "Розширення Persistent Volumes Claims".

  • ExperimentalCriticalPodAnnotation: Увімкнути позначення певних Podʼів як критичних, щоб гарантувати їх планування. Ця функція застаріла внаслідок використання пріоритетів та випередження для Podʼів, починаючи з версії 1.13.

  • ExperimentalHostUserNamespaceDefaulting: Дозволяє встановлення стандартного простору імен для хосту. Призначено для контейнерів, які використовують інші простори імен хосту, монтування хосту або контейнери, які мають привілеї або використовують конкретні не іменовані можливості (наприклад, MKNODE, SYS_MODULE і т. д.). Слід вмикати лише у випадку, якщо перепризначення (remapping) просторів імен користувача увімкнено в демоні Docker.

  • ExternalPolicyForExternalIP: Виправляє помилку, коли ExternalTrafficPolicy не застосовується до Service ExternalIPs.

  • GCERegionalPersistentDisk: Увімкніть регіональну функцію PD у GCE.

  • GenericEphemeralVolume: Дозволяє створювати ефемерні, вбудовані томи, які підтримують усі функції звичайних томів (можуть надаватися сторонніми постачальниками сховищ, відстеження ємності сховища, відновлення зі знімка тощо). Див. статтю Ефемерні томи.

  • GRPCContainerProbe: Вмикає метод gRPC для {Liveness,Readiness,Startup}Probe. Див. розділ Налаштування проб життєздатності, готовності та запуску.

  • HugePages: Увімкніть виділення та використання попередньо виділених величезних сторінок.

  • HugePageStorageMediumSize: Увімкніть підтримку декількох розмірів попередньо виділених величезних сторінок.

  • HyperVContainer: Вмикає ізоляцію Hyper-V для контейнерів Windows

  • IdentifyPodOS: Дозволяє вказати поле Pod OS. Це допомагає достовірно ідентифікувати операційну систему під час допуску до сервера API.

  • ImmutableEphemeralVolumes: Дозволяє позначати окремі Secrets та ConfigMaps як незмінні для кращої безпеки та продуктивності.

  • IndexedJob: Дозволяє контролеру Job керувати завершенням Pod за індексом завершення.

  • IngressClassNamespacedParams: Дозволяє посилатися на параметри в межах простору імен у ресурсі IngressClass. Ця можливість додає два поля — Scope та Namespace до IngressClass.spec.parameters.

  • Initializers: Дозволяє асинхронно координувати створення обʼєктів за допомогою втулка допуску Initializers.

  • InTreePluginAWSUnregister: Припиняє реєстрацію вбудованого втулка aws-ebs у kubelet та контролерах томів.

  • InTreePluginAzureDiskUnregister: Припиняє реєстрацію вбудованого втулка azuredisk у kubelet та контролерах томів.

  • InTreePluginAzureFileUnregister: Припиняє реєстрацію вбудованого втулка azurefile у kubelet та контролерах томів.

  • InTreePluginGCEUnregister: Припиняє реєстрацію вбудованого втулка gce-pd у kubelet та контролерах томів.

  • InTreePluginOpenStackUnregister: Припиняє реєстрацію вбудованого втулка OpenStack cinder у kubelet та контролерах томів.

  • InTreePluginRBDUnregister: Припиняє реєстрацію вбудованого втулка RBD у kubelet та контролерах томів.

  • InTreePluginvSphereUnregister: Припиняє реєстрацію вбудованого втулка vSphere у kubelet та контролерах томів.

  • IPTablesOwnershipCleanup: Це призводить до того, що kubelet більше не створює застарілі правила iptables.

  • IPv6DualStack: Вмикає підтримку подвійного стека для IPv6.

  • JobMutableNodeSchedulingDirectives: Дозволяє оновити директиви планування вузлів у шаблоні pod Job.

  • JobReadyPods: Дозволяє відстежувати кількість Podʼів, які мають стан Ready. Кількість Ready Podʼів записується у status Job.

  • JobTrackingWithFinalizers: Дозволяє відстежувати завершення Job, не покладаючись на те, що Pods залишаться в кластері на невизначений час. Контролер Job використовує завершувачі Pod і поле у статусі Job для відстеження завершених Podʼів, щоб зарахувати їх до списку завершених.

  • KubeletConfigFile: Дозволяє завантажувати конфігурацію kubelet з файлу, вказаного за допомогою конфігураційного файлу. Докладнішу інформацію див. у статті налаштування параметрів kubelet за допомогою конфігураційного файлу.

  • KubeletCredentialProviders: Вмикає постачальників облікових даних для kubelet exec для отримання облікових даних для отримання образів.

  • KubeletPluginsWatcher: Вмикає утиліту для відстеження втулків на основі проб, щоб дозволити kubelet виявляти втулки, такі як драйвери томів CSI.

  • KubeletPodResources: Вмикає ресурси точки доступу gRPC kubelet Pod. Докладніші відомості наведено у статті Підтримка моніторингу пристроїв.

  • KubeletPodResourcesGetAllocatable: Вмикає функцію GetAllocatableResources для ресурсів pod у kubelet. Цей API доповнює звіт про розподіл ресурсів

  • LegacyNodeRoleBehavior: Якщо вимкнено, застаріла поведінка балансувальників навантаження сервісів та вимкнення вузлів ігноруватиме мітку node-role.kubernetes.io/master на користь специфічних міток, що надаються мітками NodeDisruptionExclusion та ServiceNodeExclusion.

  • LegacyServiceAccountTokenNoAutoGeneration: Припиняє автоматичне створення токенів службових облікових записів на основі Secret.

  • LegacyServiceAccountTokenTracking: Відстеження використання токенів службових облікових записів, що базуються на Secret.

  • LocalStorageCapacityIsolation: Вмикає використання локального ефемерного сховища, а також властивість sizeLimit тома emptyDir.

  • MinimizeIPTablesRestore: Вмикає нову логіку покращення продуктивності в режимі kube-proxy iptables.

  • MixedProtocolLBService: Вмикає використання різних протоколів в одному екземплярі Service типу LoadBalancer.

  • MountContainers: Вмикає використання контейнерів утиліт на хості як монтувальника томів.

  • MountPropagation: Дозволяє надавати спільний доступ до тому, змонтованого одним контейнером, іншим контейнерам або Podʼам. Докладніші відомості наведено у статті поширення монтування.

  • MultiCIDRRangeAllocator: Вмикає розподільник діапазону MultiCIDR.

  • NamespaceDefaultLabelName: Налаштуйте API Server на встановлення незмінної мітки kubernetes.io/metadata.name у всіх просторах назв, що містить назву простору назв.

  • NetworkPolicyEndPort: Дозволяє визначити порти у правилі NetworkPolicy як діапазон номерів портів.

  • NetworkPolicyStatus: Вмикає субресурс status для обʼєктів NetworkPolicy.

  • NodeDisruptionExclusion: Дозволяє використовувати мітку вузла node.kubernetes.io/exclude-disruption, яка запобігає евакуації вузлів під час збоїв у зоні.

  • NodeLease: Увімкніть новий Lease API для звітування про пульс вузла, який може бути використаний як сигнал про стан вузла.

  • NonPreemptingPriority: Вмикає поле preemptionPolicy для PriorityClass та Pod.

  • OpenAPIV3: Дозволяє серверу API публікувати OpenAPI v3.

  • PersistentLocalVolumes: Вмикає використання типу тому local у Podʼах. Якщо запитується local том, необхідно вказати спорідненість тому до Podʼів.

  • PodAffinityNamespaceSelector: Вмикає функції селектора простору імен за спорідненістю Podʼа та CrossNamespacePodAffinity діапазону квотування.

  • PodDisruptionBudget: Вмикає PodDisruptionBudget.

  • PodHasNetworkCondition: Дозволити kubelet позначати стан PodHasNetwork для контейнерів. Його було перейменовано на PodReadyToStartContainersCondition у версії 1.28.

  • PodOverhead: Вмикає PodOverhead для врахування накладних витрат на Pod.

  • PodPriority: Дозволяє випередження та зміну планування Podʼів на основі їх пріоритетів.

  • PodReadinessGates: Дозволяє увімкнути налаштування поля PodReadinessGate для розширення оцінювання готовності Pod. Дивіться Готовність Podʼа для більш детальної інформації.

  • PodSecurity: Вмикає втулок допуску PodSecurity.

  • PodShareProcessNamespace: Вмикає параметр shareProcessNamespace у Pod для спільного використання єдиного простору імен процесів між контейнерами, запущеними у Pod. Більш детальну інформацію можна знайти у статті Спільний простір імен процесів між контейнерами у Pod.

  • PreferNominatedNode: Цей прапорець вказує планувальнику, чи будуть номіновані вузли перевірятися першими перед тим, як обходити всі інші вузли кластера.

  • ProbeTerminationGracePeriod: Вмикає налаштування рівня проби terminationGracePeriodSeconds у контейнерах Pod. Дивіться пропозицію щодо вдосконалення для більш детальної інформації.

  • ProxyTerminatingEndpoints: Дозволити kube-proxy обробляти завершення точок доступу, коли ExternalTrafficPolicy=Local.

  • PVCProtection: Вмикає запобігання видаленню PersistentVolumeClaim (PVC), коли він все ще використовується яким-небудь Pod.

  • ReadOnlyAPIDataVolumes:

    Встановлює configMap, secret, downwardAPI та projected тому для монтування в режимі "тільки читання".

    Починаючи з Kubernetes v1.10, ці типи томів завжди є тільки для читання, і ви не можете відмовитися від цього.

  • ReadWriteOncePod: Дозволяє використовувати ReadWriteOncePod режим доступу до PersistentVolume.

  • RemoveSelfLink: Встановлює поле .metadata.selfLink порожнім (порожній рядок) для всіх обʼєктів і колекцій. Це поле застаріло з випуску Kubernetes v1.16. Коли цю можливість увімкнено, поле .metadata.selfLink залишається частиною API Kubernetes, але завжди не встановлене.

  • RequestManagement: Дозволяє керувати паралельністю запитів з пріоритетами та справедливістю на кожному сервері API. Замінено на APIPriorityAndFairness з 1.17.

  • ResourceLimitsPriorityFunction: Вмикає функцію пріоритету планувальника, яка присвоює найнижчу можливу оцінку 1 вузлу, який задовольняє хоча б одному з лімітів процесора та памʼяті вхідного Podʼа. Це має на меті розірвати звʼязки між вузлами з однаковими оцінками.

  • ResourceQuotaScopeSelectors: Вмикає селектори області обмежень ресурсів.

  • RetroactiveDefaultStorageClass: Дозволяє призначати StorageClass незвʼязаним постійним томам (PVC) ретроактивно.

  • RootCAConfigMap: Налаштуйте kube-controller-manager на публікацію ConfigMap з назвою kube-root-ca.crt у кожному просторі імен. Цей ConfigMap містить пакет CA, який використовується для перевірки зʼєднань з kube-apiserver. Докладні відомості наведено у статті Токени привʼязаних службових облікових записів.

  • RotateKubeletClientCertificate: Вмикає ротацію клієнтського TLS-сертифікату в kubelet. Дивіться kubelet configuration для більш детальної інформації.

  • RunAsGroup: Вмикає контроль за первинним ідентифікатором групи, встановленим у процесах ініціалізації контейнерів.

  • RuntimeClass: Вмикає RuntimeClass для вибору конфігурацій середовища виконання контейнера.

  • ScheduleDaemonSetPods: Дозволяє Podʼам DemonSet плануватися стандартним планувальником замість контролера DaemonSet.

  • SCTPSupport: Вмикає значення protocol SCTP в означеннях Pod, Service, Endpoints, EndpointSlice та NetworkPolicy.

  • SeccompDefault: Дозволяє використовувати RuntimeDefault як стандартний профіль seccomp для всіх робочих навантажень. Профіль seccomp вказується в ecurityContext Pod та/або Container.

  • SecurityContextDeny: Ця можливість сигналізує про те, що контролер допуску SecurityContextDeny є застарілим.

  • SelectorIndex: Дозволяє використовувати індекси на основі міток і полів у кеші спостереження сервера API для прискорення роботи зі списками.

  • ServiceAccountIssuerDiscovery: Вмикає точки доступу OIDC discovery (URL видачі та JWKS) для видачі службових облікових записів в API-сервері. Див. Налаштування службових облікових записів для контейнерів Pod для отримання додаткових відомостей.

  • ServiceAppProtocol: Вмикає поле appProtocol у Services та Endpoints.

  • ServiceInternalTrafficPolicy: Вмикає поле internalTrafficPolicy у Services.

  • ServiceIPStaticSubrange: Вмикає стратегію розподілу службових кластерних IP-адрес, згідно з якою діапазон ClusterIP поділяється на частини. Динамічні адреси ClusterIP призначатимуться переважно з верхнього діапазону, що дасть змогу користувачам призначати статичні адреси ClusterIP з нижнього діапазону з низьким ризиком колізій. Докладніші відомості наведено у статті Уникнення колізій.

  • ServiceLBNodePortControl: Вмикає поле allocateLoadBalancerNodePorts у Services.

  • ServiceLoadBalancerClass: Вмикає поле loadBalancerClass у Services. Див. Вказання класу реалізації балансувальника навантаження

  • ServiceLoadBalancerFinalizer: Вмикає захист завершувача для Service load balancers.

  • ServiceNodeExclusion: Дозволяє виключати вузли з балансувальників навантаження, створених хмарним постачальником. Вузол може бути виключений, якщо він має мітку "node.kubernetes.io/exclude-from-external-load-balancers".

  • ServiceNodePortStaticSubrange: Дозволяє використовувати різні стратегії розподілу портів для Сервісів NodePort. Докладні відомості наведено у статті резервування діапазонів NodePort для уникнення колізій.

  • ServiceTopology: Вмикає сервіс для маршрутизації трафіку на основі топології вузлів кластера.

  • SetHostnameAsFQDN: Дозволяє вказати повне доменне імʼя (FQDN) як імʼя хосту Podʼів. Див. розділ Поле setHostnameAsFQDN у Pod.

  • SkipReadOnlyValidationGCE: Пропустити перевірку, що томи GCE PersistentDisk перебувають у режимі лише для читання.

  • StartupProbe: Вмикає пробу запуску в kubelet.

  • StatefulSetMinReadySeconds: Дозволяє контролеру StatefulSet дотримуватися значення minReadySeconds.

  • StorageObjectInUseProtection: Відкладення видалення обʼєктів PersistentVolume або PersistentVolumeClaim, якщо вони все ще використовуються.

  • StreamingProxyRedirects: Доручає серверу API перехоплювати (і виконувати) перенаправлення від бекенда ('kubelet') для потокових запитів. Прикладами потокових запитів є запити exec, attach і port-forward.

  • SupportIPVSProxyMode: Вмикає балансування навантаження сервісів у кластері за допомогою IPVS. Докладні відомості див. у статті проксі-сервери.

  • SupportNodePidsLimit: Вмикає підтримку обмеження PID на вузлі. Параметр pid=<number> в опціях --system-reserved і --kube-reserved можна вказати, щоб гарантувати, що вказану кількість ідентифікаторів процесів буде зарезервовано для системи в цілому і для системних демонів Kubernetes відповідно.

  • SupportPodPidsLimit: Вмикання підтримки обмеження PID у Podʼах.

  • SuspendJob: Дозволяє призупиняти та поновлювати виконання Jobs. Докладнішу інформацію дивіться у документації про Job.

  • Sysctls: Вмикання підтримки параметрів ядра у просторі імен (sysctls), які можна задавати для кожного з Podʼів. Докладні відомості наведено у sysctls.

  • TaintBasedEvictions: Дозволяє виселяти Podʼи з вузлів на основі taints на вузлах і толерантностей на Podʼах. Детальніше дивіться у статті taint та tolerances.

  • TaintNodesByCondition: Дозволяє автоматичне позначення вузлів taints на основі станів вузлів.

  • TokenRequest: Вмикає точку доступу TokenRequest для ресурсів службових облікових записів.

  • TokenRequestProjection: Вмикає інʼєкцію токенів службових облікових записів у Pod через projected том.

  • TopologyManager: Вмикання механізму для координації тонких призначень апаратних ресурсів для різних компонентів у Kubernetes. Див. розділ Керування політиками керування топологією на вузлі.

  • TTLAfterFinished: Дозволити TTL-контролеру очищати ресурси після завершення їх виконання.

  • UserNamespacesStatelessPodsSupport: Увімкніть підтримку простору імен користувачів для stateless Podʼів. Ці функціональні можливості були замінені на UserNamespacesSupport у випуску Kubernetes v1.28.

  • ValidateProxyRedirects: Цей прапорець визначає, чи повинен сервер API перевіряти, що перенаправлення виконуються тільки на той самий хост. Використовується лише якщо увімкнено прапорець StreamingProxyRedirects.

  • VolumePVCDataSource: Підтримка вказівки існуючого PVC як DataSource.

  • VolumeScheduling: Вмикає планування з урахуванням топології тома і робить привʼязку PersistentVolumeClaim (PVC) обізнаною з рішеннями щодо планування. Це також дозволяє використовувати тип тома local при використанні разом з функціональною можливістю PersistentLocalVolumes.

  • VolumeSnapshotDataSource: Вмикання підтримки джерела даних для створення знімків томів.

  • VolumeSubpath: Дозволяє монтувати субшлях тому в контейнері.

  • VolumeSubpathEnvExpansion: Вмикання поля SubPathExpr для розгортання змінних оточення у SubPath.

  • WarningHeaders: Дозволяє надсилати заголовки попередження в відповідях API.

  • WindowsEndpointSliceProxying: Якщо увімкнено, kube-proxy, що працює на Windows, використовуватиме EndpointSlices як основне джерело даних замість Endpoints, що забезпечує масштабованість і покращення продуктивності. Див. статтю Увімкнення Endpoint Slices.

  • WindowsGMSA: Дозволяє передавати специфікацію облікових даних GMSA від Podʼів до середовища виконання контейнера.

  • WindowsHostProcessContainers: Вмикає підтримку контейнерів Windows HostProcess.

  • WindowsRunAsUserName: Вмикання підтримки запуску програм у контейнерах Windows від імені не типового користувача. Докладні відомості наведено у статті Налаштування RunAsUserName.

12.3 - kubelet

Огляд

Kubelet є основним "агентом вузла", який працює на кожному вузлі. Він може зареєструвати вузол на apiserver, використовуючи одне з наступного: імʼя хосту; прапорець для перевизначення імені хоста; або спеціальну логіку для провайдера хмарних послуг.

Kubelet працює в термінах PodSpec. PodSpe — це обʼєкт YAML або JSON, який описує Pod. Kubelet приймає набір PodSpec, які надаються різними механізмами (переважно через apiserver) і забезпечує, що контейнери, описані в цих PodSpec, працюють і є справними. Kubelet не управляє контейнерами, які не були створені Kubernetes.

Крім PodSpec з apiserver, є два способи, як маніфест контейнера може бути наданий kubelet.

  • Файл: Шлях, переданий як прапорець у командному рядку. Файли за цим шляхом будуть періодично моніторитися на наявність оновлень. Період моніторингу стандартно становить 20 секунд і налаштовується за допомогою прапорця.
  • HTTP endpoint: HTTP endpoint, переданий як параметр у командному рядку. Цей endpoint перевіряється кожні 20 секунд (також налаштовується за допомогою прапорця).
kubelet [flags]

Параметри

--address string     Типово: 0.0.0.0
IP-адреса, на якій буде працювати kubelet (встановіть 0.0.0.0 або :: для прослуховування на всіх інтерфейсах та в усіх сімействах IP-адрес) (ЗАСТАРІЛО: Цей параметр слід встановлювати через конфігураційний файл, вказаний прапорцем --config kubelet. Дивіться kubelet-config-file для отримання додаткової інформації.)
--allowed-unsafe-sysctls strings
Список небезпечних sysctl або шаблонів sysctl, розділених комами (завершуються на *). Використовуйте їх на свій ризик. (ЗАСТАРІЛО: Цей параметр слід встановлювати через конфігураційний файл, вказаний прапорцем --config kubelet. Дивіться kubelet-config-file для отримання додаткової інформації.)
--anonymous-auth     Типово: true
Дозволяє анонімні запити до сервера kubelet. Запити, які не відхилені іншим методом автентифікації, розглядаються як анонімні. Анонімні запити мають імʼя користувача system:anonymous та імʼя групи system:unauthenticated. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authentication-token-webhook
Використовуйте API TokenReview для визначення автентифікації за допомогою маркерів доступу. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authentication-token-webhook-cache-ttl duration     Типово: 2m0s
Тривалість кешування відповідей від вебхук аутентифікатора маркерів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authorization-mode string     Типово: AlwaysAllow
Режим авторизації для сервера kubelet. Дійсні варіанти — "AlwaysAllow" або "Webhook". Режим Webhook використовує API SubjectAccessReview для визначення авторизації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authorization-webhook-cache-authorized-ttl duration     Типово: 5m0s
Тривалість кешування відповідей "authorized" від вебхук авторизатора. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authorization-webhook-cache-unauthorized-ttl duration     Типово: 30s
Тривалість кешування відповідей "unauthorized" від веб-хук авторизатора. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--bootstrap-kubeconfig string
Шлях до файлу kubeconfig, який буде використовуватися для отримання клієнтського сертифіката для kubelet. Якщо файл, вказаний прапорцем --kubeconfig, не існує, використовується файл bootstrap kubeconfig для запиту клієнтського сертифіката від API сервера. У разі успіху, файл kubeconfig, що посилається на згенерований клієнтський сертифікат і ключ, буде записано за шляхом, вказаним прапорцем --kubeconfig. Файл клієнтського сертифіката і ключа буде збережено в теці, на яку вказує прапорець --cert-dir.
--cert-dir string     Типово: /var/lib/kubelet/pki
Тека, де розташовані TLS сертифікати. Якщо вказані прапорці --tls-cert-file та --tls-private-key-file, цей прапорець буде ігноруватися.
--cgroup-driver string     Типово: cgroupfs
Драйвер, який kubelet використовує для управління cgroups на хості. Можливі значення: "cgroupfs", "systemd". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cgroup-root string     Типово: ''
Необовʼязковий кореневий cgroup для використання з Podʼами. Обробляється контейнерним середовищем на основі принципу найкращих зусиль. Типово: '', що означає використання стандартного значення контейнерного середовища. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cgroups-per-qos     Типово: true
Увімкнути створення ієрархії QoS cgroup. Якщо це вірно, створюються cgroup верхнього рівня QoS та cgroup Podʼів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--client-ca-file string
Якщо встановлено, будь-який запит, що містить клієнтський сертифікат, підписаний однією з організацій, зазначених у файлі client-ca-file, буде автентифіковано з ідентичністю, що відповідає CommonName клієнтського сертифіката. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cloud-config string
Шлях до файлу конфігурації постачальника хмари. Порожній рядок означає відсутність файлу конфігурації. (ЗАСТАРІЛО: буде видалено в версії 1.25 або пізніше, на користь видалення коду постачальників хмари з kubelet.)
--cloud-provider string
Постачальник для хмарних сервісів. Встановіть порожній рядок для запуску без постачальника хмари. Встановіть 'external' для запуску з зовнішнім постачальником хмари. Якщо встановлено, постачальник хмари визначає імʼя вузла (консультуйтеся з документацією постачальника хмари, щоб дізнатися, чи і як використовується імʼя хоста).
--cluster-dns strings
Список IP-адрес DNS-серверів, розділений комами. Це значення використовується для DNS-серверів контейнерів у випадку Podʼів з "dnsPolicy: ClusterFirst".
Примітка: всі DNS-сервери у списку МАЮТЬ обслуговувати один і той же набір записів, інакше розвʼязання імен у кластері може працювати некоректно. Немає гарантії, який саме DNS-сервер буде використовуватися для розвʼязання імен. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cluster-domain string
Домен для цього кластера. Якщо встановлено, kubelet налаштує всі контейнери для пошуку в цьому домені на додаток до пошукових доменів хоста. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--config string
Kubelet завантажить свою початкову конфігурацію з цього файлу. Шлях може бути абсолютним або відносним; відносні шляхи починаються з поточної робочої теки kubelet. Пропустіть цей прапорець, щоб використовувати вбудовані стандартні значення конфігурації. Прапорці командного рядка переважають над конфігурацією з цього файлу.
--config-dir string     Типово: ''
Шлях до теки для вказівки додаткових конфігурацій, що дозволяє користувачу за бажанням зазначити додаткові конфігурації для перевизначення значень, що надаються стандартно і в прапорці `--config`.
Примітка: Встановіть змінну середовища 'KUBELET_CONFIG_DROPIN_DIR_ALPHA', щоб вказати теку.
--container-log-max-files int32     Типово: 5
<Увага: бета-функція> Встановіть максимальну кількість файлів логів контейнерів, які можуть бути присутніми для контейнера. Число має бути >= 2. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--container-log-max-size string     Типово: 10Mi
<Увага: бета-функція> Встановіть максимальний розмір (наприклад, 10Mi) файлу логу контейнера до того, як буде виконано його ротацію. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--container-runtime-endpoint string     Типово: "unix:///run/containerd/containerd.sock"
Точка доступу до віддаленого сервісу. UNIX доменні сокети підтримуються в Linux, тоді як точки доступу 'npipe' і 'tcp' підтримуються у Windows. Приклади: 'unix:///path/to/runtime.sock', 'npipe:////./pipe/runtime'. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--contention-profiling
Дозволяє профілювання блоків, якщо профілювання увімкнено. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-cfs-quota     Типово: true
Вмикає застосування квоти CPU CFS для контейнерів, у яких вказано ліміти CPU. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-cfs-quota-period duration     Типово: 100ms
Встановлює значення періоду квоти CPU CFS, cpu.cfs_period_us, зазвичай використовується стандартне значення ядра Linux. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-manager-policy string     Типово: none
Політика керування CPU для використання. Можливі значення: "none", "static". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-manager-policy-options string
Набір параметрів політики " key=value" менеджера процесорів, які можна використовувати для точного налаштування їхньої поведінки. Якщо не надано, залишити стандартну поведінку. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-manager-reconcile-period duration     Типово: 10s
<Увага: альфа-функція> Період узгодження політики керування CPU. Приклади: "10s", або "1m". Якщо не вказано, використовується стандартна частота оновлення статусу вузла. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enable-controller-attach-detach     Типово: true
Дозволяє контролеру Attach/Detach керувати приєднанням/відʼєднанням томів, запланованих до цього вузла, і забороняє kubelet виконувати будь-які операції приєднання/відʼєднання. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enable-debugging-handlers     Типово: true
Вмикає серверні точки доступу для збору логів та локального запуску контейнерів і команд. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enable-server     Типово: true
Вмикає сервер kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enforce-node-allocatable strings     Типово: pods
Список рівнів застосування обмежень розподілу ресурсів вузла, розділений комами, який буде застосовуватися kubelet. Прийнятні опції: "none", "pods", "system-reserved" та "kube-reserved". Якщо зазначені останні дві опції, обовʼязково також встановити --system-reserved-cgroup і --kube-reserved-cgroup, відповідно. Якщо зазначено "none", додаткові опції не повинні бути встановлені. Дивіться офіційну документацію для отримання додаткової інформації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--event-burst int32     Типово: 100
Максимальний розмір сплеску записів подій, тимчасово дозволяє записам подій збільшуватися до цього числа, не перевищуючи --event-qps. Число має бути >= 0. Якщо встановлено 0, буде використано стандартне значення (100). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--event-qps int32     Типово: 50
QPS для обмеження створення подій. Число має бути >= 0. Якщо 0, буде використано стандартне значення QPS (50). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-hard strings     Типово: imagefs.available<15%,memory.available<100Mi,nodefs.available<10%
Набір порогів виселення (наприклад, "memory.available<1Gi"), досягнення яких спричиняє виселення Podʼів. На вузлі Linux стандартне значення також включає "nodefs.inodesFree<5%". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-max-pod-grace-period int32
Максимальний допустимий період завершення (в секундах) для використання при завершенні Podʼів у відповідь на досягнення мʼякого порогу виселення. Якщо значення відʼємне, використовувати значення, вказане у Podʼі. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-minimum-reclaim strings
Набір мінімальних відновлень (наприклад, "imagefs.available=2Gi"), що описує мінімальну кількість ресурсів, яку kubelet буде відновлювати під час виселення Podʼів, якщо цей ресурс знаходиться під тиском. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-pressure-transition-period duration     Типово: 5m0s
Тривалість, протягом якої kubelet має чекати перед виходом із стану тиску виселення. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-soft strings
Набір порогів виселення (наприклад, "memory.available<1.5Gi"), які при досягненні протягом відповідного пільгового періоду спричинять виселення Podʼів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-soft-grace-period strings
Набір пільгових періодів виселення (наприклад, "memory.available=1m30s"), які відповідають тривалості, протягом якої мʼякий поріг виселення має утримуватись перед тим, як буде ініційовано виселення Podʼів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--exit-on-lock-contention
Чи повинен kubelet завершити роботу після конфлікту файлів блокування.
--experimental-allocatable-ignore-eviction     Типово: false
Якщо встановлено true, жорсткі пороги виселення будуть ігноруватися при розрахунку доступних ресурсів вузла. Дивіться тут для отримання додаткової інформації. (ЗАСТАРІЛО: буде видалено в версії 1.25 або пізніше)
--experimental-mounter-path string     Типово: mount
[Експериментально] Шлях до виконуваного файлу монтувальника. Залиште порожнім, щоб використовувати стандартний mount. (ЗАСТАРІЛО: буде видалено в версії 1.24 або пізніше на користь використання CSI.)
--fail-swap-on     Типово: true
Змушує kubelet не запускатися, якщо на вузлі увімкнено своп. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--feature-gates <Перелік пар 'key=true/false'>
Набір пар key=value, що містить опис функціональних можливостей рівня alpha/experimental. Можливі варіанти:
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (BETA - default=true)
APIServerTracing=true|false (BETA - default=true)
APIServingWithRoutine=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (BETA - default=true)
AppArmor=true|false (BETA - default=true)
AppArmorFields=true|false (BETA - default=true)
CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (BETA - default=true)
CRDValidationRatcheting=true|false (BETA - default=true)
CSIMigrationPortworx=true|false (BETA - default=false)
CSIVolumeHealth=true|false (ALPHA - default=false)
CloudControllerManagerWebhook=true|false (ALPHA - default=false)
ClusterTrustBundle=true|false (ALPHA - default=false)
ClusterTrustBundleProjection=true|false (ALPHA - default=false)
ComponentSLIs=true|false (BETA - default=true)
ConsistentListFromCache=true|false (ALPHA - default=false)
ContainerCheckpoint=true|false (BETA - default=true)
ContextualLogging=true|false (BETA - default=true)
CronJobsScheduledAnnotation=true|false (BETA - default=true)
CrossNamespaceVolumeDataSource=true|false (ALPHA - default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceFieldSelectors=true|false (ALPHA - default=false)
DevicePluginCDIDevices=true|false (BETA - default=true)
DisableCloudProviders=true|false (BETA - default=true)
DisableKubeletCloudCredentialProviders=true|false (BETA - default=true)
DisableNodeKubeProxyVersion=true|false (ALPHA - default=false)
DynamicResourceAllocation=true|false (ALPHA - default=false)
ElasticIndexedJob=true|false (BETA - default=true)
EventedPLEG=true|false (ALPHA - default=false)
GracefulNodeShutdown=true|false (BETA - default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
HPAScaleToZero=true|false (ALPHA - default=false)
HonorPVReclaimPolicy=true|false (ALPHA - default=false)
ImageMaximumGCAge=true|false (BETA - default=true)
InPlacePodVerticalScaling=true|false (ALPHA - default=false)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
InformerResourceVersion=true|false (ALPHA - default=false)
JobBackoffLimitPerIndex=true|false (BETA - default=true)
JobManagedBy=true|false (ALPHA - default=false)
JobPodFailurePolicy=true|false (BETA - default=true)
JobPodReplacementPolicy=true|false (BETA - default=true)
JobSuccessPolicy=true|false (ALPHA - default=false)
KubeProxyDrainingTerminatingNodes=true|false (BETA - default=true)
KubeletCgroupDriverFromCRI=true|false (ALPHA - default=false)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResourcesDynamicResources=true|false (ALPHA - default=false)
KubeletPodResourcesGet=true|false (ALPHA - default=false)
KubeletSeparateDiskGC=true|false (ALPHA - default=false)
KubeletTracing=true|false (BETA - default=true)
LoadBalancerIPMode=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
LoggingAlphaOptions=true|false (ALPHA - default=false)
LoggingBetaOptions=true|false (BETA - default=true)
MatchLabelKeysInPodAffinity=true|false (ALPHA - default=false)
MatchLabelKeysInPodTopologySpread=true|false (BETA - default=true)
MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MultiCIDRServiceAllocator=true|false (ALPHA - default=false)
MutatingAdmissionPolicy=true|false (ALPHA - default=false)
NFTablesProxyMode=true|false (ALPHA - default=false)
NodeInclusionPolicyInPodTopologySpread=true|false (BETA - default=true)
NodeLogQuery=true|false (BETA - default=false)
NodeSwap=true|false (BETA - default=true)
OpenAPIEnums=true|false (BETA - default=true)
PDBUnhealthyPodEvictionPolicy=true|false (BETA - default=true)
PersistentVolumeLastPhaseTransitionTime=true|false (BETA - default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
PodDeletionCost=true|false (BETA - default=true)
PodDisruptionConditions=true|false (BETA - default=true)
PodIndexLabel=true|false (BETA - default=true)
PodLifecycleSleepAction=true|false (BETA - default=true)
PodReadyToStartContainersCondition=true|false (BETA - default=true)
PortForwardWebsockets=true|false (ALPHA - default=false)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
RecursiveReadOnlyMounts=true|false (ALPHA - default=false)
RelaxedEnvironmentVariableValidation=true|false (ALPHA - default=false)
RetryGenerateName=true|false (ALPHA - default=false)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RuntimeClassInImageCriApi=true|false (ALPHA - default=false)
SELinuxMount=true|false (ALPHA - default=false)
SELinuxMountReadWriteOncePod=true|false (BETA - default=true)
SchedulerQueueingHints=true|false (BETA - default=false)
SeparateCacheWatchRPC=true|false (BETA - default=true)
SeparateTaintEvictionController=true|false (BETA - default=true)
ServiceAccountTokenJTI=true|false (BETA - default=true)
ServiceAccountTokenNodeBinding=true|false (ALPHA - default=false)
ServiceAccountTokenNodeBindingValidation=true|false (BETA - default=true)
ServiceAccountTokenPodNodeInfo=true|false (BETA - default=true)
ServiceTrafficDistribution=true|false (ALPHA - default=false)
SidecarContainers=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetAutoDeletePVC=true|false (BETA - default=true)
StatefulSetStartOrdinal=true|false (BETA - default=true)
StorageNamespaceIndex=true|false (BETA - default=true)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
StorageVersionMigrator=true|false (ALPHA - default=false)
StructuredAuthenticationConfiguration=true|false (BETA - default=true)
StructuredAuthorizationConfiguration=true|false (BETA - default=true)
TopologyAwareHints=true|false (BETA - default=true)
TopologyManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
TopologyManagerPolicyBetaOptions=true|false (BETA - default=true)
TopologyManagerPolicyOptions=true|false (BETA - default=true)
TranslateStreamCloseWebsocketRequests=true|false (BETA - default=true)
UnauthenticatedHTTP2DOSMitigation=true|false (BETA - default=true)
UnknownVersionInteroperabilityProxy=true|false (ALPHA - default=false)
UserNamespacesPodSecurityStandards=true|false (ALPHA - default=false)
UserNamespacesSupport=true|false (BETA - default=false)
VolumeAttributesClass=true|false (ALPHA - default=false)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WatchFromStorageWithoutResourceVersion=true|false (BETA - default=false)
WatchList=true|false (ALPHA - default=false)
WatchListClient=true|false (BETA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostNetwork=true|false (ALPHA - default=true)

(ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--file-check-frequency duration     Типово: 20s
Тривалість між перевірками конфігураційних файлів на наявність нових даних. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--hairpin-mode string     Типово: promiscuous-bridge
Як kubelet повинен налаштовувати hairpin NAT. Це дозволяє точкам доступу Service балансувати навантаження назад на себе, якщо вони намагаються отримати доступ до власного Service. Допустимі значення: "promiscuous-bridge", "hairpin-veth" та "none". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--healthz-bind-address string     Типово: 127.0.0.1
IP-адреса, на якій буде працювати сервер healthz (встановіть на "0.0.0.0" або "::" для прослуховування на всіх інтерфейсах та IP-сімействах). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--healthz-port int32     Типово: 10248
Порт точки доступу healthz на localhost (встановіть 0 щоб вимкнути). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
-h, --help
Довідка kubelet
--hostname-override string
Якщо не порожній, буде використовуватися цей рядок як ідентифікатор замість фактичного імені хоста. Якщо встановлено --cloud-provider, постачальник хмарних послуг визначає імʼя вузла (звіртесь з документацією постачальника хмарних послуг, щоб дізнатися, як використовується імʼя хосту).
--http-check-frequency duration     Типово: 20s
Тривалість між перевірками HTTP на наявність нових даних. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--image-credential-provider-bin-dir string
Шлях до теки, де знаходяться двійкові файли втулка постачальника облікових даних.
--image-credential-provider-config string
Шлях до конфігураційного файлу втулка постачальника облікових даних.
--image-gc-high-threshold int32     Типово: 85
Відсоток використання диска, після якого завжди виконується видалення непотрібних образів. Значення має бути в діапазоні [0, 100], щоб вимкнути збирання сміття, встановіть значення 100. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--image-gc-low-threshold int32     Типово: 80
Відсоток використання диска, до якого прибирання образів ніколи не виконується. Найменше використання диска, при якому проводиться збір сміття. Значення повинні бути в межах [0, 100] і не повинні перевищувати значення --image-gc-high-threshold. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--image-service-endpoint string
Точка доступу до віддаленого сервісу образів. Якщо не вказано, стандартно буде така ж, як і у --container-runtime-endpoint. UNIX доменні сокети підтримуються в Linux, тоді як точки доступу `npipe` і `tcp` підтримуються у Windows. Приклади: unix:///path/to/runtime.sock, npipe:////./pipe/runtime. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--keep-terminated-pod-volumes
Зберігати змонтовані томи завершених Podʼів на вузлі після завершення роботи Podʼів. Може бути корисним для відлагодження проблем, повʼязаних з томами. (DEPRECATED: will be removed in a future version)
--kernel-memcg-notification
Якщо увімкнено, kubelet буде інтегруватися з повідомленням memcg ядра для визначення, чи перевищено порогові значення пам’яті для виселення, замість періодичного опитування. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-api-burst int32     Типово: 100
Сплеск, який буде використовуватися при спілкуванні з API сервером Kubernetes. Число має бути >= 0. Якщо встановлено 0, буде використано стандартне значення (100). Не стосується пудьсу API подій та вузлів, для яких обмеження швидкості контролюється іншим набором прапорців. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-api-content-type string     Типово: application/vnd.kubernetes.protobuf
Тип вмісту запитів, що надсилаються до apiserver. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-api-qps int32     Типово: 50
QPS, який буде використовуватися при спілкуванні з API сервером Kubernetes. Число має бути >= 0. Якщо встановлено 0, буде використано стандартне значення (50). Не стосується пульсу API подій та вузлів, для яких обмеження швидкості контролюється іншим набором прапорців. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-reserved strings     Типово: <None>
Набір пар <resource name>=<resource quantity> (наприклад, "cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'"), які описують ресурси, зарезервовані для компонентів системи Kubernetes. В даний час підтримуються cpu, memory та локальне ephemeral-storage для кореневої файлової системи. Дивіться тут для отримання додаткової інформації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-reserved-cgroup string     Типово: ''
Абсолютне імʼя верхнього рівня cgroup, яке використовується для управління компонентами Kubernetes, для яких ресурси обчислення були зарезервовані за допомогою прапорця --kube-reserved. Наприклад, "/kube-reserved". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kubeconfig string
Шлях до файлу kubeconfig, що визначає, як підключитися до API сервера. Надання --kubeconfig увімкне режим API сервера, тоді як пропуск --kubeconfig увімкне автономний (standalone) режим.
--kubelet-cgroups string
Необовʼязкове абсолютне імʼя cgroups для створення та запуску kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--local-storage-capacity-isolation>     Типово: true
Якщо true, увімкнено ізоляцію локального тимчасового зберігання. Інакше функція ізоляції локального зберігання буде вимкнена. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--lock-file string
<Попередження: Альфа функція> Шлях до файлу, який kubelet використовуватиме як файл блокування.
--log-flush-frequency duration     Типово: 5s
Максимальна кількість секунд між очищеннями логу.
--log-json-info-buffer-size string     Типово: '0'
[Alpha] У форматі JSON з розділеними вихідними потоками інформаційні повідомлення можуть бути буферизовані на деякий час для підвищення продуктивності. Стандартне значення, що дорівнює нулю байтів, вимикає буферизацію. Розмір може бути вказаний у байтах (512), кратних 1000 (1K), кратних 1024 (2Ki) або степенях цих значень (3M, 4G, 5Mi, 6Gi). Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--log-json-split-stream
[Alpha] У форматі JSON помилки записуються у stderr, а інформаційні повідомлення — у stdout. Стандартно всі повідомлення записуються в один потік stdout. Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--log-text-info-buffer-size string     Типово: '0'
[Alpha] У текстовому форматі з розділеними вихідними потоками інформаційні повідомлення можуть бути буферизовані на деякий час для підвищення продуктивності. Стандартне значення, що дорівнює нулю байтів, вимикає буферизацію. Розмір може бути вказаний у байтах (512), кратних 1000 (1K), кратних 1024 (2Ki) або степенях цих значень (3M, 4G, 5Mi, 6Gi). Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--log-text-split-stream
[Alpha] У текстовому форматі помилки записуються у stderr, а інформаційні повідомлення — у stdout. Стандартно всі повідомлення записуються в один потік stdout. Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--logging-format string     Типово: text
Встановлює формат логу. Дозволені формати: "json" (контрольований LoggingBetaOptions, "text"). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--make-iptables-util-chains     Типово: true
Якщо значення істинне, kubelet забезпечить наявність правил утиліти iptables на хості. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--manifest-url string
URL для доступу до додаткових специфікацій Pod, які потрібно запустити. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--manifest-url-header strings
Список HTTP-заголовків, розділених комами, які слід використовувати при доступі до URL, наданого параметру --manifest-url. Кілька заголовків з однаковою назвою будуть додані в тому ж порядку, в якому вони надані. Цей параметр можна використовувати кілька разів. Наприклад: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--max-open-files int     Типово: 1000000
Кількість файлів, які може відкрити процес kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--max-pods int32     Типово: 110
Кількість Podʼів, які можуть працювати на цьому kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--maximum-dead-containers int32     Типово: -1
Максимальна кількість старих екземплярів контейнерів, які можна зберігати глобально. Кожен контейнер займає певний простір на диску. Щоб вимкнути, встановіть відʼємне число. (ЗАСТАРІЛО: Замість цього використовуйте --eviction-hard або --eviction-soft. Буде видалено в майбутніх версіях.)
--maximum-dead-containers-per-container int32     Типово: 1
Максимальна кількість старих екземплярів, які потрібно зберігати для кожного контейнера. Кожен контейнер займає певний обсяг дискового простору. (ЗАСТАРІЛО: Замість цього використовуйте --eviction-hard або --eviction-soft. Буде видалено в майбутніх версіях.)
--memory-manager-policy string     Типово: None
Політика Memory Manager для використання. Можливі значення: "None", "Static". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--minimum-container-ttl-duration duration
Мінімальний вік для завершеного контейнера перед тим, як його буде прибрано. Приклади: "300ms", "10s" або "2h45m". (ЗАСТАРІЛО: Замість цього використовуйте --eviction-hard або --eviction-soft. Буде видалено в майбутніх версіях.)
--minimum-image-ttl-duration duration     Типово: 2m0s
Мінімальний вік для невикористаного образу перед тим, як його буде прибрано. Приклади: "300ms", "10s" або "2h45m". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--node-ip string
IP-адреса (або список IP-адрес для двох стеків, розділених комами) вузла. Якщо не встановлено, kubelet використовуватиме стандартну IPv4-адресу вузла, якщо така є, або його стандартну IPv6-адресу, якщо IPv4-адрес немає. Ви можете передати "::", щоб віддати перевагу стандартній IPv6-адресі замість стандартної IPv4-адреси.
--node-labels <пари key=value>
<Попередження: Alpha функція>Мітки для додавання під час реєстрації вузла в кластері. Мітки повинні бути у форматі key=value, розділені ','. Мітки в просторі 'kubernetes.io' повинні починатися з дозволеного префікса ('kubelet.kubernetes.io', 'node.kubernetes.io') або бути в спеціально дозволеному наборі ('beta.kubernetes.io/arch', 'beta.kubernetes.io/instance-type', 'beta.kubernetes.io/os', 'failure-domain.beta.kubernetes.io/region', 'failure-domain.beta.kubernetes.io/zone', 'kubernetes.io/arch', 'kubernetes.io/hostname', 'kubernetes.io/os', 'node.kubernetes.io/instance-type', 'topology.kubernetes.io/region', 'topology.kubernetes.io/zone').
--node-status-max-images int32     Типово: 50
Максимальна кількість образів для показу в node.status.images. Якщо вказано -1, обмеження не буде застосовано. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--node-status-update-frequency duration     Типово: 10s
Визначає, як часто kubelet сповіщає про статус вузла у майстер. Примітка: будьте обережні при зміні константи, вона повинна узгоджуватися з nodeMonitorGracePeriod в контролері вузлів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--oom-score-adj int32     Типово: -999
Значення oom-score-adj для процесу kubelet. Значення повинні бути в межах від [-1000, 1000]. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pod-cidr string
CIDR для використання IP-адрес Pod, використовується тільки в автономному (standalone) режимі. У кластерному режимі це отримується від майстра. Для IPv6 максимальна кількість виділених IP-адрес складає 65536. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pod-infra-container-image string     Типово: registry.k8s.io/pause:3.9
Вказаний образ не буде видалений під час прибирання образів. Реалізації CRI мають власну конфігурацію для налаштування цього образу. (ЗАСТАРІЛО: буде видалено в 1.27. Прибирання образів буде отримувати інформацію про образи пісочниць з CRI.)
--pod-manifest-path string
Шлях до теки, що містить файли статичних Pod для запуску, або шлях до одного файлу статичного Pod. Файли, що починаються з крапки, будуть ігноруватися. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pod-max-pids int     Типово: -1
Встановлює максимальну кількість процесів на Pod. Якщо -1, kubelet стандартно використовує доступну на вузлі ємність PID. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pods-per-core int32
Кількість Podʼів на ядро, які можуть працювати на цьому kubelet. Загальна кількість Podʼів на цьому kubelet не може перевищувати --max-pods, тому буде використовуватися --max-pods, якщо цей розрахунок призведе до більшої кількості дозволених Podʼів на kubelet. Значення 0 вимикає це обмеження. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--port int32     Типово: 10250
Порт, на якому kubelet буде обслуговувати запити. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--protect-kernel-defaults
Стандартна поведінка kubelet для налаштування ядра. Якщо встановлено, kubelet видасть помилку, якщо будь-яке з налаштувань ядра відрізняється від стандартних значень kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--provider-id string
Унікальний ідентифікатор для ідентифікації вузла в базі даних машин, тобто у постачальника хмари.
--qos-reserved string
<Попередження: Alpha рівень> Набір пар <resource name>=<percentage> (наприклад, "memory=50%"), які описують, як запити ресурсів Pod резервуються на рівні QoS. На даний момент підтримується тільки memory. Потрібно активувати функціональну можливість QOSReserved. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--read-only-port int32     Типово: 10255
Порт тільки для читання, на якому буде працювати kubelet без автентифікації/авторизації (для вимкнення встановіть 0). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--register-node     Типово: true
Зареєструйте вузол на сервері API. Якщо --kubeconfig не вказано, цей параметр не має значення, оскільки kubelet не матиме API-сервера для реєстрації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--register-schedulable     Типово: true
Зареєструвати вузол як придатний для планування. Не матиме впливу, якщо --register-node має значення false. (ЗАСТАРІЛО: буде вилучено в майбутніх версіях)
--register-with-taints string
Реєструє вузол з наданим списком taints (розділених комами <key>=<value>:<effect>). Нічого не робить, якщо --register-node має значення false. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--registry-burst int32     Типово: 10
Максимальний розмір для сплеску завантажень, тимчасово дозволяє завантаженням досягати цієї кількості, не перевищуючи при цьому --registry-qps. Використовується тільки якщо --registry-qps більше 0. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--registry-qps int32     Типово: 5
Якщо > 0, обмежити QPS для завантажень з реєстру до цього значення. Якщо 0, без обмежень. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--reserved-cpus string
Список CPU або діапазонів CPU, розділених комами, зарезервованих для системи та використання Kubernetes. Цей конкретний список переважатиме над кількістю CPU в --system-reserved та --kube-reserved. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--reserved-memory string
Список резервувань памʼяті для NUMA вузлів, розділених комами. (наприклад, "--reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi"). Загальна сума для кожного типу памʼяті повинна дорівнювати сумі --kube-reserved, --system-reserved та --eviction-threshold. Дивіться тут для отримання додаткових відомостей. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--resolv-conf string     Типово: /etc/resolv.conf
Файл конфігурації резольвера, який використовується як основа для конфігурації DNS-резолюції контейнера. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--root-dir string     Типово: /var/lib/kubelet
Шлях до теки для управління файлами kubelet (монтування томів тощо).
--rotate-certificates
Виконувати автоматичну ротацію клієнтськіх сертифікатів kubelet, запитуючи нові сертифікати у kube-apiserver, коли термін дії сертифіката наближається до закінчення. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--rotate-server-certificates
Автоматично запитувати та виконувати ротацію сертифікатів kubelet, запитуючи нові сертифікати у kube-apiserver, коли термін дії сертифіката наближається до закінчення. Потрібно активувати функціональну можливість RotateKubeletServerCertificate та схвалення поданих обʼєктів CertificateSigningRequest. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--runonce
Якщо true, виходити після створення Podʼів з локальних маніфестів або віддалених URL. Взаємовиключно з --enable-server. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--runtime-cgroups string
Необовʼязкова абсолютна назва cgroups для створення та запуску середовища виконання.
--runtime-request-timeout duration     Типово: 2m0s
Тайм-аут для всіх запитів до середовища виконання, окрім довготривалих запитів — pull, logs, exec та attach. Коли тайм-аут перевищено, kubelet скасує запит, видасть помилку і спробує знову пізніше. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--seccomp-default
Вмикає використання RuntimeDefault як стандартного профілю seccomp для всіх навантажень.
--serialize-image-pulls     Типово: true
Витягує образи по одному. Рекомендується *не* змінювати стандартні значення на вузлах, які використовують демон Docker версії < 1.9 або сховище aufs. Деталі дивіться в тікеті #10959. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--streaming-connection-idle-timeout duration     Типово: 4h0m0s
Максимальний час, протягом якого зʼєднання для потокового режиму може бути неактивним перед автоматичним закриттям зʼєднання. 0 вказує на відсутність тайм-ауту. Приклад: 5m. Примітка: всі зʼєднання до сервера kubelet мають максимальну тривалість 4 години. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--sync-frequency duration     Типово: 1m0s
Максимальний проміжок часу між синхронізацією запущених контейнерів та конфігурацією. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--system-cgroups string
Необовʼязкова абсолютна назва cgroups, в якій слід розмістити всі процеси, що не є процесами ядра, що не знаходяться вже в cgroup під '/'. Пусто для відсутності контейнера. Для скасування прапорця потрібне перезавантаження. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--system-reserved string     Типово: <none>
Набір пар <resource name>=<resource quantity> (наприклад, "cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'"), які описують ресурси, зарезервовані для не-Kubernetes компонентів. Наразі підтримуються тільки cpu, memory та локальне тимчасове сховище для кореневої файлової системи. Дивіться тут для отримання додаткових відомостей. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--system-reserved-cgroup string     Типово: ''
Абсолютна назва cgroup найвищого рівня, яка використовується для управління не-Kubernetes компонентами, для яких ресурси були зарезервовані за допомогою прапорця --system-reserved. Наприклад, /system-reserved. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-cert-file string
Файл, що містить x509 сертифікат, використовується для обслуговування HTTPS (з проміжними сертифікатами, якщо такі є, конкатенованими після серверного сертифіката). Якщо --tls-cert-file та --tls-private-key-file не вказані, для публічної адреси генеруються самопідписані сертифікат і ключ, які зберігаються в теці, вказаній в --cert-dir. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-cipher-suites string
Список наборів шифрів для сервера, розділений комами. Якщо не вказано, будуть використані стандартні набори шифрів Go.
Рекомендовані значення: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384

Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.

(ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-min-version string
Minimum TLS version supported. Possible values: "VersionTLS10", "VersionTLS11", "VersionTLS12", "VersionTLS13". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-private-key-file string
Файл, що містить приватний ключ x509, що відповідає --tls-cert-file. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--topology-manager-policy string     Типово: 'none'
Політика Topology Manager для використання. Можливі значення: "none", "best-effort", "restricted", "single-numa-node". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--topology-manager-policy-options string
Набір параметрів політики Topology Manager у форматі <key>=<value>, які можна використовувати для тонкого налаштування їх поведінки. Якщо не вказані, зберігається стандартна поведінка. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--topology-manager-scope string     Типово: container
Область, до якої застосовуються топологічні підказки. Topology Manager збирає підказки від постачальників підказок і застосовує їх до визначеної області для забезпечення допуску Pod. Можливі значення: "container", "pod". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
-v, --v Level
Число для рівня детальності логу
--version version[=true]
Виводить інформацію про версію та виходить; --version=vX.Y.Z... задає відображену версію.
--vmodule <A list of 'pattern=N' strings>
Список налаштувань pattern=N, розділених комами, для фільтрованого логування файлів (працює тільки для текстового формату логу).
--volume-plugin-dir string     Типово: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/
Повний шлях до теки, в якій слід шукати додаткові втулки томів від сторонніх постачальників. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--volume-stats-agg-period duration     Типово: 1m0s
Вказує інтервал, через який kubelet обчислює та кешує використання диска томів для всіх Podʼів і томів. Щоб вимкнути обчислення томів, встановіть від’ємне число. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)

12.4 - kube-apiserver

Огляд

Сервер API Kubernetes перевіряє та налаштовує дані для обʼєктів api, які включають Podʼи, сервіси, replicationcontrollers та інші. API Server обслуговує REST-операції та забезпечує інтерфейс до спільного стану кластера, через який взаємодіють всі інші компоненти.

kube-apiserver [flags]

Параметри

--admission-control-config-file string

Файл з конфігурацією контролю допуску.

--advertise-address string

IP-адреса, на якій буде публікуватися інформація про apiserver для членів кластеру. Ця адреса має бути доступною для решти учасників кластера. Якщо не вказано, буде використано --bind-address. Якщо --bind-address не вказано, буде використано стандартний інтерфейс хоста.

--aggregator-reject-forwarding-redirect     Типово: true

Агрегатор відхиляє перенаправлення відповіді редиректу назад клієнту.

--allow-metric-labels stringToString     Типово: []

Зіставляє метрику-мітку зі списком дозволених значень цієї мітки. Формат ключа — <MetricName>,<LabelName>. Формат значення — < allowed_value>, <allowed_value>...наприклад, metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

--allow-metric-labels-manifest string

Шлях до файлу маніфесту, який містить зіставлення allow-list. Формат файлу такий самий, як і у прапорця --allow-metric-labels. Зауважте, що прапорець --allow-metric-labels замінить файл маніфесту.

--allow-privileged

Якщо true, дозволити привілейовані контейнери. [default=false]

--anonymous-auth     Типово: true

Дозволяє анонімні запити до захищеного порту сервера API. Запити, які не були відхилені іншими методами автентифікації, вважаються анонімними. Анонімні запити мають імʼя користувача system:anonymous і назву групи system:unauthenticated.

--api-audiences strings

Ідентифікатори API. Автентифікатор токенів службового облікового запису перевіряє, що токени, які використовуються з API, привʼязані принаймні до однієї з цих аудиторій. Якщо прапорець --service-account-issuer налаштовано, а цей прапорець не встановлено, стандартно у цьому полі буде вказано список з одного елемента, що містить URL-адресу емітента.

--audit-log-batch-buffer-size int     Типово: 10000

Розмір буфера для зберігання подій перед пакетною передачею та записом. Використовується тільки у пакетному режимі.

--audit-log-batch-max-size int     Типово: 1

Максимальний розмір пакету. Використовується тільки в пакетному режимі.

--audit-log-batch-max-wait duration

Час очікування перед примусовим записом пакету, який не досягнув максимального розміру. Використовується тільки в пакетному режимі.

--audit-log-batch-throttle-burst int

Максимальна кількість запитів, надісланих одночасно, якщо ThrottleQPS не використовувався раніше. Використовується тільки в пакетному режимі.

--audit-log-batch-throttle-enable

Чи ввімкнено пакетний тротлінг. Використовується тільки в пакетному режимі.

--audit-log-batch-throttle-qps float

Максимальна середня кількість партій в секунду. Використовується тільки в пакетному режимі.

--audit-log-compress

Якщо встановлено, файли логів, що ротуються, буде стиснуто за допомогою gzip.

--audit-log-format string     Типово: "json"

Формат збережених аудитів. "legacy" вказує на 1-рядковий текстовий формат для кожної події. "json" вказує на структурований формат json. Відомі формати: legacy, json.

--audit-log-maxage int

Максимальна кількість днів для зберігання старих файлів логів аудиту на основі мітки часу, закодованої в їхньому імені.

--audit-log-maxbackup int

Максимальна кількість старих файлів логів аудиту, які слід зберігати. Встановлення значення 0 означатиме відсутність обмежень на кількість файлів.

--audit-log-maxsize int

Максимальний розмір у мегабайтах файлу логу аудиту до того, як буде виконано його ротацію.

--audit-log-mode string     Типово: "blocking"

Стратегія надсилання подій аудиту. Блокування вказує на те, що надсилання подій має блокувати відповіді сервера. Пакетне виконання змушує бекенд буферизувати і записувати події асинхронно. Відомі такі режими: batch, blocking, blocking-strict.

--audit-log-path string

Якщо встановлено, всі запити, що надходять до apiserver, будуть записуватися до цього файлу. '-' означає стандартний вивід.

--audit-log-truncate-enabled

Чи увімкнено усікання подій та пакетів.

--audit-log-truncate-max-batch-size int     Типово: 10485760

Максимальний розмір пакету, що надсилається до відповідного бекенду. Фактичний розмір серіалізованого файлу може бути на кілька сотень байт більшим. Якщо пакет перевищує цей ліміт, він розбивається на кілька пакетів меншого розміру.

--audit-log-truncate-max-event-size int     Типово: 102400

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

--audit-log-version string     Типово: "audit.k8s.io/v1"

Група та версія API, що використовується для серіалізації подій аудиту, записаних до логу.

--audit-policy-file string

Шлях до файлу, який визначає конфігурацію політики аудиту.

--audit-webhook-batch-buffer-size int     Типово: 10000

Розмір буфера для зберігання подій перед пакетною передачею та записом. Використовується тільки у пакетному режимі.

--audit-webhook-batch-max-size int     Типово: 400

Максимальний розмір пакету. Використовується тільки у пакетному режимі.

--audit-webhook-batch-max-wait duration     Типово: 30s

Час очікування перед примусовим записом пакету, який не досягнув максимального розміру. Використовується тільки у пакетному режимі.

--audit-webhook-batch-throttle-burst int     Типово: 15

Максимальна кількість запитів, надісланих одночасно, якщо ThrottleQPS не використовувався раніше. Використовується тільки у пакетному режимі.

--audit-webhook-batch-throttle-enable     Типово: true

Чи ввімкнено пакетний тротлінг. Використовується тільки у пакетному режимі.

--audit-webhook-batch-throttle-qps float     Типово: 10

Максимальна середня кількість пакетів за секунду. Використовується тільки у пакетному режимі.

--audit-webhook-config-file string

Шлях до файлу у форматі kubeconfig, який визначає конфігурацію вебхука аудиту.

--audit-webhook-initial-backoff duration     Типово: 10s

Час очікування перед повторною спробою після першого невдалого запиту.

--audit-webhook-mode string     Типово: "batch"

Стратегія надсилання подій аудиту. Блокування вказує на те, що надсилання подій має блокувати відповіді сервера. Режим batch змушує бекенд буферизувати і записувати події асинхронно. Відомі такі режими: batch, blocking, blocking-strict.

--audit-webhook-truncate-enabled

Чи увімкнено усікання подій та пакетів.

--audit-webhook-truncate-max-batch-size int     Типово: 10485760

Максимальний розмір пакету, що надсилається до відповідного бекенду. Фактичний розмір серіалізованого файлу може бути на кілька сотень байт більшим. Якщо пакет перевищує цей ліміт, він розбивається на кілька пакетів меншого розміру.

--audit-webhook-truncate-max-event-size int     Типово: 102400

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

--audit-webhook-version string     Типово: "audit.k8s.io/v1"

Група та версія API, що використовується для серіалізації подій аудиту, записаних у webhook.

--authentication-config string

Файл з конфігурацією автентифікації для налаштування автентифікатора JWT Token або анонімного автентифікатора. Примітка: Ця функція доступна у версії Alpha, починаючи з v1.29.--feature-gate=StructuredAuthenticationConfiguration=true, щоб увімкнути цю функцію.Ця функція є взаємовиключною з прапорцями oidc-*. Для налаштування анонімного автентифікатора вам потрібно ввімкнути --feature-gate=AnonymousAuthConfigurableEndpoints. Коли ви налаштовуєте анонімний автентифікатор у конфігурації автентифікації, ви не можете використовувати прапорець --anonymous-auth.

--authentication-token-webhook-cache-ttl duration     Типово: 2m0s

Тривалість кешування відповідей від автентифікатора токенів вебхуків.

--authentication-token-webhook-config-file string

Файл з конфігурацією вебхука для автентифікації токенів у форматі kubeconfig. Сервер API буде запитувати віддалений сервіс для визначення автентичності токенів на предʼявника.

--authentication-token-webhook-version string     Типово: "v1beta1"

Версія API authentication.k8s.io TokenReview для надсилання та очікування від вебхука.

--authorization-config string

Файл з конфігурацією авторизації для налаштування ланцюжка авторизації.Примітка: Ця можливість зʼявилася у версії Alpha починаючи з v1.29.--feature-gate=StructuredAuthorizationConfiguration=true прапорець функції має бути встановлений у true для увімкнення функціональності.Ця можливість є взаємовиключною з іншими прапорцями --authorization-mode та --authorization-webhook-*.

--authorization-mode strings

Впорядкований список втулків для авторизації на захищеному порту. Стандартно має значення AlwaysAllow, якщо не вказано --authorization-config. Список втулків, розділених комами: AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.

--authorization-policy-file string

Файл з політикою авторизації у форматі json, що використовується з --authorization-mode=ABAC, на захищеному порту.

--authorization-webhook-cache-authorized-ttl duration     Типово: 5m0s

Тривалість кешування 'authorized' відповідей від авторизатора вебхука.

--authorization-webhook-cache-unauthorized-ttl duration     Типово: 30s

Тривалість кешування 'unauthorized' відповідей від авторизатора вебхука.

--authorization-webhook-config-file string

Файл з конфігурацією webhook у форматі kubeconfig, що використовується з --authorization-mode=Webhook. Сервер API запитує віддалений сервіс для визначення доступу на захищеному порту сервера API.

--authorization-webhook-version string     Типово: "v1beta1"

Версія API authorization.k8s.io SubjectAccessReview, яку потрібно надсилати до вебхука та очікувати від нього.

--bind-address string     Типово: 0.0.0.0

IP-адреса, на якій буде прослуховуватися порт --secure-port. Відповідний інтерфейс(и) має бути доступним для решти кластера, а також для CLI/веб-клієнтів. Якщо цей параметр не вказано або вказано невизначену адресу (0.0.0.0 або ::), будуть використані всі інтерфейси та сімейства IP-адрес.

--cert-dir string     Типово: "/var/run/kubernetes"

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--client-ca-file string

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

--contention-profiling

Дозволяє профілювання блоків, якщо профілювання увімкнено

--cors-allowed-origins strings

Список дозволених джерел для CORS, через кому. Допустимим джерелом може бути регулярний вираз для підтримки співставлення субдоменів. Якщо цей список порожній, CORS не буде ввімкнено. Будь ласка, переконайтеся, що кожен вираз співпадає з повним імʼям хоста шляхом привʼязки до початку за допомогою '^' або включення префікса '//', а також шляхом привʼязки до кінця за допомогою '$' або включення суфікса-розділювача портів ':'. Прикладами допустимих виразів є '//example.com(:|$)' і '^https://example.com(:|$)'

--debug-socket-path string

Використовуйте незахищений (без authn/authz) unix-доменний сокет для профілювання за вказаним шляхом

--default-not-ready-toleration-seconds int     Типово: 300

Вказує толерантність у секундах для notReady:NoExecute, яка стандартно додається до кожного Podʼа, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Показує tolerationSeconds толерантності для unreachable:NoExecute, яка стандартно додається до кожного Podʼа, який ще не має такої толерантності.

--delete-collection-workers int     Типово: 1

Кількість обробників, створених для виклику DeleteCollection. Вони використовуються для прискорення очищення простору імен.

--disable-admission-plugins strings

Втулки допуску, які слід вимкнути, хоча вони є у списку стандартно ввімкнутих втулків (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Список втулків допуску розділених комою: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. Порядок розташування втулків у цьому прапорці не має значення.

--disable-http2-serving

Якщо значення true, HTTP2-сервіс буде вимкнено [default=false].

--disabled-metrics strings

Цей прапорець забезпечує аварійний вихід для метрик, що поводяться не належним чином. Щоб вимкнути метрику, ви маєте вказати її повну назву. Застереження: вимкнення метрик має вищий пріоритет, ніж показ прихованих метрик.

--egress-selector-config-file string

Файл з конфігурацією селектора egress apiserver.

--emulated-version strings

У версіях різні компоненти емулюють свої можливості (API, функції, ...) інших компонентів.
Якщо встановлено, компонент буде емулювати поведінку цієї версії замість базової двійкової версії.
Формат версії може бути лише major.minor, наприклад: '--emulated-version=wardle=1.2,kube=1.31'. Можливі варіанти:
kube=1.31..1.31 (default=1.31) Якщо компонент не вказано, стандартно використовується "kube"

--enable-admission-plugins strings

Втулки допуску, які слід увімкнути на додачу до стандартно увімкнутих (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Розділений комами список втулків допуску: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. Порядок розташування втулків у цьому прапорці не має значення.

--enable-aggregator-routing

Вмикає маршрутизацію запитів агрегатора на IP точок доступу, а не на IP кластера.

--enable-bootstrap-token-auth

Увімкніть, щоб дозволити використовувати секрети типу 'bootstrap.kubernetes.io/token' у просторі імен 'kube-system' для автентифікації за допомогою TLS-завантаження.

--enable-garbage-collector     Типово: true

Вмикає загальний збирач сміття. МАЄ бути синхронізовано з відповідним прапорцем kube-controller-manager.

--enable-priority-and-fairness     Типово: true

Якщо true, замініть обробник max-in-flight на покращений обробник, який ставить в чергу та розподіляє відправлення з пріоритетом та справедливістю

--encryption-provider-config string

Файл, що містить конфігурацію для провайдерів шифрування, які будуть використовуватися для зберігання секретів у etcd

--encryption-provider-config-automatic-reload

Визначає, чи слід автоматично перезавантажувати файл, заданий за допомогою --encryption-provider-config, у разі зміни вмісту диска. Встановлення цього параметра у значення true вимикає можливість унікальної ідентифікації окремих втулків KMS за допомогою точок доступу API сервера healthz.

--endpoint-reconciler-type string     Типово: "lease"

Використовувати узгоджувач точок доступу (master-count, lease, none) master-count є застарілим і буде вилучений у наступній версії.

--etcd-cafile string

Файл центру сертифікації SSL, який використовується для захисту звʼязку etcd.

--etcd-certfile string

Файл SSL-сертифікату, який використовується для захисту звʼязку etcd.

--etcd-compaction-interval duration     Типово: 5m0s

Інтервал запитів на ущільнення. Якщо 0, то запит на ущільнення від apiserver вимкнено.

--etcd-count-metric-poll-period duration     Типово: 1m0s

Частота опитування etcd для кількості ресурсів за типом. 0 вимикає збір метрик.

--etcd-db-metric-poll-interval duration     Типово: 30s

Інтервал запитів на опитування etcd та оновлення метрики. 0 вимикає збір метрики

--etcd-healthcheck-timeout duration     Типово: 2s

Тайм-аут для перевірки стану etcd.

--etcd-keyfile string

Файл ключа SSL, який використовується для захисту комунікації etcd.

--etcd-prefix string     Типово: "/registry"

Префікс для додавання до всіх шляхів до ресурсів у etcd.

--etcd-readycheck-timeout duration     Типово: 2s

Тайм-аут для перевірки готовності etcd

--etcd-servers strings

Список etcd серверів для зʼєднання (scheme://ip: port), через кому.

--etcd-servers-overrides strings

Окремі перевизначення серверів etcd для кожного ресурсу, через кому. Формат перевизначення: група/ресурс#сервери, де сервери — це URL-адреси, розділені крапкою з комою. Зауважте, що це стосується лише ресурсів, скомпільованих у цей двійковий файл сервера.

--event-ttl duration     Типово: 1h0m0s

Кількість часу для збереження подій.

--external-hostname string

Імʼя хоста, яке використовуватиметься під час генерації зовнішніх URL-адрес для цього master (наприклад, Swagger API Docs або OpenID Discovery).

--feature-gates colonSeparatedMultimapStringString

Розділений комами список пар component:key=value, які описують функціональні можливості для альфа/експериментальних можливостей різних компонентів.
Якщо компонент не вказано, стандартно використовується "kube". Цей прапорець можна викликати багаторазово. Наприклад: --feature-gates 'wardle:featureA=true,wardle:featureB=false' --feature-gates 'kube:featureC=true'. Можливі варіанти:
kube:APIResponseCompression=true|false (BETA — default=true)
kube:APIServerIdentity=true|false (BETA — default=true)
kube:APIServerTracing=true|false (BETA — default=true)
kube:APIServingWithRoutine=true|false (ALPHA — default=false)
kube:AllAlpha=true|false (ALPHA — default=false)
kube:AllBeta=true|false (BETA — default=false)
kube:AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
kube:AnyVolumeDataSource=true|false (BETA — default=true)
kube:AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
kube:AuthorizeWithSelectors=true|false (ALPHA — default=false)
kube:CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:CPUManagerPolicyOptions=true|false (BETA — default=true)
kube:CRDValidationRatcheting=true|false (BETA — default=true)
kube:CSIMigrationPortworx=true|false (BETA — default=true)
kube:CSIVolumeHealth=true|false (ALPHA — default=false)
kube:CloudControllerManagerWebhook=true|false (ALPHA — default=false)
kube:ClusterTrustBundle=true|false (ALPHA — default=false)
kube:ClusterTrustBundleProjection=true|false (ALPHA — default=false)
kube:ComponentSLIs=true|false (BETA — default=true)
kube:ConcurrentWatchObjectDecode=true|false (BETA — default=false)
kube:ConsistentListFromCache=true|false (BETA — default=true)
kube:ContainerCheckpoint=true|false (BETA — default=true)
kube:ContextualLogging=true|false (BETA — default=true)
kube:CoordinatedLeaderElection=true|false (ALPHA — default=false)
kube:CronJobsScheduledAnnotation=true|false (BETA — default=true)
kube:CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
kube:CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
kube:CustomResourceFieldSelectors=true|false (BETA — default=true)
kube:DRAControlPlaneController=true|false (ALPHA — default=false)
kube:DisableAllocatorDualWrite=true|false (ALPHA — default=false)
kube:DisableNodeKubeProxyVersion=true|false (BETA — default=true)
kube:DynamicResourceAllocation=true|false (ALPHA — default=false)
kube:EventedPLEG=true|false (ALPHA — default=false)
kube:GracefulNodeShutdown=true|false (BETA — default=true)
kube:GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
kube:HPAScaleToZero=true|false (ALPHA — default=false)
kube:HonorPVReclaimPolicy=true|false (BETA — default=true)
kube:ImageMaximumGCAge=true|false (BETA — default=true)
kube:ImageVolume=true|false (ALPHA — default=false)
kube:InPlacePodVerticalScaling=true|false (ALPHA — default=false)
kube:InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
kube:InformerResourceVersion=true|false (ALPHA — default=false)
kube:JobBackoffLimitPerIndex=true|false (BETA — default=true)
kube:JobManagedBy=true|false (ALPHA — default=false)
kube:JobPodReplacementPolicy=true|false (BETA — default=true)
kube:JobSuccessPolicy=true|false (BETA — default=true)
kube:KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
kube:KubeletInUserNamespace=true|false (ALPHA — default=false)
kube:KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
kube:KubeletPodResourcesGet=true|false (ALPHA — default=false)
kube:KubeletSeparateDiskGC=true|false (BETA — default=true)
kube:KubeletTracing=true|false (BETA — default=true)
kube:LoadBalancerIPMode=true|false (BETA — default=true)
kube:LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
kube:LoggingAlphaOptions=true|false (ALPHA — default=false)
kube:LoggingBetaOptions=true|false (BETA — default=true)
kube:MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
kube:MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
kube:MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
kube:MemoryManager=true|false (BETA — default=true)
kube:MemoryQoS=true|false (ALPHA — default=false)
kube:MultiCIDRServiceAllocator=true|false (BETA — default=false)
kube:MutatingAdmissionPolicy=true|false (ALPHA — default=false)
kube:NFTablesProxyMode=true|false (BETA — default=true)
kube:NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
kube:NodeLogQuery=true|false (BETA — default=false)
kube:NodeSwap=true|false (BETA — default=true)
kube:OpenAPIEnums=true|false (BETA — default=true)
kube:PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
kube:PodDeletionCost=true|false (BETA — default=true)
kube:PodIndexLabel=true|false (BETA — default=true)
kube:PodLifecycleSleepAction=true|false (BETA — default=true)
kube:PodReadyToStartContainersCondition=true|false (BETA — default=true)
kube:PortForwardWebsockets=true|false (BETA — default=true)
kube:ProcMountType=true|false (BETA — default=false)
kube:QOSReserved=true|false (ALPHA — default=false)
kube:RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
kube:RecursiveReadOnlyMounts=true|false (BETA — default=true)
kube:RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
kube:ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
kube:ResilientWatchCacheInitialization=true|false (BETA — default=true)
kube:ResourceHealthStatus=true|false (ALPHA — default=false)
kube:RetryGenerateName=true|false (BETA — default=true)
kube:RotateKubeletServerCertificate=true|false (BETA — default=true)
kube:RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
kube:SELinuxMount=true|false (ALPHA — default=false)
kube:SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
kube:SchedulerQueueingHints=true|false (BETA — default=false)
kube:SeparateCacheWatchRPC=true|false (BETA — default=true)
kube:SeparateTaintEvictionController=true|false (BETA — default=true)
kube:ServiceAccountTokenJTI=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
kube:ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
kube:ServiceTrafficDistribution=true|false (BETA — default=true)
kube:SidecarContainers=true|false (BETA — default=true)
kube:SizeMemoryBackedVolumes=true|false (BETA — default=true)
kube:StatefulSetAutoDeletePVC=true|false (BETA — default=true)
kube:StorageNamespaceIndex=true|false (BETA — default=true)
kube:StorageVersionAPI=true|false (ALPHA — default=false)
kube:StorageVersionHash=true|false (BETA — default=true)
kube:StorageVersionMigrator=true|false (ALPHA — default=false)
kube:StrictCostEnforcementForVAP=true|false (BETA — default=false)
kube:StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
kube:StructuredAuthenticationConfiguration=true|false (BETA — default=true)
kube:StructuredAuthorizationConfiguration=true|false (BETA — default=true)
kube:SupplementalGroupsPolicy=true|false (ALPHA — default=false)
kube:TopologyAwareHints=true|false (BETA — default=true)
kube:TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:TopologyManagerPolicyOptions=true|false (BETA — default=true)
kube:TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
kube:UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
kube:UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
kube:UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
kube:UserNamespacesSupport=true|false (BETA — default=false)
kube:VolumeAttributesClass=true|false (BETA — default=false)
kube:VolumeCapacityPriority=true|false (ALPHA — default=false)
kube:WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
kube:WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
kube:WatchList=true|false (ALPHA — default=false)
kube:WatchListClient=true|false (BETA — default=false)
kube:WinDSR=true|false (ALPHA — default=false)
kube:WinOverlay=true|false (BETA — default=true)
kube:WindowsHostNetwork=true|false (ALPHA — default=true)

--goaway-chance float

Щоб запобігти застряганню HTTP/2-клієнтів на одному apiserver, випадково закрийте зʼєднання (GOAWAY). Інші запити клієнта не будуть зачеплені, і клієнт відновить зʼєднання, ймовірно, потрапивши на інший apiserver після того, як знову пройде через балансувальник навантаження. Цей аргумент задає частку запитів, які будуть відправлені GOAWAY. Кластери з одним apiserver або ті, що не використовують балансувальник навантаження, НЕ повинні вмикати цей параметр. Мінімальне значення — 0 (вимкнено), максимальне — 0.02 (1/50 запитів); 0.001 (1/1000) є рекомендованим початковим значенням.

-h, --help

Довідка kube-apiserver

--http2-max-streams-per-connection int

Обмеження, яке сервер надає клієнтам на максимальну кількість потоків у зʼєднанні HTTP/2. Нуль означає використання стандартного значення golang.

--kubelet-certificate-authority string

Шлях до файлу сертифіката центру сертифікації.

--kubelet-client-certificate string

Шлях до файлу клієнтського сертифіката для TLS.

--kubelet-client-key string

Шлях до файлу клієнтського ключа для TLS.

--kubelet-preferred-address-types strings     Типово: "Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP"

Список бажаних типів NodeAddressTypes для зʼєднань kubelet.

--kubelet-timeout duration     Типово: 5s

Таймаут для операцій kubelet.

--kubernetes-service-node-port int

Якщо значення відмінне від нуля, майстер-сервіс Kubernetes (який створює/підтримує apiserver) матиме тип NodePort, використовуючи його як значення порту. Якщо нульове значення, майстер-сервіс Kubernetes матиме тип ClusterIP.

--lease-reuse-duration-seconds int     Типово: 60

Час у секундах, протягом якого кожна оренда використовується повторно. Менше значення допоможе уникнути повторного використання однієї і тієї ж оренди великою кількістю обʼєктів. Зауважте, що занадто мале значення може спричинити проблеми з продуктивністю на рівні сховища.

--livez-grace-period duration

Цей параметр вказує максимальний час, за який apiserver має завершити свою послідовність запуску і стати активним. З моменту запуску apiserver і до закінчення цього часу /livez вважатиме, що незавершені після запуску хуки будуть успішно завершені, а отже, повертатиме значення true.

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--max-connection-bytes-per-sec int

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

--max-mutating-requests-inflight int     Типово: 200

Цей та --max-requests-inflight підсумовуються для визначення загального ліміту паралелізму сервера (який має бути додатнім), якщо --enable-priority-and-fairness має значення true. В іншому випадку цей прапорець обмежує максимальну кількість запитів, що змінюються у процесі виконання, або нульове значення повністю вимикає обмеження.

--max-requests-inflight int     Типово: 400

Це значення та --max-mutating-requests-inflight підсумовуються для визначення загального ліміту паралелізму сервера (який має бути додатнім), якщо --enable-priority-and-fairness має значення true. В іншому випадку цей прапорець обмежує максимальну кількість запитів, що не змінюються у процесі виконання, або нульове значення повністю вимикає ліміт.

--min-request-timeout int     Типово: 1800

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

--oidc-ca-file string

Якщо встановлено, сертифікат сервера OpenID буде перевірено одним з центрів сертифікації в oidc-ca-файлі, інакше буде використано кореневий центр сертифікації хоста.

--oidc-client-id string

Ідентифікатор клієнта для клієнта OpenID Connect повинен бути встановлений, якщо встановлено oidc-issuer-url.

--oidc-groups-claim string

Якщо вказано, імʼя власного запиту OpenID Connect для вказівки груп користувачів. Очікується, що значенням параметра буде рядок або масив рядків. Цей прапорець є експериментальним, будь ласка, зверніться до документації з автентифікації для отримання більш детальної інформації.

--oidc-groups-prefix string

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

--oidc-issuer-url string

URL-адреса емітента OpenID, приймається тільки схема HTTPS. Якщо встановлено, він буде використаний для перевірки OIDC JSON Web Token (JWT).

--oidc-required-claim <comma-separated 'key=value' pairs>

Пара key=value, яка описує необхідний реквізит в ідентифікаторі. Якщо встановлено, перевіряється, що реквізит присутній в ідентифікаторі з відповідним значенням. Повторіть цей прапорець, щоб вказати декілька реквізитів.

--oidc-signing-algs strings     Типово: "RS256"

Список дозволених алгоритмів асиметричного підпису JOSE через кому. JWT з підтримуваними значеннями заголовка 'alg': RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512. Значення визначені в RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1.

--oidc-username-claim string     Типово: "sub"

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

--oidc-username-prefix string

Якщо вказано, всі імена користувачів будуть доповнені цим значенням. Якщо не вказано, до імен користувачів, відмінних від "email", буде додано префікс URL-адреси емітента, щоб уникнути зіткнень. Щоб пропустити будь-яку префіксацію, вкажіть значення '-'.

--peer-advertise-ip string

Якщо встановлено і ввімкнено функцію UnknownVersionInteroperabilityProxy, цей IP буде використовуватися одноранговими kube-apiserverʼами для проксі-запитів до цього kube-apiserverʼа, коли запит не може бути оброблений одноранговим через невідповідність версій між kube-apiserʼами. Цей прапорець використовується лише у кластерах, сконфігурованих з декількома kube-apiserverʼами для забезпечення високої доступності.

--peer-advertise-port string

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

--peer-ca-file string

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

--permit-address-sharing

Якщо це значення дорівнює true, SO_REUSEADDR буде використано при привʼязці порту. Це дозволяє паралельно привʼязуватись до підстановочних IP-адрес, таких як 0.0.0.0, і до конкретних IP-адрес, а також дозволяє уникнути очікування ядром звільнення сокетів у стані TIME_WAIT. [default=false]

--permit-port-sharing

Якщо значення true, SO_REUSEPORT буде використано при привʼязці порту, що дозволяє більш ніж одному екземпляру привʼязуватися до однієї адреси та порту. [default=false]

--profiling     Типово: true

Увімкніть профілювання через веб-інтерфейс host:port/debug/pprof/

--proxy-client-cert-file string

Клієнтський сертифікат, що використовується для підтвердження особи агрегатора або kube-apiserver, коли необхідно здійснити виклик під час запиту. Це включає проксирування запитів до користувацького API-сервера та виклики до втулків допуску webhook. Очікується, що цей сертифікат містить підпис від CA, вказаного у прапорі --requestheader-client-ca-file. Цей CA публікується в configmap 'extension-apiserver-authentication' у просторі імен kube-system. Компоненти, що отримують виклики від kube-aggregator, повинні використовувати цей CA для виконання своєї частини взаємної TLS перевірки.

--proxy-client-key-file string

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

--request-timeout duration     Типово: 1m0s

Необовʼязкове поле, що вказує на тривалість, протягом якої обробник повинен тримати запит відкритим, перш ніж завершити його виконання. Це стандартний таймаут для запитів, але його можна перевизначити за допомогою прапорців, таких як --min-request-timeout для певних типів запитів.

--requestheader-allowed-names strings

Список загальних імен клієнтських сертифікатів, щоб дозволити вказувати імена користувачів у заголовках, визначених параметром --requestheader-username-headers. Якщо він порожній, можна використовувати будь-який сертифікат клієнта, підтверджений центрами сертифікації у файлі --requestheader-client-ca-file.

--requestheader-client-ca-file string

Пакет кореневих сертифікатів для перевірки клієнтських сертифікатів на вхідних запитах перед тим, як довіряти імена користувачів у заголовках, визначених параметром --requestheader-username-headers. ПОПЕРЕДЖЕННЯ: зазвичай не залежить від авторизації, яку вже виконано для вхідних запитів.

--requestheader-extra-headers-prefix strings

Список префіксів заголовків запитів для перевірки. Запропоновано X-Remote-Extra-.

--requestheader-group-headers strings

Список заголовків запитів для перевірки на наявність груп. Пропонується X-Remote-Group.

--requestheader-username-headers strings

Список заголовків запитів для перевірки на наявність імен користувачів. X-Remote-User є поширеним.

--runtime-config <comma-separated 'key=value' pairs>

Набір пар key=value, які вмикають або вимикають вбудовані API. Підтримувані параметри:
v1=true|false для основної групи API
<group>/<version>=true|false для певної групи API та версії (наприклад, apps/v1=true)
api/all=true|false контролює всі версії API
api/ga=true|false контролює всі версії API у формі v[0-9]+
api/beta=true| false контролює всі версії API форми v[0-9]+beta[0-9]+
api/alpha=true|false контролює всі версії API форми v[0-9]+alpha[0 -9]+
api/legacy застаріло та буде видалено в наступній версії

--secure-port int     Типово: 6443

Порт, на якому буде обслуговуватися HTTPS з автентифікацією та авторизацією. Його не можна вимкнути за допомогою 0.

--service-account-extend-token-expiration     Типово: true

Вмикає прогнозоване продовження терміну дії облікового запису під час генерації токенів, що допомагає безпечному переходу від застарілих токенів до привʼязаних токенів облікових записів. Якщо цей прапорець увімкнено, термін дії токенів, що вводяться, буде подовжено до 1 року, щоб запобігти несподіваним збоям під час переходу, ігноруючи значення параметра service-account-max-token-expiration.

--service-account-issuer strings

Ідентифікатор емітента токенів службового облікового запису. Емітент вказуватиме цей ідентифікатор у запиті "iss" на видачу випущених токенів. Це значення є рядком або URI. Якщо цей параметр не є дійсним URI згідно зі специфікацією OpenID Discovery 1.0, функція ServiceAccountIssuerDiscovery залишиться вимкненою, навіть якщо для функції gate буде встановлено значення true. Наполегливо рекомендується, щоб це значення відповідало специфікації OpenID: https://openid.net/specs/openid-connect-discovery-1_0.html. На практиці це означає, що service-account-issuer має бути URL-адресою https. Також наполегливо рекомендується, щоб ця URL-адреса могла обслуговувати документи виявлення OpenID за адресою {service-account-issuer}/.well-known/openid-configuration. Якщо цей прапорець вказано декілька разів, перший раз використовується для генерації токенів, а всі інші - для визначення прийнятних емітентів.

--service-account-jwks-uri string

Перевизначає URI для набору веб-ключів JSON у документі виявлення, що надсилається за адресою /.well-known/openid-configuration. Цей прапорець корисний, якщо документ виявлення та набір ключів надаються сторонам, що довіряють, за URL-адресою, відмінною від зовнішньої URL-адреси сервера API (автоматично визначеною або перевизначеною за допомогою external-hostname).

--service-account-key-file strings

File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key-file is provided

--service-account-lookup     Типово: true

Якщо true, підтвердити наявність токенів ServiceAccount в etcd як частину автентифікації.

--service-account-max-token-expiration duration

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

--service-account-signing-key-file string

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

--service-cluster-ip-range string

Діапазон IP-адрес у нотації CIDR, з якого призначаються сервісні кластерні IP-адреси. Він не повинен перетинатися з будь-якими діапазонами IP, призначеними вузлам або Podʼами. Максимальний допустимий діапазон — два двостекових CIDR.

--service-node-port-range <a string in the form 'N1-N2'>     Типово: 30000-32767

Діапазон портів для резервування для сервісів з видимістю NodePort. Він не повинен перетинатися з ефемерним діапазоном портів на вузлах. Приклад: '30000-32767'. Включно з обох кінців діапазону.

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату - переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, замість того, щоб дивуватися, коли вони будуть назавжди вилучені в наступному релізі.

--shutdown-delay-duration duration

Час затримки завершення роботи. Протягом цього часу сервер продовжує обслуговувати запити у звичайному режимі. Точки доступу /healthz і /livez повертатимуть успішне завершення, але /readyz одразу ж поверне помилку. Належне завершення роботи почнється після закінчення цієї затримки. Це може бути використано для того, щоб дозволити балансувальнику навантаження припинити надсилання трафіку на цей сервер.

--shutdown-send-retry-after

Якщо значення true, HTTP-сервер продовжуватиме прослуховування доти, доки всі недовготривалі запити у процесі виконання не будуть вичерпані, під час цього вікна всі вхідні запити будуть відхилені з кодом статусу 429 та заголовком відповіді "Retry-After", крім того, встановлюється заголовок відповіді "Connection: close" для того, щоб розірвати TCP-зʼєднання, коли воно не виконується.

--shutdown-watch-termination-grace-period duration

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

--storage-backend string

Бекенд сховища для збереження даних. Параметри: 'etcd3' (стандартно).

--storage-initialization-timeout duration     Типово: 1m0s

Максимальний час очікування ініціалізації сховища перед оголошенням готовності apiserver. Стандартно — 1m.

--storage-media-type string     Типово: "application/vnd.kubernetes.protobuf"

Тип носія для зберігання обʼєктів у сховищі. Деякі ресурси або бекенди сховища можуть підтримувати лише певний тип носія і ігноруватимуть цей параметр. Підтримувані медіа-типи: [application/json, application/yaml, application/vnd.kubernetes.protobuf].

--strict-transport-security-directives strings

Список директив для HSTS через кому. Якщо цей список порожній, то директиви HSTS не будуть додані. Приклад: 'max-age=31536000,includeSubDomains,preload'

--tls-cert-file string

Файл, що містить стандартний сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо HTTPS-сервіс увімкнено, а --tls-cert-file і --tls-private-key-file не вказано, для публічної адреси буде згенеровано самопідписаний сертифікат і ключ, які буде збережено в теці, вказаній в --cert-dir.

--tls-cipher-suites strings

Розділений комами список наборів шифрів для сервера. Якщо не вказано, буде використано стандартний набір шифрів Go.
Значення, яким надається перевага: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_RC4_128_SHA.

--tls-min-version string

Мінімальна підтримувана версія TLS. Можливі значення: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

--tls-private-key-file string

Файл, що містить стандартний приватний ключ x509, який відповідає --tls-cert-file.

--tls-sni-cert-key string

Пара шляхів до файлів сертифіката x509 і приватного ключа, до яких за бажанням додається список доменних шаблонів, які є повними доменними іменами, можливо, з префіксальними підстановчими сегментами. Доменні шаблони також дозволяють використовувати IP-адреси, але IP-адреси слід використовувати лише в тому випадку, якщо apiserver має доступ до IP-адреси, запитуваної клієнтом. Якщо шаблони домену не надано, витягуються імена сертифікатів. Збіги без підстановочних знаків мають перевагу над збігами з підстановочними знаками, а явні шаблони доменів мають перевагу над отриманими іменами. Для кількох пар ключ/сертифікат використовуйте --tls-sni-cert-key кілька разів. Приклади: "example.crt,example.key" або "foo.crt,foo.key:*.foo.com,foo.com".

--token-auth-file string

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

--tracing-config-file string

Файл з конфігурацією трасування apiserver.

-v, --v int

число рівня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

--watch-cache     Типово: true

Увімкніть кешування watch в apiserver

--watch-cache-sizes strings

Налаштування розміру кешу для деяких ресурсів (pods, nodes і т.д.), через кому. Формат індивідуальних налаштувань: resource[.group]#size, де resource — малі літери множини (без версії), group пропущено для ресурсів apiVersion v1 (застаріле ядро API) і включено для інших, а size — число. Цей параметр має значення лише для ресурсів, вбудованих у apiserver, а не для ресурсів, визначених CRD або зібраних із зовнішніх серверів, і використовується лише у випадку, якщо увімкнено watch-cache. Єдиним допустимим значенням розміру є нуль, що означає вимкнення кешування watch для відповідного ресурсу; усі ненульові значення є еквівалентними і означають, що кешування для цього ресурсу не вимкнено.

12.5 - kube-controller-manager

Огляд

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

kube-controller-manager [flags]

Параметри

https://kubernetes.io/docs/concepts/cluster-administration/node-shutdown/#storage-force-detach-on-timeout32     Типово: 5
--allocate-node-cidrs

Чи повинні CIDR для Podʼів бути виділені та налаштовані хмарним провайдером.

--allow-metric-labels stringToString     Типово: []

Зіставляє metric-label зі списком дозволених значень цієї мітки. Формат ключа — <MetricName>,<LabelName>. Формат значення — <дозволене_значення>,<дозволене_значення>...наприклад, metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

--allow-metric-labels-manifest string

Шлях до файлу маніфесту, який містить зіставлення allow-list. Формат файлу такий самий, як і у прапорця --allow-metric-labels. Зауважте, що прапорець --allow-metric-labels замінить файл маніфесту.

--attach-detach-reconcile-sync-period duration     Типово: 1m0s

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

--authentication-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення tokenreviews.authentication.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити токенів вважаються анонімними, і жоден клієнтський центр сертифікації не шукається в кластері.

--authentication-skip-lookup

Якщо значення false, authentication-kubeconfig буде використано для пошуку відсутньої конфігурації автентифікації в кластері.

--authentication-token-webhook-cache-ttl duration     Типово: 10s

Тривалість кешування відповідей від автентифікатора токенів webhook.

--authentication-tolerate-lookup-failure

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

--authorization-always-allow-paths strings     Типово: "/healthz,/readyz,/livez"

Список HTTP-шляхів, які пропускаються під час авторизації, тобто авторизуються без звʼязку з 'core' сервером kubernetes.

--authorization-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення subjectaccessreviews.authorization.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити, не пропущені авторизацією, будуть заборонені.

--authorization-webhook-cache-authorized-ttl duration     Типово: 10s

Тривалість кешування 'authorized' відповідей від авторизатора вебхука.

--authorization-webhook-cache-unauthorized-ttl duration     Типово: 10s

Тривалість кешування 'unauthorized' відповідей від авторизатора вебхука.

--bind-address string     Типово: 0.0.0.0

IP-адреса, на якій буде прослуховуватися порт --secure-port. Відповідний інтерфейс(и) має бути доступним для решти кластера, а також для CLI/веб-клієнтів. Якщо цей параметр не вказано або вказано невизначену адресу (0.0.0.0 або ::), будуть використані всі інтерфейси та сімейства IP-адрес.

--cert-dir string

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--cidr-allocator-type string     Типово: "RangeAllocator"

Тип розподілювача CIDR для використання

--client-ca-file string

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

--cloud-config string

Шлях до файлу конфігурації хмарного провайдера. Порожній рядок, якщо файл конфігурації відсутній.

--cloud-provider string

Провайдер хмарних сервісів. Порожній рядок для відсутності провайдера.

--cluster-cidr string

Діапазон CIDR для вузлів у кластері. Потрібно, щоб --allocate-node-cidrs мав значення true

--cluster-name string     Типово: "kubernetes"

Префікс екземпляру для кластера.

--cluster-signing-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску кластерних сертифікатів. Якщо вказано, можна не вказувати більш специфічний прапорець --cluster-signing-*.

--cluster-signing-duration duration     Типово: 8760h0m0s

Буде вказано максимальний термін дії підписаних сертифікатів. Окремі CSR можуть запитувати коротші сертифікати, встановивши spec.expirationSeconds.

--cluster-signing-key-file string

Імʼя файлу, що містить PEM-кодований закритий ключ RSA або ECDSA, який використовується для підпису кластерних сертифікатів. Якщо вказано, не можна вказувати більш специфічний прапорець --cluster-signing-*.

--cluster-signing-kube-apiserver-client-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску сертифікатів для підписувача kubernetes.io/kube-apiserver-client. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kube-apiserver-client-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для підписувача kubernetes.io/kube-apiserver-client. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-client-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску сертифікатів для підписувача kubernetes.io/kube-apiserver-client-kubelet. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-client-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для підписувача kubernetes.io/kube-apiserver-client-kubelet. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-serving-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску сертифікатів для підписувача kubernetes.io/kubelet-serving. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-serving-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для підписувача kubernetes.io/kubelet-serving. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-legacy-unknown-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для видачі сертифікатів для підписувача kubernetes.io/legacy-unknown. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-legacy-unknown-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для kubernetes.io/legacy-unknown signer. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--concurrent-cron-job-syncs int32     Типово: 5

Кількість обʼєктів завдання cron, яким дозволено синхронізуватися одночасно. Більша кількість = швидше реагують завдання, але більше навантаження на процесор (і мережу)

--concurrent-deployment-syncs int32     Типово: 5

Кількість обʼєктів deployment, яким дозволено синхронізуватися одночасно. Більша кількість = швидше розгортання, але більше навантаження на процесор (і мережу)

--concurrent-endpoint-syncs int32     Типово: 5

Кількість операцій синхронізації точок доступу, які будуть виконуватися одночасно. Більша кількість = швидше оновлення точок доступу, але більше навантаження на процесор (і мережу)

--concurrent-ephemeralvolume-syncs int32     Типово: 5

Кількість операцій синхронізації ефемерних томів, які будуть виконуватися одночасно. Більша кількість = швидше оновлення ефемерних томів, але більше навантаження на процесор (і мережу)

Кількість обʼєктів Job, яким дозволено синхронізуватися одночасно. Більша кількість = швидше реагують завдання, але більше навантаження на процесор (і мережу)

--concurrent-namespace-syncs int32     Типово: 10

Кількість обʼєктів namespace, яким дозволено синхронізуватися одночасно. Більша кількість = більш оперативне завершення роботи простору імен, але більше навантаження на процесор (і мережу)

--concurrent-rc-syncs int32     Типово: 5

Кількість контролерів реплікації, яким дозволено синхронізуватися одночасно. Більша кількість = більш оперативне керування реплікацією, але більше навантаження на процесор (і мережу)

--concurrent-replicaset-syncs int32     Типово: 5

Кількість replica set, які дозволено синхронізувати одночасно. Більша кількість = більш оперативне керування реплікацією, але більше навантаження на процесор (і мережу)

--concurrent-resource-quota-syncs int32     Типово: 5

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

--concurrent-service-endpoint-syncs int32     Типово: 5

Кількість операцій синхронізації точок доступу сервісів, які будуть виконуватися одночасно. Чим більше число, тим швидше оновлюватиметься зріз кінцевих точок, але більше завантажуватиметься процесор (і мережа). Стандартно дорівнює 5.

--concurrent-service-syncs int32     Типово: 1

Кількість сервісів, яким дозволено синхронізуватися одночасно. Більша кількість = більш оперативне управління послугами, але більше навантаження на процесор (і мережу)

--concurrent-serviceaccount-token-syncs int32     Типово: 5

Кількість обʼєктів токенів службових облікових записів, яким дозволено синхронізуватися одночасно. Більша кількість = швидша генерація токенів, але більше навантаження на процесор (і мережу)

--concurrent-statefulset-syncs int32     Типово: 5

Кількість обʼєктів statefulset, яким дозволено синхронізуватися одночасно. Більша кількість = більш швидкодіючі statefulsets, але більше навантаження на процесор (і мережу)

--concurrent-ttl-after-finished-syncs int32     Типово: 5

Кількість обробників ttl-after-finished-controller, яким дозволено синхронізуватися одночасно.

--concurrent-validating-admission-policy-status-syncs int32     Типово: 5

Кількість обробників ValidatingAdmissionPolicyStatusController, яким дозволено синхронізуватися одночасно.

--configure-cloud-routes     Типово: true

Чи повинні CIDR, виділені за допомогою allocate-node-cidrs, бути налаштовані на хмарному провайдері.

--contention-profiling

Активувати профілювання блоків, якщо профілювання увімкнено

--controller-start-interval duration

Інтервал між запуском менеджерів контролерів.

--controllers strings     Типово: "*"

Перелік контролерів для ввімкнення. '*' вмикає всі типово визначені контролери, 'foo' вмикає контролер з назвою 'foo', '-foo' вимикає контролер з назвою 'foo'.
Всі контролери: bootstrap-signer-controller, certificatesigningrequest-approving-controller, certificatesigningrequest-cleaner-controller, certificatesigningrequest-signing-controller, cloud-node-lifecycle-controller, clusterrole-aggregation-controller, cronjob-controller, daemonset-controller, deployment-controller, disruption-controller, endpoints-controller, endpointslice-controller, endpointslice-mirroring-controller, ephemeral-volume-controller, garbage-collector-controller, horizontal-pod-autoscaler-controller, job-controller, legacy-serviceaccount-token-cleaner-controller, namespace-controller, node-ipam-controller, node-lifecycle-controller, node-route-controller, persistentvolume-attach-detach-controller, persistentvolume-binder-controller, persistentvolume-expander-controller, persistentvolume-protection-controller, persistentvolumeclaim-protection-controller, pod-garbage-collector-controller, replicaset-controller, replicationcontroller-controller, resourceclaim-controller, resourcequota-controller, root-ca-certificate-publisher-controller, service-cidr-controller, service-lb-controller, serviceaccount-controller, serviceaccount-token-controller, statefulset-controller, storage-version-migrator-controller, storageversion-garbage-collector-controller, taint-eviction-controller, token-cleaner-controller, ttl-after-finished-controller, ttl-controller, validatingadmissionpolicy-status-controller
Стандартно вимкнені контролери: bootstrap-signer-controller, token-cleaner-controller

--disable-attach-detach-reconcile-sync

Вимкнути синхронізацію узгоджувача приєднання томів. Вимкнення цієї опції може призвести до невідповідності томів і Podʼів. Використовуйте з обережністю.

--disable-force-detach-on-timeout

Заборонити примусове відʼєднання томів на основі максимального часу відʼєднання та стану вузла. Якщо цей прапорець встановлено у true, необхідно використовувати функцію примусового вимкнення вузла для відновлення після збою вузла. Докладні відомості див. на сторінці https://kubernetes.io/docs/concepts/cluster-administration/node-shutdown/#storage-force-detach-on-timeout

--disable-http2-serving

Якщо значення true, HTTP2-сервіс буде вимкнено [default=false].

--disabled-metrics strings

Цей прапорець забезпечує аварійний вихід для метрик, що поводяться не належним чином. Щоб вимкнути метрику, ви маєте вказати її повну назву. Застереження: вимкнення метрик має вищий пріоритет, ніж показ прихованих метрик.

--emulated-version strings

У версіях різні компоненти емулюють свої можливості (API, функції, ...) інших компонентів.
Якщо встановлено, компонент буде емулювати поведінку цієї версії замість базової двійкової версії.
Формат версії може бути лише major.minor, наприклад: '--emulated-version=wardle=1.2,kube=1.31'. Можливі варіанти:
kube=1.31..1.31 (default=1.31) Якщо компонент не вказано, стандартно використовується "kube"

--enable-dynamic-provisioning     Типово: true

Увімкніть динамічне створення ресурсів для середовищ, які його підтримують.

--enable-garbage-collector     Типово: true

Вмикає загальний збирач сміття. ПОВИНЕН бути синхронізований з відповідним прапорцем kube-apiserver.

--enable-hostpath-provisioner

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

--enable-leader-migration

Чи вмикати міграцію лідера контролера.

--endpoint-updates-batch-period duration

Тривалість періоду пакетного оновлення точок доступу. Обробка змін у пакунках буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями і зменшити загальну кількість оновлень точок доступу. Більша кількість = більша затримка програмування точок доступу, але менша кількість згенерованих ревізій точок доступу

--endpointslice-updates-batch-period duration

Тривалість періоду пакетного оновлення зрізу точок доступу. Обробка змін у пакунках буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями і зменшити загальну кількість оновлень точок доступу. Більша кількість = більша затримка програмування точок доступу, але менша кількість згенерованих ревізій точок доступу

--external-cloud-volume-plugin string

Втулок для використання, коли хмарний провайдер встановлений як зовнішній. Може бути порожнім, слід встановлювати лише тоді, коли хмарний провайдер є зовнішнім. Наразі використовується для дозволу роботи node-ipam-controller, persistentvolume-binder-controller, persistentvolume-expander-controller та attach-detach-controller у вбудованих хмарних провайдерів.

--feature-gates colonSeparatedMultimapStringString

Розділений комами список пар component:key=value, які описують функціональні можливості для альфа/експериментальних можливостей різних компонентів.
Якщо компонент не вказано, стандартно використовується "kube". Цей прапорець можна викликати багаторазово. Наприклад: --feature-gates 'wardle:featureA=true,wardle:featureB=false' --feature-gates 'kube:featureC=true'. Можливі варіанти:
kube:APIResponseCompression=true|false (BETA — default=true)
kube:APIServerIdentity=true|false (BETA — default=true)
kube:APIServerTracing=true|false (BETA — default=true)
kube:APIServingWithRoutine=true|false (ALPHA — default=false)
kube:AllAlpha=true|false (ALPHA — default=false)
kube:AllBeta=true|false (BETA — default=false)
kube:AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
kube:AnyVolumeDataSource=true|false (BETA — default=true)
kube:AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
kube:AuthorizeWithSelectors=true|false (ALPHA — default=false)
kube:CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:CPUManagerPolicyOptions=true|false (BETA — default=true)
kube:CRDValidationRatcheting=true|false (BETA — default=true)
kube:CSIMigrationPortworx=true|false (BETA — default=true)
kube:CSIVolumeHealth=true|false (ALPHA — default=false)
kube:CloudControllerManagerWebhook=true|false (ALPHA — default=false)
kube:ClusterTrustBundle=true|false (ALPHA — default=false)
kube:ClusterTrustBundleProjection=true|false (ALPHA — default=false)
kube:ComponentSLIs=true|false (BETA — default=true)
kube:ConcurrentWatchObjectDecode=true|false (BETA — default=false)
kube:ConsistentListFromCache=true|false (BETA — default=true)
kube:ContainerCheckpoint=true|false (BETA — default=true)
kube:ContextualLogging=true|false (BETA — default=true)
kube:CoordinatedLeaderElection=true|false (ALPHA — default=false)
kube:CronJobsScheduledAnnotation=true|false (BETA — default=true)
kube:CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
kube:CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
kube:CustomResourceFieldSelectors=true|false (BETA — default=true)
kube:DRAControlPlaneController=true|false (ALPHA — default=false)
kube:DisableAllocatorDualWrite=true|false (ALPHA — default=false)
kube:DisableNodeKubeProxyVersion=true|false (BETA — default=true)
kube:DynamicResourceAllocation=true|false (ALPHA — default=false)
kube:EventedPLEG=true|false (ALPHA — default=false)
kube:GracefulNodeShutdown=true|false (BETA — default=true)
kube:GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
kube:HPAScaleToZero=true|false (ALPHA — default=false)
kube:HonorPVReclaimPolicy=true|false (BETA — default=true)
kube:ImageMaximumGCAge=true|false (BETA — default=true)
kube:ImageVolume=true|false (ALPHA — default=false)
kube:InPlacePodVerticalScaling=true|false (ALPHA — default=false)
kube:InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
kube:InformerResourceVersion=true|false (ALPHA — default=false)
kube:JobBackoffLimitPerIndex=true|false (BETA — default=true)
kube:JobManagedBy=true|false (ALPHA — default=false)
kube:JobPodReplacementPolicy=true|false (BETA — default=true)
kube:JobSuccessPolicy=true|false (BETA — default=true)
kube:KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
kube:KubeletInUserNamespace=true|false (ALPHA — default=false)
kube:KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
kube:KubeletPodResourcesGet=true|false (ALPHA — default=false)
kube:KubeletSeparateDiskGC=true|false (BETA — default=true)
kube:KubeletTracing=true|false (BETA — default=true)
kube:LoadBalancerIPMode=true|false (BETA — default=true)
kube:LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
kube:LoggingAlphaOptions=true|false (ALPHA — default=false)
kube:LoggingBetaOptions=true|false (BETA — default=true)
kube:MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
kube:MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
kube:MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
kube:MemoryManager=true|false (BETA — default=true)
kube:MemoryQoS=true|false (ALPHA — default=false)
kube:MultiCIDRServiceAllocator=true|false (BETA — default=false)
kube:MutatingAdmissionPolicy=true|false (ALPHA — default=false)
kube:NFTablesProxyMode=true|false (BETA — default=true)
kube:NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
kube:NodeLogQuery=true|false (BETA — default=false)
kube:NodeSwap=true|false (BETA — default=true)
kube:OpenAPIEnums=true|false (BETA — default=true)
kube:PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
kube:PodDeletionCost=true|false (BETA — default=true)
kube:PodIndexLabel=true|false (BETA — default=true)
kube:PodLifecycleSleepAction=true|false (BETA — default=true)
kube:PodReadyToStartContainersCondition=true|false (BETA — default=true)
kube:PortForwardWebsockets=true|false (BETA — default=true)
kube:ProcMountType=true|false (BETA — default=false)
kube:QOSReserved=true|false (ALPHA — default=false)
kube:RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
kube:RecursiveReadOnlyMounts=true|false (BETA — default=true)
kube:RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
kube:ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
kube:ResilientWatchCacheInitialization=true|false (BETA — default=true)
kube:ResourceHealthStatus=true|false (ALPHA — default=false)
kube:RetryGenerateName=true|false (BETA — default=true)
kube:RotateKubeletServerCertificate=true|false (BETA — default=true)
kube:RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
kube:SELinuxMount=true|false (ALPHA — default=false)
kube:SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
kube:SchedulerQueueingHints=true|false (BETA — default=false)
kube:SeparateCacheWatchRPC=true|false (BETA — default=true)
kube:SeparateTaintEvictionController=true|false (BETA — default=true)
kube:ServiceAccountTokenJTI=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
kube:ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
kube:ServiceTrafficDistribution=true|false (BETA — default=true)
kube:SidecarContainers=true|false (BETA — default=true)
kube:SizeMemoryBackedVolumes=true|false (BETA — default=true)
kube:StatefulSetAutoDeletePVC=true|false (BETA — default=true)
kube:StorageNamespaceIndex=true|false (BETA — default=true)
kube:StorageVersionAPI=true|false (ALPHA — default=false)
kube:StorageVersionHash=true|false (BETA — default=true)
kube:StorageVersionMigrator=true|false (ALPHA — default=false)
kube:StrictCostEnforcementForVAP=true|false (BETA — default=false)
kube:StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
kube:StructuredAuthenticationConfiguration=true|false (BETA — default=true)
kube:StructuredAuthorizationConfiguration=true|false (BETA — default=true)
kube:SupplementalGroupsPolicy=true|false (ALPHA — default=false)
kube:TopologyAwareHints=true|false (BETA — default=true)
kube:TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:TopologyManagerPolicyOptions=true|false (BETA — default=true)
kube:TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
kube:UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
kube:UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
kube:UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
kube:UserNamespacesSupport=true|false (BETA — default=false)
kube:VolumeAttributesClass=true|false (BETA — default=false)
kube:VolumeCapacityPriority=true|false (ALPHA — default=false)
kube:WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
kube:WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
kube:WatchList=true|false (ALPHA — default=false)
kube:WatchListClient=true|false (BETA — default=false)
kube:WinDSR=true|false (ALPHA — default=false)
kube:WinOverlay=true|false (BETA — default=true)
kube:WindowsHostNetwork=true|false (ALPHA — default=true)

--flex-volume-plugin-dir string     Типово: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"

Повний шлях до теки, у якій втулок flex volume має шукати додаткові втулки сторонніх розробників.

-h, --help

Довідка kube-controller-manager

--horizontal-pod-autoscaler-cpu-initialization-period duration     Типово: 5m0s

Період після запуску Зod, коли проби CPU можуть бути пропущені.

--horizontal-pod-autoscaler-downscale-stabilization duration     Типово: 5m0s

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

--horizontal-pod-autoscaler-initial-readiness-delay duration     Типово: 30s

Період після запуску Pod, протягом якого готовність змінюється, буде вважатися початковою готовністю.

--horizontal-pod-autoscaler-sync-period duration     Типово: 15s

Період для синхронізації кількості Podʼів у horizontal pod autoscaler.

--horizontal-pod-autoscaler-tolerance float     Типово: 0.1

Мінімальна зміна (від 1.0) у співвідношенні бажаної та фактичної метрики для того, щоб horizontal pod autoscaler розглянув можливість масштабування.

--http2-max-streams-per-connection int

Обмеження, яке сервер надає клієнтам на максимальну кількість потоків у зʼєднанні HTTP/2. Нуль означає використання стандартних значень golang.

--kube-api-burst int32     Типово: 30

Сплеск для використання під час спілкування з apiserver на kubernetes.

--kube-api-content-type string     Типово: "application/vnd.kubernetes.protobuf"

Тип вмісту запитів, що надсилаються до apiserver.

--kube-api-qps float     Типово: 20

QPS для використання під час спілкування з kubernetes apiserver.

--kubeconfig string

Шлях до файлу kubeconfig з інформацією про авторизацію та розташування майстра (розташування майстра може бути перевизначено прапорцем master).

--large-cluster-size-threshold int32     Типово: 50

Кількість вузлів, з яких node-lifecycle-controller вважає кластер великим для цілей логіки виселення. --secondary-node-eviction-rate неявно перевизначено у 0 для кластерів такого розміру або менших. Зауваження: Якщо вузли знаходяться у декількох зонах, цей поріг буде розглядатися як поріг розміру вузла зони для кожної зони, щоб визначити швидкість виселення вузла незалежно.

--leader-elect     Типово: true

Запускає клієнта виборів лідера і отримує лідерство перед виконанням основного циклу. Увімкніть цю опцію під час запуску реплікованих компонентів для забезпечення високої доступності.

--leader-elect-lease-duration duration     Типово: 15s

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

--leader-elect-renew-deadline duration     Типово: 10s

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

--leader-elect-resource-lock string     Типово: "leases"

Тип обʼєкта ресурсу, який використовується для блокування під час виборів лідера. Підтримуються такі варіанти 'leases', 'endpointsleases' and 'configmapsleases'.

--leader-elect-resource-name string     Типово: "kube-controller-manager"

Імʼя обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-resource-namespace string     Типово: "kube-system"

Простір імен обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-retry-period duration     Типово: 2s

Час, протягом якого клієнти повинні чекати між спробою отримання та поновленням лідерства. Це стосується лише тих випадків, коли увімкнено обрання лідера.

--leader-migration-config string

Шлях до конфігураційного файлу для міграції лідера контролерів або порожній, щоб використовувати значення, яке є стандартною конфігурацією диспетчера контролерів. Конфігураційний файл має бути типу LeaderMigrationConfiguration, група controllermanager.config.k8s.io, версія v1alpha1.

--legacy-service-account-token-clean-up-period duration     Типово: 8760h0m0s

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

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--master string

Адреса сервера API Kubernetes (перевизначає будь-яке значення в kubeconfig).

--max-endpoints-per-slice int32     Типово: 100

Максимальна кількість точок доступу, яку буде додано до зрізу EndpointSlice. Чим більше точок на зріз, тим менше зрізів точок, але більші ресурси. Стандартне значення — 100.

--min-resync-period duration     Типово: 12h0m0s

Період ресинхронізації у рефлекторах буде випадковим між MinResyncPeriod та 2*MinResyncPeriod.

--mirroring-concurrent-service-endpoint-syncs int32     Типово: 5

Кількість операцій синхронізації точок доступу сервісів, які будуть виконуватися одночасно контролером endpointslice-mirroring-controller. Більша кількість = швидше оновлення зрізу точок доступу, але більше навантаження на процесор (і мережу). Стандартне значення — 5.

--mirroring-endpointslice-updates-batch-period duration

Тривалість періоду пакетного оновлення EndpointSlice для контролера endpointslice-mirroring-controller. Обробка змін EndpointSlice буде затримана на цей період, щоб обʼєднати їх з потенційними майбутніми оновленнями і зменшити загальну кількість оновлень EndpointSlice. Більша кількість = більша затримка програмування точок доступу, але менша кількість згенерованих ревізій точок доступу

--mirroring-max-endpoints-per-subset int32     Типово: 1000

Максимальна кількість точок доступу, яку буде додано до зрізу EndpointSlice контролером endpointslice-mirroring-controller. Чим більше точок на зріз, тим менше зрізів точок, але більші ресурси. Стандартно дорівнює 100.

--namespace-sync-period duration     Типово: 5m0s

Період синхронізації оновлень життєвого циклу простору імен

--node-cidr-mask-size int32

Розмір маски для вузла cidr у кластері. Стандартне значення 24 для IPv4 та 64 для IPv6.

--node-cidr-mask-size-ipv4 int32

Розмір маски для IPv4 вузла cidr у двостековому кластері. Стандартне значення — 24.

--node-cidr-mask-size-ipv6 int32

Розмір маски для IPv6 вузла cidr у двостековому кластері. Стандартне значення — 64.

--node-eviction-rate float     Типово: 0.1

Кількість вузлів на секунду, на яких видаляються підтипи у випадку відмови вузла, коли зона є справною (див. --unhealthy-zone-threshold для визначення справності/несправності зони). Під зоною мається на увазі весь кластер у небагатозонних кластерах.

--node-monitor-grace-period duration     Типово: 40s

Кількість часу, протягом якого ми дозволяємо вузлу не відповідати на запити, перш ніж позначити його як несправний. Має бути у N разів більшою за nodeStatusUpdateFrequency kubelet, де N означає кількість спроб, дозволених kubelet для публікації статусу вузла.

--node-monitor-period duration     Типово: 5s

Період синхронізації NodeStatus у контролері cloud-node-lifecycle-controller.

--node-startup-grace-period duration     Типово: 1m0s

Час, протягом якого ми дозволяємо стартовому вузлу не відповідати, перш ніж позначити його як несправний.

--permit-address-sharing

Якщо це значення дорівнює true, SO_REUSEADDR буде використано при привʼязці порту. Це дозволяє паралельно привʼязуватись до підстановочних IP-адрес, таких як 0.0.0.0, і до конкретних IP-адрес, а також дозволяє уникнути очікування ядром звільнення сокетів у стані TIME_WAIT. [default=false]

--permit-port-sharing

Якщо значення true, SO_REUSEPORT буде використано при привʼязці порту, що дозволяє більш ніж одному екземпляру привʼязуватися до тієї самої адреси та порту. [default=false]

--profiling     Типово: true

Вмикання профілювання через веб-інтерфейс host:port/debug/pprof/

--pv-recycler-increment-timeout-nfs int32     Типово: 30

Інкремент часу, що додається для кожного Gi до ActiveDeadlineSeconds для поду NFS scrubber

--pv-recycler-minimum-timeout-hostpath int32     Типово: 60

Мінімальне значення ActiveDeadlineSeconds, яке потрібно використовувати для HostPath Recycler pod. Це лише для розробки та тестування і не працюватиме у багатовузловому кластері.

--pv-recycler-minimum-timeout-nfs int32     Типово: 300

TМінімальне значення ActiveDeadlineSeconds, яке потрібно використовувати для pod NFS Recycler

--pv-recycler-pod-template-filepath-hostpath string

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

--pv-recycler-pod-template-filepath-nfs string

Шлях до файлу з визначенням pod, який використовується як шаблон для рециркуляції постійних томів NFS

--pv-recycler-timeout-increment-hostpath int32     Типово: 30

інкремент часу, що додається до ActiveDeadlineSeconds на кожен Gi, для HostPath Pod scrubber. Це призначено лише для розробки та тестування і не працюватиме у багатовузловому кластері.

--pvclaimbinder-sync-period duration     Типово: 15s

Період синхронізації постійних томів і заявок на постійні томи

--requestheader-allowed-names strings

Список загальних імен клієнтських сертифікатів, щоб дозволити вказувати імена користувачів у заголовках, визначених параметром --requestheader-username-headers. Якщо він порожній, можна використовувати будь-який сертифікат клієнта, підтверджений центрами сертифікації у файлі --requestheader-client-ca-file.

--requestheader-client-ca-file string

Пакет кореневих сертифікатів для перевірки клієнтських сертифікатів на вхідних запитах перед тим, як довіряти іменам користувачів у заголовках, визначених параметром --requestheader-username-headers. ПОПЕРЕДЖЕННЯ: зазвичай не залежить від авторизації, яку вже виконано для вхідних запитів.

--requestheader-extra-headers-prefix strings     Типово: "x-remote-extra-"

Список префіксів заголовків запитів для перевірки. Пропонується X-Remote-Extra-.

--requestheader-group-headers strings     Типово: "x-remote-group"

Список заголовків запитів для перевірки на наявність груп. Пропонується X-Remote-Group.

--requestheader-username-headers strings     Типово: "x-remote-user"

Список заголовків запитів для перевірки на наявність імен користувачів. X-Remote-User є поширеним.

--resource-quota-sync-period duration     Типово: 5m0s

Період синхронізації статусу використання квоти в системі

--root-ca-file string

Якщо встановлено, цей кореневий центр сертифікації буде включено до токену секрету службового облікового запису. Це має бути дійсний пакет центрів сертифікації з PEM-кодуванням.

--route-reconciliation-period duration     Типово: 10s

Період узгодження маршрутів, створених для Node хмарним провайдером.

--secondary-node-eviction-rate float     Типово: 0.01

Кількість вузлів на секунду, на яких видаляються pods у разі відмови вузла, коли зона є несправною (див. --unhealthy-zone-threshold для визначення healthy/unhealthy зони). Під зоною мається на увазі весь кластер у небагатозонних кластерах. Це значення неявно перевизначається на 0, якщо розмір кластера менший за --large-cluster-size-threshold.

--secure-port int     Типово: 10257

Порт, на якому обслуговувати HTTPS з автентифікацією та авторизацією. Якщо 0, не обслуговувати HTTPS взагалі.

--service-account-private-key-file string

Файл, що містить приватний ключ RSA або ECDSA, закодований PEM, який використовується для підпису токенів службових облікових записів.

--service-cluster-ip-range string

Діапазон CIDR для Services у кластері. Потрібно, щоб --allocate-node-cidrs мав значення true

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату — переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, замість того, щоб дивуватися, коли вони будуть назавжди вилучені в наступному релізі.

--terminated-pod-gc-threshold int32     Типово: 12500

Кількість podʼів, що завершили роботу, які можуть існувати до того, як збирач завершених podʼів почне їх видалення. Якщо <= 0, то збирач завершених podʼів вимкнено.

--tls-cert-file string

Файл, що містить стандартний сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо HTTPS-сервіс увімкнено, а --tls-cert-file і --tls-private-key-file не вказано, для публічної адреси буде згенеровано самопідписаний сертифікат і ключ, які буде збережено в теці, вказаній в --cert-dir.

--tls-cipher-suites strings

Розділений комами список наборів шифрів для сервера. Якщо не вказано, буде використано стандартний набір шифрів Go.
Значення, яким надається перевага: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_RC4_128_SHA.

--tls-min-version string

Мінімальна підтримувана версія TLS. Можливі значення: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

--tls-private-key-file string

Файл, що містить стандартний приватний ключ x509, який відповідає --tls-cert-file.

--tls-sni-cert-key string

Пара шляхів до файлів сертифіката x509 і приватного ключа, до яких за бажанням додається список шаблонів доменів, які є повними доменними іменами, можливо, з префіксальними підстановчими сегментами. Доменні шаблони також дозволяють використовувати IP-адреси, але IP-адреси слід використовувати лише в тому випадку, якщо apiserver має доступ до IP-адреси, запитуваної клієнтом. Якщо шаблони домену не надано, витягуються імена сертифікатів. Збіги без підстановочних знаків мають перевагу над збігами з підстановочними знаками, а явні шаблони доменів мають перевагу над отриманими іменами. Для кількох пар ключ/сертифікат використовуйте --tls-sni-cert-key кілька разів. Приклади: "example.crt,example.key" або "foo.crt,foo.key:*.foo.com,foo.com".

--unhealthy-zone-threshold float     Типово: 0.55

Частка вузлів у зоні, яка не повинна бути Ready (мінімум 3) для того, щоб зона вважалася несправною.

--use-service-account-credentials

Якщо true, використовуйте окремі облікові дані для кожного контролера.

-v, --v int

число для визначення ступеня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

12.6 - kube-proxy

Огляд

Мережевий проксі-сервер Kubernetes працює на кожному вузлі. Це відображає сервіси, визначені у Kubernetes API, на кожному вузлі і може виконувати просте перенаправлення потоків TCP, UDP і SCTP або циклічне перенаправлення TCP, UDP і SCTP через набір бекендів. Наразі IP-адреси та порти кластерів обслуговування можна знайти за допомогою сумісних з Docker-посиланнями змінні оточення, що визначають порти, відкриті проксі-сервісом. Існує надбудова яка надає кластерний DNS для цих кластерних IP-адрес. Користувач повинен створити сервіс за допомогою API apiserver, щоб налаштувати проксі.

kube-proxy [flags]

Параметри

--add_dir_header

Якщо true, додає теку файлу до заголовка повідомлень логу

--alsologtostderr

виводити лог до stderr, а також у файли (не має ефекту, якщо -logtostderr=true)

--bind-address string     Типово: 0.0.0.0

Перевизначає уявлення kube-proxy про первинну IP-адресу вузла. Зауважте, що назва є історичним артефактом, і kube-proxy насправді не привʼязує жодних сокетів до цього IP. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--bind-address-hard-fail

Якщо true, kube-proxy розцінить невдалу спробу звʼязатися з портом як фатальну і завершить роботу

--cleanup

Якщо true, очистіть iptables та правила ipvs і вийдіть.

--cluster-cidr string

Діапазон CIDR для Podʼів у кластері. (Для двостекових кластерів це може бути пара діапазонів CIDR, розділених комами). Коли --detect-local-mode має значення ClusterCIDR, kube-proxy вважатиме трафік локальним, якщо IP-адреса його джерела знаходиться в цьому діапазоні. (В іншому випадку він не використовується.) Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--config string

Шлях до файлу конфігурації.

--config-sync-period duration     Типово: 15m0s

Як часто оновлюється конфігурація з apiserver. Повинно бути більше 0.

--conntrack-max-per-core int32     Типово: 32768

Максимальна кількість NAT-зʼєднань для відстеження на одне ядро процесора (0 — залишити ліміт як є і ігнорувати conntrack-min).

--conntrack-min int32     Типово: 131072

Мінімальна кількість записів conntrack для розподілу, незалежно від conntrack-max-per-core (встановіть conntrack-max-per-core=0, щоб залишити обмеження без змін).

--conntrack-tcp-be-liberal

Увімкніть ліберальний режим відстеження TCP-пакетів, встановивши nf_conntrack_tcp_be_liberal у 1

--conntrack-tcp-timeout-close-wait duration     Типово: 1h0m0s

Таймаут NAT для TCP-зʼєднань у стані CLOSE_WAIT

--conntrack-tcp-timeout-established duration     Типово: 24h0m0s

Тайм-аут простою для встановлених TCP-зʼєднань (0 — залишити як є)

--conntrack-udp-timeout duration

Тайм-аут очікування для UDP-зʼєднань без відповіді (0 — залишити як є)

--conntrack-udp-timeout-stream duration

Тайм-аут простою для ASSURED UDP-зʼєднань (0 — залишити як є)

--detect-local-mode LocalMode

Режим для виявлення локального трафіку. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--feature-gates <comma-separated 'key=True|False' pairs>

Набір пар key=value, які описують функціональні можливостідля альфа/експериментальних функцій. Можливі варіанти:
APIResponseCompression=true|false (BETA — default=true)
APIServerIdentity=true|false (BETA — default=true)
APIServerTracing=true|false (BETA — default=true)
APIServingWithRoutine=true|false (ALPHA — default=false)
AllAlpha=true|false (ALPHA — default=false)
AllBeta=true|false (BETA — default=false)
AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
AnyVolumeDataSource=true|false (BETA — default=true)
AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
AuthorizeWithSelectors=true|false (ALPHA — default=false)
CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
CPUManagerPolicyOptions=true|false (BETA — default=true)
CRDValidationRatcheting=true|false (BETA — default=true)
CSIMigrationPortworx=true|false (BETA — default=true)
CSIVolumeHealth=true|false (ALPHA — default=false)
CloudControllerManagerWebhook=true|false (ALPHA — default=false)
ClusterTrustBundle=true|false (ALPHA — default=false)
ClusterTrustBundleProjection=true|false (ALPHA — default=false)
ComponentSLIs=true|false (BETA — default=true)
ConcurrentWatchObjectDecode=true|false (BETA — default=false)
ConsistentListFromCache=true|false (BETA — default=true)
ContainerCheckpoint=true|false (BETA — default=true)
ContextualLogging=true|false (BETA — default=true)
CoordinatedLeaderElection=true|false (ALPHA — default=false)
CronJobsScheduledAnnotation=true|false (BETA — default=true)
CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
CustomResourceFieldSelectors=true|false (BETA — default=true)
DRAControlPlaneController=true|false (ALPHA — default=false)
DisableAllocatorDualWrite=true|false (ALPHA — default=false)
DisableNodeKubeProxyVersion=true|false (BETA — default=true)
DynamicResourceAllocation=true|false (ALPHA — default=false)
EventedPLEG=true|false (ALPHA — default=false)
GracefulNodeShutdown=true|false (BETA — default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
HPAScaleToZero=true|false (ALPHA — default=false)
HonorPVReclaimPolicy=true|false (BETA — default=true)
ImageMaximumGCAge=true|false (BETA — default=true)
ImageVolume=true|false (ALPHA — default=false)
InPlacePodVerticalScaling=true|false (ALPHA — default=false)
InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
InformerResourceVersion=true|false (ALPHA — default=false)
JobBackoffLimitPerIndex=true|false (BETA — default=true)
JobManagedBy=true|false (ALPHA — default=false)
JobPodReplacementPolicy=true|false (BETA — default=true)
JobSuccessPolicy=true|false (BETA — default=true)
KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
KubeletInUserNamespace=true|false (ALPHA — default=false)
KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
KubeletPodResourcesGet=true|false (ALPHA — default=false)
KubeletSeparateDiskGC=true|false (BETA — default=true)
KubeletTracing=true|false (BETA — default=true)
LoadBalancerIPMode=true|false (BETA — default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
LoggingAlphaOptions=true|false (ALPHA — default=false)
LoggingBetaOptions=true|false (BETA — default=true)
MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
MemoryManager=true|false (BETA — default=true)
MemoryQoS=true|false (ALPHA — default=false)
MultiCIDRServiceAllocator=true|false (BETA — default=false)
MutatingAdmissionPolicy=true|false (ALPHA — default=false)
NFTablesProxyMode=true|false (BETA — default=true)
NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
NodeLogQuery=true|false (BETA — default=false)
NodeSwap=true|false (BETA — default=true)
OpenAPIEnums=true|false (BETA — default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
PodDeletionCost=true|false (BETA — default=true)
PodIndexLabel=true|false (BETA — default=true)
PodLifecycleSleepAction=true|false (BETA — default=true)
PodReadyToStartContainersCondition=true|false (BETA — default=true)
PortForwardWebsockets=true|false (BETA — default=true)
ProcMountType=true|false (BETA — default=false)
QOSReserved=true|false (ALPHA — default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
RecursiveReadOnlyMounts=true|false (BETA — default=true)
RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
ResilientWatchCacheInitialization=true|false (BETA — default=true)
ResourceHealthStatus=true|false (ALPHA — default=false)
RetryGenerateName=true|false (BETA — default=true)
RotateKubeletServerCertificate=true|false (BETA — default=true)
RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
SELinuxMount=true|false (ALPHA — default=false)
SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
SchedulerQueueingHints=true|false (BETA — default=false)
SeparateCacheWatchRPC=true|false (BETA — default=true)
SeparateTaintEvictionController=true|false (BETA — default=true)
ServiceAccountTokenJTI=true|false (BETA — default=true)
ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
ServiceTrafficDistribution=true|false (BETA — default=true)
SidecarContainers=true|false (BETA — default=true)
SizeMemoryBackedVolumes=true|false (BETA — default=true)
StatefulSetAutoDeletePVC=true|false (BETA — default=true)
StorageNamespaceIndex=true|false (BETA — default=true)
StorageVersionAPI=true|false (ALPHA — default=false)
StorageVersionHash=true|false (BETA — default=true)
StorageVersionMigrator=true|false (ALPHA — default=false)
StrictCostEnforcementForVAP=true|false (BETA — default=false)
StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
StructuredAuthenticationConfiguration=true|false (BETA — default=true)
StructuredAuthorizationConfiguration=true|false (BETA — default=true)
SupplementalGroupsPolicy=true|false (ALPHA — default=false)
TopologyAwareHints=true|false (BETA — default=true)
TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
TopologyManagerPolicyOptions=true|false (BETA — default=true)
TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
UserNamespacesSupport=true|false (BETA — default=false)
VolumeAttributesClass=true|false (BETA — default=false)
VolumeCapacityPriority=true|false (ALPHA — default=false)
WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
WatchList=true|false (ALPHA — default=false)
WatchListClient=true|false (BETA — default=false)
WinDSR=true|false (ALPHA — default=false)
WinOverlay=true|false (BETA — default=true)
WindowsHostNetwork=true|false (ALPHA — default=true)
Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--healthz-bind-address ipport     Типово: 0.0.0.0:10256

IP-адреса та порт для сервера перевірки справності, стандартно "0.0.0.0:10256". Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

-h, --help

Довідка kube-proxy

--hostname-override string

Якщо не порожнє, буде використано як імʼя вузла, на якому запущено kube-proxy. Якщо не задано, імʼя вузла вважається таким самим, як і імʼя хоста вузла.

--init-only

Якщо true, виконайте всі кроки ініціалізації, які необхідно виконати з повними привілеями root, а потім вийдіть. Після цього ви можете запустити kube-proxy знову, але тільки з параметром CAP_NET_ADMIN.

--iptables-localhost-nodeports     Типово: true

Якщо значення false, kube-proxy вимкне застарілу поведінку, яка дозволяла доступ до сервісів NodePort через localhost. (Стосується лише режиму iptables та IPv4; NodePort через localhost ніколи не буде дозволено в інших режимах проксі або з IPv6).

--iptables-masquerade-bit int32     Типово: 14

Якщо використовується режим проксі iptables або ipvs, біт простору fwmark, яким слід позначати пакети, що вимагають SNAT. Повинен знаходитися в діапазоні [0, 31].

--iptables-min-sync-period duration     Типово: 1s

Мінімальний період між пересинхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайного пересинхронізації iptables.

--iptables-sync-period duration     Типово: 30s

Інтервал (наприклад, '5s', '1m', '2h22m'), який вказує, як часто виконуються різні операції ресинхронізації та очищення. Має бути більше 0.

--ipvs-exclude-cidrs strings

Список CIDR, розділених комами, які ipvs-проксі-сервер не повинен торкатися під час очищення правил IPVS.

--ipvs-min-sync-period duration     Типово: 1s

Мінімальний період між ресинхронізаціями правил IPVS (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної пересинхронізації IPVS.

--ipvs-scheduler string

Тип планувальника ipvs, якщо режим проксі — ipvs

--ipvs-strict-arp

Увімкніть строгий ARP, встановивши arp_ignore на 1 і arp_announce на 2

--ipvs-sync-period duration     Типово: 30s

Інтервал (наприклад, '5s', '1m', '2h22m'), який вказує, як часто виконуються різні операції ресинхронізації та очищення. Має бути більше 0.

--ipvs-tcp-timeout duration

Тайм-аут для неактивних TCP-зʼєднань IPVS, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m').

--ipvs-tcpfin-timeout duration

Тайм-аут для IPVS TCP-зʼєднань після отримання FIN-пакету, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m').

--ipvs-udp-timeout duration

Таймаут для IPVS UDP-пакетів, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m').

--kube-api-burst int32     Типово: 10

Сплеск для використання під час спілкування з apiserver на kubernetes.

--kube-api-content-type string     Типово: "application/vnd.kubernetes.protobuf"

Тип вмісту запитів, що надсилаються до apiserver.

--kube-api-qps float     Типово: 5

Використання QPS під час спілкування з apiserver на kubernetes

--kubeconfig string

Шлях до файлу kubeconfig з інформацією про авторизацію (розташування master може бути перевизначено прапорцем master).

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log_backtrace_at <рядок у вигляді 'file:N'>     Типово: :0

при попаданні в лог-файл рядка file:N, вивести трасування стеку

--log_dir string

Якщо тека не порожня, записати лог-файли у цю теку (не діє, якщо -logtostderr=true).

--log_file string

Якщо файл не порожній, використовуйте цей файл логу (не діє, якщо -logtostderr=true)

--log_file_max_size uint     Типово: 1800

Визначає максимальний розмір, до якого може зрости файл логу (не впливає, якщо -logtostderr=true). Одиниця виміру — мегабайти. Якщо значення дорівнює 0, максимальний розмір файлу необмежений.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--logtostderr     Типово: true

писати лог в standard error, а не у файл

--masquerade-all

SNAT для всього трафіку, що надсилається через IP-кластера сервісу. Це може бути необхідним для деяких втулків CNI. Підтримується лише в Linux.

--master string

Адреса сервера API Kubernetes (перевизначає будь-яке значення в kubeconfig).

--metrics-bind-address ipport     Типово: 127.0.0.1:10249

IP-адреса та порт для сервера метрик, типове значення: "127.0.0.1:10249". (Встановіть значення "0.0.0.0:10249" / "[::]:10249" для привʼязки на всіх інтерфейсах). Встановіть пусте значення, щоб вимкнути. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--nodeport-addresses strings

Список діапазонів CIDR, які містять допустимі IP-адреси вузлів, або, як варіант, єдиний рядок 'primary'. Якщо встановлено перелік CIDRs, зʼєднання з сервісами NodePort будуть прийматися лише з IP-адрес вузла в одному із зазначених діапазонів. Якщо встановлено значення 'primary', сервіси NodePort будуть прийматися лише на основну IP-адресу вузла згідно з обʼєктом Node. Якщо не встановлено, зʼєднання до NodePort будуть прийматися на всіх локальних IP-адресах. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--one_output

Якщо значення true, записувати логи лише до їхнього власного рівня важливості (замість запису до кожного нижчого рівня важливості; немає ефекту, якщо -logtostderr=true).

--oom-score-adj int32     Типово: -999

Значення oom-score-adj для процесу kube-proxy. Значення має бути в діапазоні [-1000, 1000]. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--pod-bridge-interface string

Імʼя інтерфейсу bridge. Коли --detect-local-mode має значення BridgeInterface, kube-proxy вважатиме трафік локальним, якщо він походить з цього мосту.

--pod-interface-name-prefix string

Префікс імені інтерфейсу. Коли --detect-local-mode має значення InterfaceNamePrefix, kube-proxy вважатиме трафік локальним, якщо він походить з будь-якого інтерфейсу, назва якого починається з цього префікса.

--profiling

Якщо значення true, вмикає профілювання через веб-інтерфейс у обробнику /debug/pprof. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--proxy-mode ProxyMode

Режим проксі-сервера: у Linux це може бути 'iptables' (стандартно) або 'ipvs'. У Windows єдиним підтримуваним значенням є 'kernelspace'. Цей параметр ігнорується, якщо у конфігураційному файлі вказано --config.

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату — переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, а не дивуватися, коли вони назавжди вилучаються в наступному релізі. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--skip_headers

Якщо true, уникати префіксів заголовків у повідомленнях логу

--skip_log_headers

Якщо значення true, уникати заголовків при відкритті файлів логу (не впливає, якщо -logtostderr=true)

--stderrthreshold int     Типово: 2

логи на рівні або вище цього порогу потрапляють до stderr під час запису до файлів та stderr (не впливає, якщо -logtostderr=true або -alsologtostderr=true)

-v, --v int

число рівня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

--write-config-to string

Якщо встановлено, записати значення стандартної конфігурації до цього файлу і вийти.

12.7 - kube-scheduler

Огляд

Планувальник Kubernetes — це процес панелі управління, який призначає Podʼи до вузлів. Планувальник визначає, які вузли є допустимими для розміщення для кожного Pod у черзі планування відповідно до обмежень та доступних ресурсів. Потім планувальник ранжує кожен допустимий вузол і привʼязує Pod до відповідного вузла. У кластері може використовуватися декілька різних планувальників; kube-scheduler є еталонною реалізацією. Див. статтю планування для отримання додаткової інформації про планування та компонент kube-scheduler.

kube-scheduler [flags]

Параметри

--allow-metric-labels stringToString     Типово: []

Зіставляє метрику-мітку зі списком дозволених значень цієї мітки. Формат ключа — <MetricName>,<LabelName>. Формат значення — < allowed_value>, <allowed_value>...наприклад, metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

--allow-metric-labels-manifest string

Шлях до файлу маніфесту, який містить зіставлення allow-list. Формат файлу такий самий, як і у прапорця --allow-metric-labels. Зауважте, що прапорець --allow-metric-labels замінить файл маніфесту.

--authentication-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення tokenreviews.authentication.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити токенів вважаються анонімними, і жоден клієнтський центр сертифікації не шукається в кластері.

--authentication-skip-lookup

Якщо значення false, authentication-kubeconfig буде використано для пошуку відсутньої конфігурації автентифікації в кластері.

--authentication-token-webhook-cache-ttl duration     Типово: 10s

Тривалість кешування відповідей від автентифікатора токенів вебхуків.

--authentication-tolerate-lookup-failure     Типово: true

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

--authorization-always-allow-paths strings     Типово: "/healthz,/readyz,/livez"

Список HTTP-шляхів, які пропускаються під час авторизації, тобто авторизуються без звʼязку з 'core' сервером kubernetes.

--authorization-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення subjectaccessreviews.authorization.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити, не пропущені авторизацією, будуть заборонені.

--authorization-webhook-cache-authorized-ttl duration     Типово: 10s

Тривалість кешування 'authorized' відповідей від авторизатора вебхука.

--authorization-webhook-cache-unauthorized-ttl duration     Типово: 10s

Тривалість кешування 'unauthorized' відповідей від авторизатора вебхука.

--bind-address string     Типово: 0.0.0.0

IP-адреса, на якій буде прослуховуватися порт --secure-port. Відповідний інтерфейс(и) має бути доступним для решти кластера, а також для CLI/веб-клієнтів. Якщо цей параметр не вказано або вказано невизначену адресу (0.0.0.0 або ::), будуть використані всі інтерфейси та сімейства IP-адрес.

--cert-dir string

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--client-ca-file string

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

--config string

Шлях до файлу конфігурації.

--contention-profiling     Типово: true

DEPRECATED: увімкнути профілювання блоків, якщо профілювання увімкнено. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--disable-http2-serving

Якщо значення true, HTTP2-сервіс буде вимкнено [default=false].

--disabled-metrics strings

Цей прапорець забезпечує аварійний вихід для метрик, що поводяться не належним чином. Щоб вимкнути метрику, ви маєте вказати її повну назву. Застереження: вимкнення метрик має вищий пріоритет, ніж показ прихованих метрик.

--emulated-version strings

У версіях різні компоненти емулюють свої можливості (API, функції, ...) інших компонентів.
Якщо встановлено, компонент буде емулювати поведінку цієї версії замість базової двійкової версії.
Формат версії може бути лише major.minor, наприклад: '--emulated-version=wardle=1.2,kube=1.31'. Можливі варіанти:
kube=1.31..1.31 (default=1.31) Якщо компонент не вказано, стандартно використовується "kube"

--feature-gates colonSeparatedMultimapStringString

Розділений комами список пар component:key=value, які описують функціональні можливості для альфа/експериментальних можливостей різних компонентів.
Якщо компонент не вказано, стандартно використовується "kube". Цей прапорець можна викликати багаторазово. Наприклад: --feature-gates 'wardle:featureA=true,wardle:featureB=false' --feature-gates 'kube:featureC=true'. Можливі варіанти:
kube:APIResponseCompression=true|false (BETA — default=true)
kube:APIServerIdentity=true|false (BETA — default=true)
kube:APIServerTracing=true|false (BETA — default=true)
kube:APIServingWithRoutine=true|false (ALPHA — default=false)
kube:AllAlpha=true|false (ALPHA — default=false)
kube:AllBeta=true|false (BETA — default=false)
kube:AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
kube:AnyVolumeDataSource=true|false (BETA — default=true)
kube:AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
kube:AuthorizeWithSelectors=true|false (ALPHA — default=false)
kube:CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:CPUManagerPolicyOptions=true|false (BETA — default=true)
kube:CRDValidationRatcheting=true|false (BETA — default=true)
kube:CSIMigrationPortworx=true|false (BETA — default=true)
kube:CSIVolumeHealth=true|false (ALPHA — default=false)
kube:CloudControllerManagerWebhook=true|false (ALPHA — default=false)
kube:ClusterTrustBundle=true|false (ALPHA — default=false)
kube:ClusterTrustBundleProjection=true|false (ALPHA — default=false)
kube:ComponentSLIs=true|false (BETA — default=true)
kube:ConcurrentWatchObjectDecode=true|false (BETA — default=false)
kube:ConsistentListFromCache=true|false (BETA — default=true)
kube:ContainerCheckpoint=true|false (BETA — default=true)
kube:ContextualLogging=true|false (BETA — default=true)
kube:CoordinatedLeaderElection=true|false (ALPHA — default=false)
kube:CronJobsScheduledAnnotation=true|false (BETA — default=true)
kube:CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
kube:CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
kube:CustomResourceFieldSelectors=true|false (BETA — default=true)
kube:DRAControlPlaneController=true|false (ALPHA — default=false)
kube:DisableAllocatorDualWrite=true|false (ALPHA — default=false)
kube:DisableNodeKubeProxyVersion=true|false (BETA — default=true)
kube:DynamicResourceAllocation=true|false (ALPHA — default=false)
kube:EventedPLEG=true|false (ALPHA — default=false)
kube:GracefulNodeShutdown=true|false (BETA — default=true)
kube:GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
kube:HPAScaleToZero=true|false (ALPHA — default=false)
kube:HonorPVReclaimPolicy=true|false (BETA — default=true)
kube:ImageMaximumGCAge=true|false (BETA — default=true)
kube:ImageVolume=true|false (ALPHA — default=false)
kube:InPlacePodVerticalScaling=true|false (ALPHA — default=false)
kube:InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
kube:InformerResourceVersion=true|false (ALPHA — default=false)
kube:JobBackoffLimitPerIndex=true|false (BETA — default=true)
kube:JobManagedBy=true|false (ALPHA — default=false)
kube:JobPodReplacementPolicy=true|false (BETA — default=true)
kube:JobSuccessPolicy=true|false (BETA — default=true)
kube:KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
kube:KubeletInUserNamespace=true|false (ALPHA — default=false)
kube:KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
kube:KubeletPodResourcesGet=true|false (ALPHA — default=false)
kube:KubeletSeparateDiskGC=true|false (BETA — default=true)
kube:KubeletTracing=true|false (BETA — default=true)
kube:LoadBalancerIPMode=true|false (BETA — default=true)
kube:LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
kube:LoggingAlphaOptions=true|false (ALPHA — default=false)
kube:LoggingBetaOptions=true|false (BETA — default=true)
kube:MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
kube:MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
kube:MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
kube:MemoryManager=true|false (BETA — default=true)
kube:MemoryQoS=true|false (ALPHA — default=false)
kube:MultiCIDRServiceAllocator=true|false (BETA — default=false)
kube:MutatingAdmissionPolicy=true|false (ALPHA — default=false)
kube:NFTablesProxyMode=true|false (BETA — default=true)
kube:NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
kube:NodeLogQuery=true|false (BETA — default=false)
kube:NodeSwap=true|false (BETA — default=true)
kube:OpenAPIEnums=true|false (BETA — default=true)
kube:PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
kube:PodDeletionCost=true|false (BETA — default=true)
kube:PodIndexLabel=true|false (BETA — default=true)
kube:PodLifecycleSleepAction=true|false (BETA — default=true)
kube:PodReadyToStartContainersCondition=true|false (BETA — default=true)
kube:PortForwardWebsockets=true|false (BETA — default=true)
kube:ProcMountType=true|false (BETA — default=false)
kube:QOSReserved=true|false (ALPHA — default=false)
kube:RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
kube:RecursiveReadOnlyMounts=true|false (BETA — default=true)
kube:RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
kube:ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
kube:ResilientWatchCacheInitialization=true|false (BETA — default=true)
kube:ResourceHealthStatus=true|false (ALPHA — default=false)
kube:RetryGenerateName=true|false (BETA — default=true)
kube:RotateKubeletServerCertificate=true|false (BETA — default=true)
kube:RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
kube:SELinuxMount=true|false (ALPHA — default=false)
kube:SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
kube:SchedulerQueueingHints=true|false (BETA — default=false)
kube:SeparateCacheWatchRPC=true|false (BETA — default=true)
kube:SeparateTaintEvictionController=true|false (BETA — default=true)
kube:ServiceAccountTokenJTI=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
kube:ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
kube:ServiceTrafficDistribution=true|false (BETA — default=true)
kube:SidecarContainers=true|false (BETA — default=true)
kube:SizeMemoryBackedVolumes=true|false (BETA — default=true)
kube:StatefulSetAutoDeletePVC=true|false (BETA — default=true)
kube:StorageNamespaceIndex=true|false (BETA — default=true)
kube:StorageVersionAPI=true|false (ALPHA — default=false)
kube:StorageVersionHash=true|false (BETA — default=true)
kube:StorageVersionMigrator=true|false (ALPHA — default=false)
kube:StrictCostEnforcementForVAP=true|false (BETA — default=false)
kube:StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
kube:StructuredAuthenticationConfiguration=true|false (BETA — default=true)
kube:StructuredAuthorizationConfiguration=true|false (BETA — default=true)
kube:SupplementalGroupsPolicy=true|false (ALPHA — default=false)
kube:TopologyAwareHints=true|false (BETA — default=true)
kube:TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:TopologyManagerPolicyOptions=true|false (BETA — default=true)
kube:TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
kube:UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
kube:UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
kube:UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
kube:UserNamespacesSupport=true|false (BETA — default=false)
kube:VolumeAttributesClass=true|false (BETA — default=false)
kube:VolumeCapacityPriority=true|false (ALPHA — default=false)
kube:WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
kube:WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
kube:WatchList=true|false (ALPHA — default=false)
kube:WatchListClient=true|false (BETA — default=false)
kube:WinDSR=true|false (ALPHA — default=false)
kube:WinOverlay=true|false (BETA — default=true)
kube:WindowsHostNetwork=true|false (ALPHA — default=true)

-h, --help

Довідка kube-scheduler

--http2-max-streams-per-connection int

Обмеження, яке сервер надає клієнтам на максимальну кількість потоків у зʼєднанні HTTP/2. Нуль означає використання стандартних значень golang.

--kube-api-burst int32     Типово: 100

DEPRECATED: сплеск для використання під час спілкування з apiserver'ом kubernetes. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--kube-api-content-type string     Типово: "application/vnd.kubernetes.protobuf"

DEPRECATED: тип вмісту запитів, що надсилаються до apiserver. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--kube-api-qps float     Типово: 50

DEPRECATED: Використовувати QPS під час спілкування з apiserver'ом kubernetes. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--kubeconfig string

DEPRECATED: шлях до файлу kubeconfig з інформацією про авторизацію та місцезнаходження майстра. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--leader-elect     Типово: true

Запускає клієнта виборів лідера і отримує лідерство перед виконанням основного циклу. Увімкніть цю опцію під час запуску реплікованих компонентів для забезпечення високої доступності.

--leader-elect-lease-duration duration     Типово: 15s

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

--leader-elect-renew-deadline duration     Типово: 10s

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

--leader-elect-resource-lock string     Типово: "leases"

Тип обʼєкта ресурсу, який використовується для блокування під час обрання лідера. Підтримувані варіанти: 'leases', 'endpointsleases' і 'configmapsleases'.

--leader-elect-resource-name string     Типово: "kube-scheduler"

Імʼя обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-resource-namespace string     Типово: "kube-system"

Простір імен обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-retry-period duration     Типово: 2s

Час, протягом якого клієнти повинні чекати між спробою отримання та поновленням лідерства. Це стосується лише тих випадків, коли увімкнено обрання лідера.

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--master string

Адреса сервера API Kubernetes (перевизначає будь-яке значення в kubeconfig).

--permit-address-sharing

Якщо це значення дорівнює true, SO_REUSEADDR буде використано при привʼязці порту. Це дозволяє паралельно привʼязуватись до підстановочних IP-адрес, таких як 0.0.0.0, і до конкретних IP-адрес, а також дозволяє уникнути очікування ядром звільнення сокетів у стані TIME_WAIT. [default=false]

--permit-port-sharing

Якщо значення true, SO_REUSEPORT буде використано при привʼязці порту, що дозволяє більш ніж одному екземпляру привʼязуватися до однієї адреси та порту. [default=false]

--pod-max-in-unschedulable-pods-duration duration     Типово: 5m0s

DEPRECATED: максимальний час, протягом якого Pod може перебувати в unschedulablePods. Якщо Pod залишається в unschedulablePods довше, ніж це значення, то його буде переміщено з unschedulablePods до backoffQ або activeQ. Цей прапорець є застарілим і буде вилучений у наступній версії.

--profiling     Типово: true

DEPRECATED: увімкнути профілювання через веб-інтерфейс host:port/debug/prof/. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--requestheader-allowed-names strings

Список загальних імен клієнтських сертифікатів, щоб дозволити вказувати імена користувачів у заголовках, визначених параметром --requestheader-username-headers. Якщо він порожній, можна використовувати будь-який сертифікат клієнта, підтверджений центрами сертифікації у файлі --requestheader-client-ca-file.

--requestheader-client-ca-file string

Пакет кореневих сертифікатів для перевірки клієнтських сертифікатів на вхідних запитах перед тим, як довіряти іменам користувачів у заголовках, визначених параметром --requestheader-username-headers. ПОПЕРЕДЖЕННЯ: зазвичай не залежить від авторизації, яку вже виконано для вхідних запитів.

--requestheader-extra-headers-prefix strings     Типово: "x-remote-extra-"

Список префіксів заголовків запитів для перевірки. Запропоновано X-Remote-Extra-.

--requestheader-group-headers strings     Типово: "x-remote-group"

Список заголовків запитів для перевірки на наявність груп. Пропонується X-Remote-Group.

--requestheader-username-headers strings     Типово: "x-remote-user"

Список заголовків запитів для перевірки на наявність імен користувачів. X-Remote-User є поширеним.

--secure-port int     Типово: 10259

Порт, на якому обслуговувати HTTPS з автентифікацією та авторизацією. Якщо 0, не обслуговувати HTTPS взагалі.

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату - переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, замість того, щоб дивуватися, коли вони будуть назавжди вилучені в наступному релізі.

--tls-cert-file string

Файл, що містить стандартний сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо HTTPS-сервіс увімкнено, а --tls-cert-file і --tls-private-key-file не вказано, для публічної адреси буде згенеровано самопідписаний сертифікат і ключ, які буде збережено в теці, вказаній в --cert-dir.

--tls-cipher-suites strings

Розділений комами список наборів шифрів для сервера. Якщо не вказано, буде використано стандартний набір шифрів Go.
Значення, яким надається перевага: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_RC4_128_SHA.

--tls-min-version string

Мінімальна підтримувана версія TLS. Можливі значення: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

--tls-private-key-file string

>Файл, що містить стандартний приватний ключ x509, який відповідає --tls-cert-file.

--tls-sni-cert-key string

Пара шляхів до файлів сертифіката x509 і приватного ключа, до яких за бажанням додається список доменних шаблонів, які є повними доменними іменами, можливо, з префіксальними підстановчими сегментами. Доменні шаблони також дозволяють використовувати IP-адреси, але IP-адреси слід використовувати лише в тому випадку, якщо apiserver має доступ до IP-адреси, запитуваної клієнтом. Якщо шаблони домену не надано, витягуються імена сертифікатів. Збіги без підстановочних знаків мають перевагу над збігами з підстановочними знаками, а явні шаблони доменів мають перевагу над отриманими іменами. Для кількох пар ключ/сертифікат використовуйте --tls-sni-cert-key кілька разів. Приклади: "example.crt,example.key" або "foo.crt,foo.key:*.foo.com,foo.com".

-v, --v int

число рівня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

--write-config-to string

Якщо встановлено, записати значення стандартної конфігурації до цього файлу і вийти.

13 - Відлагодження кластера

13.1 - Керування потоком

API Priority and Fairness контролює поведінку сервера API Kubernetes у ситуації перевантаження. Ви можете знайти більше інформації про нього у розділі API Priority & Fairness документації.

Діагностика

Кожна відповідь HTTP від API-сервера з увімкненою функцією пріоритету та справедливості має два додаткові заголовки: X-Kubernetes-PF-FlowSchema-UID та X-Kubernetes-PF-PriorityLevel-UID, які вказують на схему потоку, що відповідала запиту, та рівень пріоритету, до якого він був призначений, відповідно. Імена обʼєктів API не включені в ці заголовки (щоб уникнути розкриття деталей у випадку, якщо користувач, який робить запит, не має дозволу на їх перегляд). Під час налагодження ви можете використовувати команду:

kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},name:{metadata.name}"

щоб отримати відповідність UID до імен для FlowSchemas та PriorityLevelConfigurations.

Точки налагодження

З увімкненою функцією APIPriorityAndFairness, kube-apiserver обслуговує наступні додаткові шляхи на своїх HTTP(S) портах.

Вам потрібно переконатися, що у вас є дозволи для доступу до цих точок. Вам не потрібно нічого робити, якщо ви адміністратор. Дозволи можуть бути надані за необхідністю відповідно до RBAC документа для доступу до /debug/api_priority_and_fairness/ шляхом зазначення nonResourceURLs.

  • /debug/api_priority_and_fairness/dump_priority_levels — перелік усіх рівнів пріоритету та поточний стан кожного. Ви можете отримати його так:

    kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests, DispatchedRequests, RejectedRequests, TimedoutRequests, CancelledRequests
catch-all,         0,            true,   false,       0,               0,                 1,                  0,                0,                0
exempt,            0,            true,   false,       0,               0,                 0,                  0,                0,                0
global-default,    0,            true,   false,       0,               0,                 46,                 0,                0,                0
leader-election,   0,            true,   false,       0,               0,                 4,                  0,                0,                0
node-high,         0,            true,   false,       0,               0,                 34,                 0,                0,                0
system,            0,            true,   false,       0,               0,                 48,                 0,                0,                0
workload-high,     0,            true,   false,       0,               0,                 500,                0,                0,                0
workload-low,      0,            true,   false,       0,               0,                 0,                  0,                0,                0

    Пояснення для вибраних назв стовпців:

    • IsQuiescing вказує, чи буде цей рівень пріоритету видалено, коли його черги буде спустошено.

  • /debug/api_priority_and_fairness/dump_queues — перелік усіх черг та їх поточний стан. Ви можете отримати його так:

    kubectl get --raw /debug/api_priority_and_fairness/dump_queues

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, Index,  PendingRequests, ExecutingRequests, SeatsInUse, NextDispatchR,   InitialSeatsSum, MaxSeatsSum, TotalWorkSum
workload-low,      14,     27,              0,                 0,          77.64342019ss,   270,             270,         0.81000000ss
workload-low,      74,     26,              0,                 0,          76.95387841ss,   260,             260,         0.78000000ss
...
leader-election,   0,      0,               0,                 0,          5088.87053833ss, 0,               0,           0.00000000ss
leader-election,   1,      0,               0,                 0,          0.00000000ss,    0,               0,           0.00000000ss
...
workload-high,     0,      0,               0,                 0,          0.00000000ss,    0,               0,           0.00000000ss
workload-high,     1,      0,               0,                 0,          1119.44936475ss, 0,               0,           0.00000000ss

    Пояснення для вибраних назв стовпців:

    • NextDispatchR: показник прогресу R, в одиницях секунд-місць, на якому буде відправлено наступний запит.
    • InitialSeatsSum: сума InitialSeats, повʼязана з усіма запитами в даній черзі.
    • MaxSeatsSum: сума MaxSeats, повʼязана з усіма запитами в даній черзі.
    • TotalWorkSum: сума загальної роботи, в одиницях секунд-місць, усіх запитів, що очікують в черзі.

    Примітка: seat-second (скорочено як ss) є одиницею вимірювання роботи в світі APF.

  • /debug/api_priority_and_fairness/dump_requests — перелік усіх запитів, включаючи запити, що очікують у черзі та запити, що виконуються. Ви можете отримати його так:

    kubectl get --raw /debug/api_priority_and_fairness/dump_requests

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, FlowSchemaName,   QueueIndex, RequestIndexInQueue, FlowDistingsher,                        ArriveTime,                     InitialSeats, FinalSeats, AdditionalLatency, StartTime
exempt,            exempt,           -1,         -1,                  ,                                       2023-07-15T04:51:25.596404345Z, 1,            0,          0s,                2023-07-15T04:51:25.596404345Z
workload-low,      service-accounts, 14,         0,                   system:serviceaccount:default:loadtest, 2023-07-18T00:12:51.386556253Z, 10,           0,          0s,                0001-01-01T00:00:00Z
workload-low,      service-accounts, 14,         1,                   system:serviceaccount:default:loadtest, 2023-07-18T00:12:51.487092539Z, 10,           0,          0s,                0001-01-01T00:00:00Z

    Ви можете отримати більш детальний перелік за допомогою команди:

    kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, FlowSchemaName,   QueueIndex, RequestIndexInQueue, FlowDistingsher,                        ArriveTime,                     InitialSeats, FinalSeats, AdditionalLatency, StartTime,                      UserName,                               Verb,   APIPath,                                   Namespace,   Name,   APIVersion, Resource,   SubResource
exempt,            exempt,           -1,         -1,                  ,                                       2023-07-15T04:51:25.596404345Z, 1,            0,          0s,                2023-07-15T04:51:25.596404345Z, system:serviceaccount:system:admin,     list,   /api/v1/namespaces/kube-stress/configmaps, kube-stress, ,       v1,         configmaps,
workload-low,      service-accounts, 14,         0,                   system:serviceaccount:default:loadtest, 2023-07-18T00:13:08.986534842Z, 10,           0,          0s,                0001-01-01T00:00:00Z,           system:serviceaccount:default:loadtest, list,   /api/v1/namespaces/kube-stress/configmaps, kube-stress, ,       v1,         configmaps,
workload-low,      service-accounts, 14,         1,                   system:serviceaccount:default:loadtest, 2023-07-18T00:13:09.086476021Z, 10,           0,          0s,                0001-01-01T00:00:00Z,           system:serviceaccount:default:loadtest, list,   /api/v1/namespaces/kube-stress/configmaps, kube-stress, ,       v1,         configmaps,

    Пояснення для вибраних назв стовпців:

    • QueueIndex: індекс черги. Він буде -1 для рівнів пріоритету без черг.
    • RequestIndexInQueue: індекс у черзі для даного запиту. Він буде -1 для запитів, що виконуються.
    • InitialSeats: кількість місць, які будуть зайняті під час початкового (нормального) етапу виконання запиту.
    • FinalSeats: кількість місць, які будуть зайняті під час завершального етапу виконання запиту, враховуючи повʼязані повідомлення WATCH.
    • AdditionalLatency: додатковий час, витрачений під час завершального етапу виконання запиту. FinalSeats будуть зайняті протягом цього періоду. Це не означає будь-яку затримку, яку спостерігатиме користувач.
    • StartTime: час початку виконання запиту. Він буде 0001-01-01T00:00:00Z для запитів, що очікують у черзі.

Ведення логів налагодження

На рівні -v=3 або вище, API-сервер виводить рядок httplog для кожного запиту в лозі API-сервера, і він містить наступні атрибути.

  • apf_fs: імʼя схеми потоку, до якої був класифікований запит.
  • apf_pl: імʼя рівня пріоритету для цієї схеми потоку.
  • apf_iseats: кількість місць, визначених для початкового (нормального) етапу виконання запиту.
  • apf_fseats: кількість місць, визначених для завершального етапу виконання (з урахуванням повʼязаних повідомлень watch) запиту.
  • apf_additionalLatency: тривалість завершального етапу виконання запиту.

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

Заголовки відповіді

APF додає наступні два заголовки до кожного HTTP повідомлення. Вони не зʼявляться в лозі аудиту. Їх можна переглянути з боку клієнта. Для клієнтів, що використовують klog, використовуйте рівень деталізації -v=8 або вище, щоб переглянути ці заголовки.

  • X-Kubernetes-PF-FlowSchema-UID містить UID обʼєкта FlowSchema, до якого був класифікований відповідний запит.
  • X-Kubernetes-PF-PriorityLevel-UID містить UID обʼєкта PriorityLevelConfiguration, повʼязаного з цією FlowSchema.

Що далі

Для отримання фонової інформації про деталі дизайну пріоритету та справедливості API дивіться пропозицію щодо покращення.

14 - Конфігураційні API

14.1 - Client Authentication (v1)

Типи ресурсів

ExecCredential

ExecCredential використовується втулками на основі exec для передачі облікових даних до HTTP транспортів.

ПолеОпис
apiVersion
string		client.authentication.k8s.io/v1
kind
string		ExecCredential
spec [Обовʼязкове]
ExecCredentialSpec

Spec містить інформацію, передану транспортом втулку.

status
ExecCredentialStatus

Status заповнюється втулоком і містить облікові дані, які транспорт повинен використовувати для контакту з API.

Cluster

Зустрічається в:

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація.

Щоб забезпечити наявність у цій структурі всього необхідного для звʼязку з кластером Kubernetes (як це робиться через kubeconfig), поля повинні відображати структуру "k8s.io/client-go/tools/clientcmd/api/v1". Cluster, за винятком CertificateAuthority, оскільки дані CA завжди будуть передаватися втулку у вигляді байтів.

ПолеОпис
server [Обовʼязкове]
string

Server — це адреса кластера Kubernetes (https://hostname:port).

tls-server-name
string

TLSServerName передається серверу для SNI і використовується у клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, за яким здійснюється контакт з сервером.

insecure-skip-tls-verify
bool

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

certificate-authority-data
[]byte

CAData містить сертифікати органів сертифікації, закодовані у форматі PEM. Якщо порожнє, слід використовувати системні корені.

proxy-url
string

ProxyURL — це URL-адреса проксі-сервера, який буде використовуватися для всіх запитів до цього кластера.

disable-compression
bool

DisableCompression дозволяє клієнту відмовитися від стиснення відповідей для всіх запитів до сервера. Це корисно для прискорення запитів (особливо списків), коли пропускна здатність мережі клієнт-сервер достатня, за рахунок економії часу на стиснення (на стороні сервера) і розпакування (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

config
k8s.io/apimachinery/pkg/runtime.RawExtension

Config містить додаткові дані конфігурації, специфічні для exec втулка щодо кластера, до якого здійснюється автентифікація.

Ці дані походять з поля extensions[client.authentication.k8s.io/exec] обʼєкта Cluster клієнтської конфігурації:

clusters:

  • name: my-cluster
    cluster:
    ...
    extensions:
    • name: client.authentication.k8s.io/exec # зарезервована назва розширення для конфігурації exec для кожного кластера
      extension:
      audience: 06e3fbd18de8 # довільна конфігурація

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

ExecCredentialSpec

Зустрічається в:

ExecCredentialSpec містить інформацію про запит і специфічну для часу виконання, надану транспортом.

ПолеОпис
cluster
Cluster

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація. Зверніть увагу, що Cluster є ненульовим тільки тоді, коли provideClusterInfo встановлено в true у конфігурації exec провайдера (тобто, ExecConfig.ProvideClusterInfo).

interactive [Обовʼязкове]
bool

Interactive вказує, чи було передано stdin цьому exec втулку.

ExecCredentialStatus

Зустрічається в:

ExecCredentialStatus містить облікові дані для використання транспортом.

Token і ClientKeyData є конфіденційними полями. Ці дані повинні передаватися тільки в памʼяті між клієнтом і процесом exec втулка. Сам exec втулок повинен бути захищений принаймні через права доступу до файлів.

ПолеОпис
expirationTimestamp
meta/v1.Time

ExpirationTimestamp вказує час, коли надані облікові дані закінчуються.

token [Обовʼязкове]
string

Token є маркером доступу, що використовується клієнтом для автентифікації запитів.

clientCertificateData [Обовʼязкове]
string

PEM-кодовані клієнтські TLS сертифікати (включаючи проміжні, якщо є).

clientKeyData [Обовʼязкове]
string

PEM-кодований приватний ключ для вищезгаданого сертифіката.

14.2 - Client Authentication (v1beta1)

Типи ресурсів

ExecCredential

ExecCredential використовується втулками на основі exec для передачі облікових даних до HTTP транспортів.

ПолеОпис
apiVersion
string		client.authentication.k8s.io/v1beta1
kind
string		ExecCredential
spec [Обовʼязкове]
ExecCredentialSpec

Spec містить інформацію, передану транспортом втулку.

status
ExecCredentialStatus

Status заповнюється втулком і містить облікові дані, які транспорт повинен використовувати для контакту з API.

Cluster

Зустрічається в:

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється аутентифікація.

Щоб забезпечити наявність у цій структурі всього необхідного для звʼязку з кластером Kubernetes (як це робиться через kubeconfig), поля повинні відображати структуру "k8s.io/client-go/tools/clientcmd/api/v1". Cluster, за винятком CertificateAuthority, оскільки дані CA завжди будуть передаватися втулку у вигляді байтів.

ПолеОпис
server [Обовʼязкове]
string

Server — це адреса кластера Kubernetes (https://hostname:port).

tls-server-name
string

TLSServerName передається серверу для SNI і використовується у клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, за яким здійснюється контакт з сервером.

insecure-skip-tls-verify
bool

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

certificate-authority-data
[]byte

CAData містить сертифікати органів сертифікації, закодовані у форматі PEM. Якщо порожнє, слід використовувати системні корені.

proxy-url
string

ProxyURL — це URL-адреса проксі-сервера, який буде використовуватися для всіх запитів до цього кластера.

disable-compression
bool

DisableCompression дозволяє клієнту відмовитися від стиснення відповідей для всіх запитів до сервера. Це корисно для прискорення запитів (особливо списків), коли пропускна здатність мережі клієнт-сервер достатня, за рахунок економії часу на стиснення (на стороні сервера) і розпакування (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

config
k8s.io/apimachinery/pkg/runtime.RawExtension

Config містить додаткові дані конфігурації, специфічні для exec втулка щодо кластера, до якого здійснюється аутентифікація.

Ці дані походять з поля extensions[client.authentication.k8s.io/exec] обʼєктаCluster клієнтської конфігурації:

clusters:

  • name: my-cluster
    cluster:
    ...
    extensions:
    • name: client.authentication.k8s.io/exec # зарезервована назва розширення для конфігурації exec для кожного кластера
      extension:
      audience: 06e3fbd18de8 # довільна конфігурація

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

ExecCredentialSpec

Зустрічається в:

ExecCredentialSpec містить інформацію про запит і специфічну для часу виконання, надану транспортом.

ПолеОпис
cluster
Cluster

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація. Зверніть увагу, що Cluster є ненульовим тільки тоді, коли provideClusterInfo встановлено в true у конфігурації exec провайдера (тобто, ExecConfig.ProvideClusterInfo).

interactive [Обовʼязкове]
bool

Interactive вказує, чи було передано stdin цьому exec втулку.

ExecCredentialStatus

Зустрічається в:

ExecCredentialStatus містить облікові дані для використання транспортом.

Token і ClientKeyData є конфіденційними полями. Ці дані повинні передаватися тільки в памʼяті між клієнтом і процесом exec втулка. Сам exec втулок повинен бути захищений принаймні через права доступу до файлів.

ПолеОпис
expirationTimestamp
meta/v1.Time

ExpirationTimestamp вказує час, коли надані облікові дані закінчуються.

token [Обовʼязкове]
string

Token є маркером доступу, що використовується клієнтом для аутентифікації запитів.

clientCertificateData [Обовʼязкове]
string

PEM-кодовані клієнтські TLS сертифікати (включаючи проміжні, якщо є).

clientKeyData [Обовʼязкове]
string

PEM-кодований приватний ключ для вищезгаданого сертифіката.

14.3 - Event Rate Limit Configuration (v1alpha1)

Типи ресурсів

Configuration

Configuration надає конфігурацію для контролера доступу EventRateLimit.

ПолеОпис
apiVersion
string		eventratelimit.admission.k8s.io/v1alpha1
kind
string		Configuration
limits [Обовʼязкове]
[]Limit

limits — це обмеження на запити подій, що надходять. Обмеження можуть бути встановлені на події, отримані на рівні сервера, на рівні простору імен, на рівні користувача та на рівні джерела+обʼєкта. Потрібно принаймні одне обмеження.

Limit

Зустрічається в:

Limit — це конфігурація для певного типу обмеження.

ПолеОпис
type [Обовʼязкове]
LimitType

type — це тип обмеження, до якого застосовується ця конфігурація.

qps [Обовʼязкове]
int32

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

burst [Обовʼязкове]
int32

burst — це кількість запитів подій burst, дозволених для цього типу обмеження. Поля qps та burst використовуються разом, щоб визначити, чи приймається певний запит події. burst визначає максимальний розмір дозволу, наданого для певного відра. Наприклад, якщо burst дорівнює 10, а qps дорівнює 3, то контроль доступу прийме 10 запитів перед блокуванням будь-яких запитів. Кожну секунду буде дозволено ще 3 запити. Якщо деяка частина цього дозволу не використовується, то вона переноситься на наступну секунду, поки не буде досягнуто максимального дозволу у 10 запитів.

cacheSize
int32

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

Стандартний розмір кешу становить 4096.

Якщо limitType — 'server', то cacheSize ігнорується.

LimitType

(Аліас string)

Зустрічається в:

LimitType — це тип обмеження (наприклад, на рівні простору імен).

14.4 - Image Policy API (v1alpha1)

Типи ресурсів

ImageReview

ImageReview перевіряє, чи дозволений набір образів у поді.

ПолеОпис
apiVersion
string		imagepolicy.k8s.io/v1alpha1
kind
string		ImageReview
metadata
meta/v1.ObjectMeta

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata. Зверніться до документації Kubernetes API для полів метаданих metadata.

spec [Обовʼязкове]
ImageReviewSpec

Spec містить інформацію про под, що оцінюється.

status
ImageReviewStatus

Status заповнюється бекендом і вказує, чи слід дозволити Pod.

ImageReviewContainerSpec

Зустрічається в:

ImageReviewContainerSpec — це опис контейнера в запиті на створення Podʼа.

ПолеОпис
image
string

Це може бути у вигляді image:tag або image@SHA:012345679abcdef.

ImageReviewSpec

Зустрічається в:

ImageReviewSpec — це опис запиту на створення Podʼа.

ПолеОпис
containers
[]ImageReviewContainerSpec

Containers — це список підмножини інформації в кожному контейнері пода, що створюється.

annotations
map[string]string

Annotations — це список ключ-значення, витягнутий з анотацій Podʼа. Він включає лише ключі, які відповідають шаблону *.image-policy.k8s.io/*. Відповідно до кожного веб-хука, щоб визначити, як інтерпретувати ці анотації, якщо взагалі.

namespace
string

Namespace — це простір імен, в якому створюється под.

ImageReviewStatus

Зустрічається в:

ImageReviewStatus — це результат перевірки запиту на створення Podʼа.

ПолеОпис
allowed [Обовʼязкове]
bool

Allowed вказує, що всі образи були дозволені до виконання.

reason
string

Reason має бути порожнім, якщо Allowed є true, у протилежному випадку може містити короткий опис проблеми. Kubernetes може обрізати надто довгі помилки під час відображення користувачу.

auditAnnotations
map[string]string

AuditAnnotations буде додано до обʼєкта атрибутів запиту контролера доступу за допомогою 'AddAnnotation'. Ключі повинні бути без префіксів (тобто контролер доступу додасть відповідний префікс).

14.5 - kube-apiserver Admission (v1)

Типи ресурсів

AdmissionReview

AdmissionReview описує запит/відповідь на перегляд доступу.

ПолеОпис
apiVersion
string		admission.k8s.io/v1
kind
string		AdmissionReview
request
AdmissionRequest

Request описує атрибути запиту на перегляд доступу.

response
AdmissionResponse

Response описує атрибути відповіді на перегляд доступу.

AdmissionRequest

Зʼявляється в:

AdmissionRequest описує атрибути доступу для запиту на перегляд доступу.

ПолеОпис
uid [Обовʼязкове]
k8s.io/apimachinery/pkg/types.UID

UID — це ідентифікатор для індивідуального запиту/відповіді. Це дозволяє нам розрізняти випадки запитів, які є в іншому випадку ідентичними (паралельні запити, запити, коли попередні запити не змінили і т. д.). UID призначений для відстеження зворотного звʼязку (запит/відповідь) між KAS і WebHook, а не користувацьким запитом. Він підходить для співставлення записів журналу між вебхуком і apiserver для аудиту або налагодження.

kind [Обовʼязкове]
meta/v1.GroupVersionKind

Kind — це повністю кваліфікований тип обʼєкта, що подається (наприклад, v1.Pod або autoscaling.v1.Scale)

resource [Обовʼязкове]
meta/v1.GroupVersionResource

Resource — це повністю кваліфікований ресурс, що запитується (наприклад, v1.pods)

subResource
string

SubResource — це субресурс, що запитується, якщо такий є (наприклад, "status" або "scale")

requestKind
meta/v1.GroupVersionKind

RequestKind — це повністю кваліфікований тип початкового API-запиту (наприклад, v1.Pod або autoscaling.v1.Scale). Якщо це вказано і відрізняється від значення в "kind", було виконано еквівалентне співставлення та перетворення.

Наприклад, якщо deployments можна змінювати за допомогою apps/v1 та apps/v1beta1, і вебхук зареєстрував правило apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"] і matchPolicy: Equivalent, API-запит до деплойментів apps/v1beta1 буде перетворено та надіслано до вебхука з kind: {group:"apps", version:"v1", kind:"Deployment"} (відповідно до правила, зареєстрованого вебхуком), і requestKind: {group:"apps", version:"v1beta1", kind:"Deployment"} (вказуючи на тип початкового API-запиту).

Дивіться документацію для поля "matchPolicy" у типі конфігурації вебхука для отримання додаткової інформації.

requestResource
meta/v1.GroupVersionResource

RequestResource — це повністю кваліфікований ресурс початкового API-запиту (наприклад, v1.pods). Якщо це вказано і відрізняється від значення в "resource", було виконано еквівалентне співставлення та перетворення.

Наприклад, якщо deployments можна змінювати за допомогою apps/v1 та apps/v1beta1, і вебхук зареєстрував правило apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"] і matchPolicy: Equivalent, API-запит до деплойментів apps/v1beta1 буде перетворено та надіслано до вебхука з resource: {group:"apps", version:"v1", resource:"deployments"} (відповідно до ресурсу, зареєстрованого вебхуком), і requestResource: {group:"apps", version:"v1beta1", resource:"deployments"} (вказуючи на ресурс початкового API-запиту).

Дивіться документацію для поля "matchPolicy" у типі конфігурації вебхука.

requestSubResource
string

RequestSubResource — це назва субресурсу початкового API-запиту, якщо такий є (наприклад, "status" або "scale"). Якщо це вказано і відрізняється від значення в "subResource", було виконано еквівалентне співставлення та перетворення. Дивіться документацію для поля "matchPolicy" у типі конфігурації вебхука.

name
string

Імʼя — це назва обʼєкта, як подано в запиті. У разі операції CREATE клієнт може не вказати імʼя та покластися на сервер для генерації імені. Якщо це так, це поле буде містити порожній рядок.

namespace
string

Namespace — це простір імен, повʼязаний із запитом (якщо є).

operation [Обовʼязкове]
Operation

Operation — це операція, що виконується. Це може відрізнятися від операції, що запитується. Наприклад, патч може призвести до виконання операції CREATE або UPDATE.

userInfo [Обовʼязкове]
authentication/v1.UserInfo

UserInfo — це інформація про користувача, який виконує запит

object
k8s.io/apimachinery/pkg/runtime.RawExtension

Object — це обʼєкт з вхідного запиту.

oldObject
k8s.io/apimachinery/ pkg/runtime.RawExtension

OldObject — це існуючий обʼєкт. Заповнюється тільки для запитів TE і UPDATE. 

dryRun
bool

DryRun вказує, що зміни точно не ть збережені —ля цього запиту. Типово: false.

options
k8s.io/apimachinery/pkg/runtime.RawExtension

Options — це структура опцій операції, що виконується. наприклад, meta.k8s.io/v1.DeleteOptions або meta.k8s.io/v1.CreateOptions. Це може бути інше, ніж опції, надані викликачем. наприклад, для запиту патчу виконана операція може бути CREATE, у цьому випадку Options буде meta.k8s.io/v1.CreateOptions, навіть якщо викликач надав meta.k8s.io/v1.PatchOptions.

AdmissionResponse

Зʼявляється в:

AdmissionResponse описує відповідь на перегляд доступу.

ПолеОпис
uid [Обовʼязкове]
k8s.io/apimachinery/pkg/types.UID

UID — це ідентифікатор для індивідуального запиту/відповіді. Це повинно бути скопійовано з відповідного AdmissionRequest.

allowed [Обовʼязкове]
bool

Allowed вказує, чи було дозволено запит на перегляд доступу.

status
meta/v1.Status

Result містить додаткові деталі щодо причин відхилення запиту на перегляд доступу. Це поле НЕ враховується, якщо "Allowed" є "true".

patch
[]byte

Тіло патчу. Наразі ми підтримуємо лише "JSONPatch", який реалізує RFC 6902.

patchType
PatchType

Тип патчу. Наразі ми підтримуємо лише "JSONPatch".

auditAnnotations
map[string]string

AuditAnnotations — це неструктурована карта ключ-значення, встановлена віддаленим контролером перегляду доступу (наприклад, error=image-blacklisted). Контролери MutatingAdmissionWebhook і ValidatingAdmissionWebhook додадуть до ключів префікс з іменем вебхука (наприклад, imagepolicy.example.com/error=image-blacklisted). AuditAnnotations буде надано вебхуком для додавання додаткового контексту до логу аудиту для цього запиту.

warnings
[]string

Warnings — це список попереджувальних повідомлень, що повертаються клієнту API, який робить запит. Попереджувальні повідомлення описують проблему, яку клієнт, що робить API-запит, має виправити або врахувати. По можливості обмежте попереджувальні повідомлення до 120 символів. Попереджувальні повідомлення, що перевищують 256 символів, та велика кількість попереджувальних повідомлень можуть бути скорочені.

Operation

(Аліас string)

Зʼявляється в:

Operation — це тип операції з ресурсом, який перевіряється для контролю доступу

PatchType

(Аліас string)

Зʼявляється в:

PatchType — це тип патчу, що використовується для представлення зміненого обʼєкта.

14.6 - kube-apiserver Audit Configuration (v1)

Типи ресурсів

Event

Зустрічається в:

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

ПолеОпис
apiVersion
string		audit.k8s.io/v1
kind
string		Event
level [Обовʼязково]
Level

Рівень аудиту, на якому була згенерована подія.

auditID [Обовʼязково]
k8s.io/apimachinery/pkg/types.UID

Унікальний ідентифікатор аудиту, згенерований для кожного запиту.

stage [Обовʼязково]
Stage

Стадія обробки запиту, коли був згенерований цей екземпляр події.

requestURI [Обовʼязково]
string

RequestURI — це URI запиту, який був надісланий клієнтом на сервер.

verb [Обовʼязково]
string

Verb — це дієслово Kubernetes, повʼязане із запитом. Для запитів без ресурсів це нижчий регістр HTTP-методу.

user [Обовʼязково]
authentication/v1.UserInfo

Інформація про автентифікованого користувача.

impersonatedUser
authentication/v1.UserInfo

Інформація про користувача, який діє від імені іншого користувача.

sourceIPs
[]string

IP-адреси джерела, звідки надійшов запит і проміжні проксі-сервери. IP-адреси джерела вказані у наступному порядку:

  1. IP-адреси заголовку запиту X-Forwarded-For
  2. Заголовок X-Real-Ip, якщо він не присутній у списку X-Forwarded-For
  3. Віддалена адреса для зʼєднання, якщо вона не відповідає останній IP-адресі у списку до цього (X-Forwarded-For або X-Real-Ip). Примітка: Усі, крім останнього IP, можуть бути довільно встановлені клієнтом.
userAgent
string

UserAgent записує рядок агента користувача, наданий клієнтом. Зазначте, що UserAgent надається клієнтом і не може бути довіреним.

objectRef
ObjectReference

Обʼєктне посилання на цей запит. Не застосовується для запитів типу Список або запитів без ресурсів.

responseStatus
meta/v1.Status

Статус відповіді, заповнений навіть коли ObjectReference не є типом Status. Для успішних відповідей це міститиме лише Code і StatusSuccess. Для не-статусних типів помилок відповідей це буде автоматично заповнено повідомленням про помилку.

requestObject
k8s.io/apimachinery/pkg/runtime.Unknown

Обʼєкт API із запиту у форматі JSON. RequestObject записується в тому вигляді, в якому він був у запиті (можливо, повторно закодований як JSON), до конвертації версій, стандартно, допуску або злиття. Це зовнішній обʼєкт типу версії, і він може бути недійсним обʼєктом самостійно. Опускається для запитів без ресурсів. Записується тільки на рівні Request та вище.

responseObject
k8s.io/apimachinery/pkg/runtime.Unknown

Обʼєкт API, що повертається у відповіді, у форматі JSON. ResponseObject записується після перетворення на зовнішній тип і серіалізується як JSON. Опускається для запитів без ресурсів. Записується тільки на рівні Response.

requestReceivedTimestamp
meta/v1.MicroTime

Час, коли запит досяг сервера API.

stageTimestamp
meta/v1.MicroTime

Час, коли запит досяг поточної стадії аудиту.

annotations
map[string]string

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

EventList

EventList містить події аудиту API.

ПолеОпис
apiVersion
string		audit.k8s.io/v1
kind
string		EventList
metadata
meta/v1.ListMeta

Метадані списку, такі як інформація про пагінацію.

items [Обовʼязково]
[]Event

Перелік подій аудиту.

Policy

Зʼявляється у:

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

ПолеОпис
apiVersion
string		audit.k8s.io/v1
kind
string		Policy
metadata
meta/v1.ObjectMeta

ObjectMeta включено для забезпечення сумісності з API-інфраструктурою.

Зверніться до документації Kubernetes API для полів поля metadata.

rules [Обовʼязково]
[]PolicyRule

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

Запит може відповідати кільком правилам, у такому випадку буде використано ПЕРШЕ відповідне правило.

Типово рівень аудиту — None, але може бути переважений універсальним правилом в кінці списку.

PolicyRules мають строго визначений порядок.

omitStages
[]Stage

OmitStages — це список етапів, для яких не створюються події. Зверніть увагу, що це також може бути вказано для кожного правила окремо, у такому випадку обʼєднання обох буде пропущено.

omitManagedFields
bool

OmitManagedFields вказує, чи слід пропускати керовані поля запитів та відповідей у журналі аудиту API.

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

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

PolicyList

PolicyList — це список політик аудиту.

ПолеОпис
apiVersion
string		audit.k8s.io/v1
kind
string		PolicyList
metadata
meta/v1.ListMeta		Опис не надано.
items [Обовʼязково]
[]Policy		Опис не надано.

GroupResources

Зустрічається в:

GroupResources представляють типи ресурсів в API групі.

ПолеОпис
group
string

Група — це назва API групи, яка містить ресурси. Порожній рядок представляє основну API групу.

resources
[]string

Ресурси — це список ресурсів, до яких застосовується це правило.

Наприклад:

  • pods відповідає Podʼам.
  • pods/log відповідає субресурсу log Podʼів.
  • * відповідає всім ресурсам та їх субресурсам.
  • pods/* відповідає всім субресурсам Podʼів.
  • */scale відповідає всім субресурсам масштабу.

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

Порожній список означає, що застосовуються всі ресурси та субресурси в цій API групі.

resourceNames
[]string

resourceNames — це список імен екземплярів ресурсів, які відповідають політиці. Використання цього поля вимагає, щоб Ресурси були вказані. Порожній список означає, що кожен екземпляр ресурсу відповідає.

Level

(Аліас string)

Зустрічається в:

Level визначає кількість інформації, що реєструється під час аудиту

ObjectReference

Зустрічається в:

ObjectReference містить достатньо інформації, щоб дозволити вам перевірити або змінити обʼєкт, на який посилається.

ПолеОпис
resource
string		Опис відсутній.
namespace
string		Опис відсутній.
name
string		Опис відсутній.
uid
k8s.io/apimachinery/pkg/types.UID		Опис відсутній.
apiGroup
string

APIGroup — це назва API групи, яка містить обʼєкт, на який посилаються. Порожній рядок представляє основну API групу.

apiVersion
string

APIVersion — це версія API групи, яка містить обʼєкт, на який посилаються.

resourceVersion
string		Опис відсутній.
subresource
string		Опис відсутній.

PolicyRule

Зʼявляється в:

PolicyRule зіставляє запити на основі метаданих з рівнем аудиту. Запити повинні відповідати правилам кожного поля (перетин правил).

ПолеОпис
level [Обовʼязково]
Level

Рівень, на якому записуються запити, що відповідають цьому правилу.

users
[]string

Користувачі (за автентифікованим імʼям користувача), до яких застосовується це правило. Порожній список означає всіх користувачів.

userGroups
[]string

Групи користувачів, до яких застосовується це правило. Користувач вважається відповідним, якщо він є членом будь-якої з UserGroups. Порожній список означає всі групи користувачів.

verbs
[]string

Дії, що відповідають цьому правилу. Порожній список означає всі дії.

resources
[]GroupResources

Ресурси, що відповідають цьому правилу. Порожній список означає всі види у всіх групах API.

namespaces
[]string

Простори імен, що відповідають цьому правилу. Порожній рядок "" відповідає ресурсам без простору імен. Порожній список означає всі простори імен.

nonResourceURLs
[]string

NonResourceURLs — це набір шляхів URL, які повинні бути аудійовані. * дозволені, але тільки як повний, кінцевий крок у шляху. Приклади:

  • /metrics — Записувати запити для метрик apiserver
  • /healthz* — Записувати всі перевірки стану
omitStages
[]Stage

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

omitManagedFields
bool

OmitManagedFields вказує, чи слід виключати керовані поля з тіла запиту та відповіді з логу аудиту API.

  • значення 'true' виключає керовані поля з логу аудиту API
  • значення 'false' вказує, що керовані поля повинні бути включені в логу аудиту API. Зверніть увагу, що значення, якщо зазначене, у цьому правилі буде переважати над глобальним стандартним значенням. Якщо значення не зазначено, то діє глобальне стандартне значення, вказане в Policy.OmitManagedFields.

Stage

(Аліас string)

Зʼявляється в:

Stage визначає стадії обробки запитів, на яких можуть створюватися події аудиту.

14.7 - kube-apiserver Configuration (v1)

Пакет v1 — це версія API v1.

Типи ресурсів

AdmissionConfiguration

AdmissionConfiguration надає версійовану конфігурацію для контролерів допуску.

ПолеОпис
apiVersion
string		apiserver.config.k8s.io/v1
kind
string		AdmissionConfiguration
plugins
[]AdmissionPluginConfiguration

Plugins дозволяє вказувати конфігурацію для кожного втулка контролю допуску.

EncryptionConfiguration

EncryptionConfiguration зберігає повну конфігурацію для провайдерів шифрування. Він також дозволяє використовувати шаблони для вказання ресурсів, які повинні бути зашифровані. Використовуйте '*.<group>' для шифрування всіх ресурсів у групі або '*.*' для шифрування всіх ресурсів. '*.' можна використовувати для шифрування всіх ресурсів у основній групі. '*.*' зашифрує всі ресурси, навіть користувацькі, які додаються після запуску сервера API. Використання шаблонів, що перекриваються в межах одного списку ресурсів або між кількома записами, не дозволяється, оскільки частина конфігурації буде неефективною. Списки ресурсів обробляються в порядку, причому перші списки мають пріоритет.

Приклад:

kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
resources:
- resources:
  - events
  providers:
  - identity: {}  # не шифрувати події, навіть якщо *.* зазначено нижче
- resources:
  - secrets
  - configmaps
  - pandas.awesome.bears.example
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: c2VjcmV0IGlzIHNlY3VyZQ==
- resources:
  - '*.apps'
  providers:
  - aescbc:
      keys:
      - name: key2
        secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
- resources:
  - '*.*'
  providers:
  - aescbc:
      keys:
      - name: key3
        secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
ПолеОпис
apiVersion
string		apiserver.config.k8s.io/v1
kind
string		EncryptionConfiguration
resources [Обовʼязково]
[]ResourceConfiguration

resources — це список, що містить ресурси та відповідні їм провайдери шифрування.

AESConfiguration

Зʼявляється в:

AESConfiguration містить конфігурацію API для AES-трансформера.

ПолеОпис
keys [Обовʼязково]
[]Key

keys — це список ключів, які використовуються для створення AES-трансформера. Кожен ключ повинен бути 32 байти для AES-CBC та 16, 24 або 32 байти для AES-GCM.

AdmissionPluginConfiguration

Зʼявляється в:

AdmissionPluginConfiguration надає конфігурацію для одного втулка.

ПолеОпис
name [Обовʼязково]
string

Name — це назва контролера допуску. Вона повинна відповідати зареєстрованій назві втулка контролю допуску.

path
string

Path — це шлях до конфігураційного файлу, який містить конфігурацію втулка

configuration
k8s.io/apimachinery/pkg/runtime.Unknown

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

IdentityConfiguration

Зʼявляється в:

IdentityConfiguration — це порожня структура, яка дозволяє використовувати трансформер ідентичності в конфігурації провайдера.

KMSConfiguration

Зʼявляється в:

KMSConfiguration містить назву, розмір кешу та шлях до конфігураційного файлу для трансформера конвертів на основі KMS.

ПолеОпис
apiVersion
string

apiVersion KeyManagementService

name [Обовʼязково]
string

name — це назва втулка KMS,який буде використовуватися.

cachesize
int32

cachesize — це максимальна кількість секретів, які кешуються в памʼяті. Стандартне значення — 1000. Встановіть негативне значення, щоб вимкнути кешування. Це поле дозволено лише для провайдерів KMS v1.

endpoint [Обовʼязково]
string

endpoint — це адреса прослуховувння gRPC сервера, наприклад, "unix:///var/run/kms-provider.sock".

timeout
meta/v1.Duration

timeout для gRPC викликів до kms-втулка (наприклад, 5 секунд). Стандатне значення — 3 секунди.

Key

Зʼявляється в:

Key містить імʼя та секрет наданого ключа для трансформера.

ПолеОпис
name [Обовʼязково]
string

name — це імʼя ключа, який буде використовуватися при збереженні даних на диск.

secret [Обовʼязково]
string

secret — це фактичний ключ, закодований в base64.

ProviderConfiguration

Зʼявляється в:

ProviderConfiguration зберігає надану конфігурацію для провайдера шифрування.

ПолеОпис
aesgcm [Обовʼязково]
AESConfiguration

aesgcm — це конфігурація для трансформера AES-GCM.

aescbc [Обовʼязково]
AESConfiguration

aescbc — це конфігурація для трансформера AES-CBC.

secretbox [Обовʼязково]
SecretboxConfiguration

secretbox — це конфігурація для трансформера на основі Secretbox.

identity [Обовʼязково]
IdentityConfiguration

identity — це (порожня) конфігурація для трансформера ідентичності.

kms [Обовʼязково]
KMSConfiguration

kms містить назву, розмір кешу та шлях до конфігураційного файлу для трансформера конвертів на основі KMS.

ResourceConfiguration

Зʼявляється в:

ResourceConfiguration зберігає конфігурацію для кожного ресурсу.

ПолеОпис
resources [Обовʼязково]
[]string

resources — це список ресурсів Kubernetes, які мають бути зашифровані. Імена ресурсів походять від resource або resource.group з group/version/resource. Наприклад: pandas.awesome.bears.example — це ресурс користувача з 'group': awesome.bears.example, 'resource': pandas. Використовуйте '*.*' для шифрування всіх ресурсів і '*.<group>' для шифрування всіх ресурсів у певній групі. Наприклад: '*.awesome.bears.example' зашифрує всі ресурси у групі 'awesome.bears.example'. Наприклад: '*.' зашифрує всі ресурси в основній групі (такі як pods, configmaps тощо).

providers [Обовʼязково]
[]ProviderConfiguration

providers — це список трансформерів, які використовуються для читання та запису ресурсів на диск. Наприклад: aesgcm, aescbc, secretbox, identity, kms.

SecretboxConfiguration

Зʼявляється в:

SecretboxConfiguration містить API конфігурацію для трансформера Secretbox.

ПолеОпис
keys [Обовʼязково]
[]Key

keys — це список ключів, які використовуються для створення трансформера Secretbox. Кожен ключ повинен бути довжиною 32 байти.

14.8 - kube-apiserver Configuration (v1alpha1)

Пакет v1alpha1 — це версія API v1alpha1.

Типи ресурсів

TracingConfiguration

Зʼявляється в:

TracingConfiguration надає версійну конфігурацію для клієнтів OpenTelemetry tracing.

ПолеОпис
endpoint
string

Endpoint колектора, куди цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендується не вказувати, і використовувати стандартно otlp grpc localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — це кількість зразків, які потрібно збирати на мільйон проміжків. Рекомендується не вказувати. Якщо не вказано, зразок буде відповідати ставці зразка батьківського проміжку, але інакше ніколи не буде зібраний.

AdmissionConfiguration

AdmissionConfiguration надає версійну конфігурацію для контролерів допуску.

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		AdmissionConfiguration
plugins
[]AdmissionPluginConfiguration

Plugins дозволяє вказати конфігурацію для кожного втулка контролю допуску.

AuthenticationConfiguration

AuthenticationConfiguration надає версійну конфігурацію для автентифікації.

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		AuthenticationConfiguration
jwt [Обовʼязково]
[]JWTAuthenticator

jwt — це список автентифікаторів для автентифікації користувачів Kubernetes за допомогою JWT-сумісних токенів. Автентифікатор спробує розпарсити ID токен, перевірити, чи він підписаний налаштованим постачальником. Публічний ключ для перевірки підпису знаходиться на публічній точці доступу постачальника, використовуючи OIDC discovery. Для вхідного токена кожен JWT-автентифікатор буде спробований у порядку, в якому він зазначений у цьому списку. Зверніть увагу, що інші автентифікатори можуть запускатися до або після JWT-автентифікаторів. Специфічне розташування JWT-автентифікаторів відносно інших автентифікаторів не визначено і не є стабільним у різних версіях. Оскільки кожен JWT-автентифікатор повинен мати унікальний URL постачальника, в більшості випадків лише один JWT-автентифікатор спробує криптографічно перевірити токен.

Мінімальне дійсне наповнення JWT повинно містити наступні вимоги:

{
"iss": "https://issuer.example.com",
"aud": ["audience"],
"exp": 1234567890,
"": "username"
}

AuthorizationConfiguration

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		AuthorizationConfiguration
authorizers [Обовʼязково]
[]AuthorizerConfiguration

Authorizers — це впорядкований список авторизаторів для авторизації запитів. Це схоже на прапорец --authorization-modes в kube-apiserver. Повинен бути принаймні один.

EgressSelectorConfiguration

EgressSelectorConfiguration надає версійну конфігурацію для клієнтів вибору виходу

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		EgressSelectorConfiguration
egressSelections [Обовʼязково]
[]EgressSelection

connectionServices містить список конфігурацій клієнтів вибору виходу.

TracingConfiguration

TracingConfiguration надає версійну конфігурацію для клієнтів трасування.

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		TracingConfiguration
TracingConfiguration [Обовʼязково]
TracingConfiguration		(Члени TracingConfiguration вбудовані в цей тип.)

Вбудувати структуру конфігурації трасування компонента.

AdmissionPluginConfiguration

Зʼявляється в:

AdmissionPluginConfiguration надає конфігурацію для одного втулка.

ПолеОпис
name [Обовʼязково]
string

Name — це імʼя контролера допуску. Воно повинно відповідати зареєстрованому імені втулка допуску.

path
string

Path — це шлях до конфігураційного файлу, що містить конфігурацію втулка.

configuration
k8s.io/apimachinery/pkg/runtime.Unknown

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

AnonymousAuthCondition

Зʼявляється в:

AnonymousAuthCondition описує стан, за якого анонімні автентифікації мають бути увімкнені.

ПолеОпис
path [Обовʼязково]
string

Шлях для якого увімкнено анонімну автентифікацію.

AnonymousAuthConfig

Зʼявляється в:

AnonymousAuthConfig надає конфігурацію для анонімного автентифікатора.

ПолеОпис
enabled [Обовʼязково]
bool		Опис не надано.
conditions [Обовʼязково]
[]AnonymousAuthCondition

Якщо встановлено, анонімна автентифікація дозволена, тільки якщо запит відповідає одній з умов.

AudienceMatchPolicyType

(Псевдонім для string)

Зʼявляється в:

AudienceMatchPolicyType є набором допустимих значень для issuer.audienceMatchPolicy

AuthorizerConfiguration

Зʼявляється в:

ПолеОпис
type [Обовʼязково]
string

Type визначає тип авторизатора. "Webhook" підтримується в загальному API-сервері. Інші API-сервери можуть підтримувати додаткові типи авторизаторів, такі як Node, RBAC, ABAC тощо.

name [Обовʼязково]
string

Name використовується для опису вебхука. Це явно використовується в механізмах моніторингу для метрик. Примітка: Імена повинні бути у форматі DNS1123, такі як myauthorizername або піддомени, такі як myauthorizer.example.domain. Обовʼязково, без стандартного значення.

webhook [Обовʼязково]
WebhookConfiguration

Webhook визначає конфігурацію для вебхук-авторизатора. Повинна бути визначена, коли Type=Webhook. Не повинна бути визначена, коли Type!=Webhook.

ClaimMappings

Зʼявляється в:

ClaimMappings надає конфігурацію для зіставлення заявок.

ПолеОпис
username [Обовʼязково]
PrefixedClaimOrExpression

username представляє опцію для атрибута імені користувача. Значення заявки повинно бути єдиним рядком. Також використовується для прапорців --oidc-username-claim і --oidc-username-prefix. Якщо встановлено username.expression, вираз повинен повертати значення рядка. Якщо username.expression використовує 'claims.email', тоді 'claims.email_verified' повинно бути використане в username.expression або extra[].valueExpression or claimValidationRules[].expression. Приклад виразу правил перевірки заявок, який відповідає перевірці, автоматично застосованій, коли username.claim встановлено в 'email', є 'claims.?email_verified.orValue(true)'.

У підході на основі прапорців, --oidc-username-claim і --oidc-username-prefix є необовʼязковими. Якщо --oidc-username-claim не встановлено, стандартне значення — "sub". Для конфігурації автентифікації немає стандартного значення для заявки або префікса. Заявка та префікс повинні бути явно встановлені. Для заявки, якщо --oidc-username-claim не був встановлений з допомогою підходу старого прапорця, налаштуйте username.claim="sub" у конфігурації автентифікації. Для префікса: (1) --oidc-username-prefix="-" не додає префікс до імені користувача. Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix="" (2) --oidc-username-prefix="" і --oidc-username-claim != "email", префікс був ""<value of --oidc-issuer-url>#". Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix="#" (3) --oidc-username-prefix="". Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix=""

groups
PrefixedClaimOrExpression

groups представляє опцію для атрибута груп. Значення заявки повинно бути рядком або масивом рядків. Якщо встановлено groups.claim, префікс повинен бути зазначений (і може бути пустим рядком). Якщо встановлено groups.expression, вираз повинен повертати рядок або масив рядків. "" (пустий рядок), [] (пустий масив) і null значення трактуються як відсутність зіставлення груп.

uid
ClaimOrExpression

uid представляє опцію для атрибута uid. Заявка повинна бути єдиним рядком. Якщо встановлено uid.expression, вираз повинен повертати рядок.

extra
[]ExtraMapping

extra представляє опцію для атрибута extra. вираз повинен повертати рядок або масив рядків. Якщо значення порожнє, відображення extra не буде присутнім.

жорстко закодоване додаткові ключ/значення

  • key: "foo" valueExpression: "'bar'" Це призведе до додаткового атрибута — foo: ["bar"]

жорстко закодований ключ копіює значення заявки

  • key: "foo" valueExpression: "claims.some_claim" Це призведе до додаткового атрибута — foo: [value of some_claim]

жорстко закодований ключ, значення, що походить від значення заявки

  • key: "admin" valueExpression: '(has(claims.is_admin) && claims.is_admin) ? "true":"' Це призведе до:
  • якщо заявка is_admin присутня і true, додатковий атрибут — admin: ["true"]
  • якщо заявка is_admin присутня і false або заявка is_admin відсутня, жоден додатковий атрибут не буде доданий

ClaimOrExpression

Зʼявляється в:

ClaimOrExpression надає конфігурацію для однієї заявки або виразу.

ПолеОпис
claim
string

claim — це заявка JWT, яку потрібно використовувати. Або claim, або expression повинно бути встановлено. Взаємно виключаються в expression.

expression
string

expression представляє вираз, який буде оцінений CEL.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінні CEL:

  • 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємно виключаються в claim.

ClaimValidationRule

Зʼявляється в:

ClaimValidationRule надає конфігурацію для однієї правила перевірки заявки.

ПолеОпис
claim
string

claim — це імʼя обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові ключі заявок. Взаємно виключається в expression і message.

requiredValue
string

requiredValue — це значення обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові значення заявок. Якщо claim встановлено, а requiredValue не встановлено, заявка повинна бути присутньою зі значенням, встановленим у порожній рядок. Взаємно виключається з expression і message.

expression
string

expression представляє вираз, який буде оцінений CEL. Повинно повернути boolean.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінні CEL:

  • 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'. Повинно повернути true для проходження перевірки.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємно виключається в claim і requiredValue.

message
string

message налаштовує повернуте повідомлення про помилку, коли вираз повертає false. message є літеральним рядком. Взаємно виключається з claim і requiredValue.

Connection

Зʼявляється в:

Connection надає конфігурацію для одного клієнта egress selection.

ПолеОпис
proxyProtocol [Обовʼязково]
ProtocolType

proxyProtocol — це протокол, який використовується для підключення клієнта до сервера konnectivity.

transport
Transport

transport визначає конфігурації транспорту, які ми використовуємо для зʼєднання з сервером konnectivity. Це потрібно, якщо ProxyProtocol — HTTPConnect або GRPC.

EgressSelection

Зʼявляється в:

EgressSelection надає конфігурацію для одного клієнта egress selection.

ПолеОпис
name [Обовʼязково]
string

name — це назва egress selection. Підтримувані значення: "controlplane", "master", "etcd" та "cluster". "master" egress selector застарілий і замінений на "controlplane".

connection [Обовʼязково]
Connection

connection — це точна інформація, що використовується для налаштування egress selection.

ExtraMapping

Зʼявляється в:

ExtraMapping надає конфігурацію для одного додаткового зіставлення.

ПолеОпис
key [Обовʼязково]
string

key — це рядок, що використовується як ключ додаткового атрибуту. key повинен бути шляхом з префіксом домену (наприклад, example.org/foo). Усі символи перед першим "/" повинні бути дійсним піддоменом, як визначено у RFC 1123. Усі символи після першого "/" повинні бути дійсними символами шляху HTTP, як визначено у RFC 3986. key повинен бути у нижньому регістрі. Має бути унікальним.

valueExpression [Обовʼязково]
string

valueExpression — це вираз CEL для вилучення значення додаткового атрибуту. valueExpression повинен виробляти рядкове або масив рядкових значень. "", [], і null значення трактуються як відсутність додаткового зіставлення. Порожні рядкові значення, що містяться в масиві рядків, відфільтровуються.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінній CEL:

  • 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Issuer

Зʼявляється в:

Issuer надає конфігурацію для конкретних налаштувань зовнішнього постачальника.

ПолеОпис
url [Обовʼязково]
string

url вказує на URL-адресу видавця у форматі https://url або https://url/path. Це повинно відповідати заявці "iss" у поданому JWT і видавцю, повернутому з виявлення. Те ж саме значення, що і прапорець --oidc-issuer-url. Інформація про виявлення отримується з "{url}/.well-known/openid-configuration", якщо не перевизначено за допомогою discoveryURL. Має бути унікальним для всіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору egress не використовується для цього мережевого зʼєднання.

discoveryURL
string

discoveryURL, якщо вказано, перевизначає URL, який використовується для отримання інформації про виявлення, замість використання "{url}/.well-known/openid-configuration". Використовується точне вказане значення, тому "/.well-known/openid-configuration" повинно бути включено в discoveryURL, якщо це потрібно.

Поле "issuer" у отриманій інформації про виявлення повинно відповідати полю "issuer.url" у AuthenticationConfiguration і буде використовуватися для перевірки заявки "iss" у поданому JWT. Це для сценаріїв, коли точки доступу well-known і jwks розміщені в іншому місці, ніж видавець (наприклад, локально в кластері).

Приклад: URL виявлення, який опублікований за допомогою сервіса kubernetes 'oidc' у просторі імен 'oidc-namespace', а інформація про виявлення доступна за адресою '/.well-known/openid-configuration'. discoveryURL: "https://oidc.oidc-namespace/.well-known/openid-configuration" certificateAuthority використовується для перевірки зʼєднання TLS, а імʼя хоста на сертифікаті повинно бути встановлено як 'oidc.oidc-namespace'.

curl https://oidc.oidc-namespace/.well-known/openid-configuration (.discoveryURL field) { issuer: "https://oidc.example.com" (.url field) }

discoveryURL повинен відрізнятися від url. Має бути унікальним для всіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору egress не використовується для цього мережевого зʼєднання.

certificateAuthority
string

certificateAuthority містить PEM-кодовані сертифікати органу сертифікації, які використовуються для перевірки зʼєднання під час отримання інформації про виявлення. Якщо не встановлено, використовується системний перевіряючий. Те ж саме значення, що і вміст файлу, на який посилається прапорець --oidc-ca-file.

audiences [Обовʼязково]
[]string

audiences — це набір прийнятних аудиторій, до яких повинен бути виданий JWT. Принаймні один з записів повинен відповідати заявці "aud" у поданих JWT. Те ж саме значення, що і прапорець --oidc-client-id (хоча це поле підтримує масив). Має бути непорожнім.

audienceMatchPolicy
AudienceMatchPolicyType

audienceMatchPolicy визначає, як поле "audiences" використовується для відповідності заявці "aud" у поданому JWT. Допустимі значення:

  1. "MatchAny" при вказанні кількох аудиторій та
  2. порожній (або не встановлений) або "MatchAny" при вказанні однієї аудиторії.

  • MatchAny: заявка "aud" у поданому JWT повинна відповідати принаймні одному з записів у полі "audiences". Наприклад, якщо "audiences" — ["foo", "bar"], заявка "aud" у поданому JWT повинна містити або "foo", або "bar" (і може містити обидва).

  • "": Політика відповідності може бути порожньою (або не встановленою) при вказанні однієї аудиторії у полі "audiences". Заявка "aud" у поданому JWT повинна містити одну аудиторію (і може містити інші).

Для більш детальної перевірки аудиторій використовуйте claimValidationRules. приклад: claimValidationRule[].expression: 'sets.equivalent(claims.aud, ["bar", "foo", "baz"])' для вимоги точної відповідності.

JWTAuthenticator

Зʼявляється в:

JWTAuthenticator надає конфігурацію для одного автентифікатора JWT.

ПолеОпис
issuer [Обовʼязково]
Issuer

issuer містить основні параметри підключення постачальника OIDC.

claimValidationRules
[]ClaimValidationRule

claimValidationRules — це правила, які застосовуються для перевірки заявок токена для автентифікації користувачів.

claimMappings [Обовʼязково]
ClaimMappings

claimMappings вказує заявки токена, які будуть розглядатися як атрибути користувача.

userValidationRules
[]UserValidationRule

userValidationRules - це правила, які застосовуються до кінцевого користувача перед завершенням автентифікації. Ці правила дозволяють застосовувати інваріанти до вхідних ідентичностей, такі як запобігання використанню префіксу system:, який зазвичай використовується компонентами Kubernetes. Правила перевірки поєднуються логічним AND і повинні всі повертати true для успішної перевірки.

PrefixedClaimOrExpression

Зʼявляється в:

PrefixedClaimOrExpression надає конфігурацію для однієї префіксованої заявки або виразу.

ПолеОпис
claim
string

claim — це заявка JWT для використання. Є взаємовиключою з expression.

prefix
string

prefix додається до значення заявки, щоб уникнути конфліктів з існуючими іменами. prefix повинен бути встановлений, якщо встановлена заявка, і може бути порожнім рядком. Взаємовиключається з expression.

expression
string

expression представляє вираз, який буде оцінюватися CEL.

CEL вирази мають доступ до вмісту заявок токена, організованого в CEL змінну:

  • 'claims' — це мапа імен заявок до їх значень. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою нотації крапок, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Є взаємовиключною з claim і prefix.

ProtocolType

(Аліас string)

Зʼявляється в:

ProtocolType — набір допустимих значень для Connection.ProtocolType

Transport

Зʼявляється в:

TCPTransport надає інформацію для зʼєднання з сервером konnectivity через TCP

FieldDescription
url [Обовʼязково]
string

URL — це місцезнаходження сервера konnectivity, до якого потрібно підʼєднатися. Наприклад, це може бути https://127.0.0.1:8131"

tlsConfig
TLSConfig

TLSConfig — конфігурація, необхідна для використання TLS при підключенні до сервера konnectivity

TLSConfig

Зʼявляється в:

TLSConfig надає інформацію для автентифікації для підключення до konnectivity server. Використовується тільки з TCPTransport.

ПолеОпис
caBundle
string

caBundle — це розташування файлу з CA, який буде використовуватися для встановлення довіри з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Якщо відсутній, коли URL TCPTransport має префікс https://, стандартно використовуються системні корені довіри.

clientKey
string

clientKey — це розташування файлу з ключем клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

clientCert
string

clientCert — це розташування файлу з сертифікатом клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

Transport

Зʼявляється в:

Transport визначає конфігурації транспорту, які ми використовуємо для підключення до konnectivity server.

ПолеОпис
tcp
TCPTransport

TCP — це конфігурація TCP для звʼязку з konnectivity server через TCP. ProxyProtocol з GRPC наразі не підтримується з TCP транспортом. Потрібно налаштувати принаймні один з TCP або UDS.

uds
UDSTransport

UDS — це конфігурація UDS для звʼязку з konnectivity server через UDS. Потрібно налаштувати принаймні один з TCP або UDS.

UDSTransport

Зʼявляється в:

UDSTransport надає інформацію для підключення до konnectivity server через UDS.

ПолеОпис
udsName [Обовʼязкове]
string

UDSName — це назва unix domain socket для підключення до konnectivity server. Це не використовує префікс unix://. (Наприклад: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

UserValidationRule

Зʼявляється в:

UserValidationRule надає конфігурацію для одного правила перевірки інформації про користувача.

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінюватися CEL. Повинен повернути true, щоб перевірка пройшла успішно.

CEL вирази мають доступ до вмісту UserInfo, організованого в CEL змінну:

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

message
string

message налаштовує повернуте повідомлення про помилку, коли правило повертає false. message є літеральним рядком.

WebhookConfiguration

Зʼявляється в:

ПолеОпис
authorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей "authorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-authorized-ttl Стандартно: 5m0s

unauthorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей "unauthorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-unauthorized-ttl Стандартно: 30s

timeout [Обовʼязкове]
meta/v1.Duration

Час очікування відповіді від вебхука Максимально дозволене значення — 30s. Обовʼязкове, стандартне значення відсутнє.

subjectAccessReviewVersion [Обовʼязкове]
string

Версія API authorization.k8s.io SubjectAccessReview, яку потрібно відправити та очікувати від вебхука. Те ж саме, що й встановлення прапорця --authorization-webhook-version Дійсні значення: v1beta1, v1. Обовʼязкове, стандартне значення відсутнє

matchConditionSubjectAccessReviewVersion [Обовʼязкове]
string

MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview, яку використовують для оцінки виразів CEL. Дійсні значення: v1. Обовʼязкове, стандартне значення відсутнє

failurePolicy [Обовʼязкове]
string

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

  • NoOpinion: продовжити до наступних авторизаторів, щоб побачити, чи один з них дозволить запит
  • Deny: відхилити запит без консультації з наступними авторизаторами. Обовʼязкове, стандартне значення відсутнє.
connectionInfo [Обовʼязкове]
WebhookConnectionInfo

ConnectionInfo визначає, як ми спілкуємося з вебхуком

matchConditions [Обовʼязкове]
[]WebhookMatchCondition

matchConditions — це список умов, які мають бути виконані, щоб запит було надіслано на цей вебхук. Порожній список matchConditions відповідає всім запитам. Максимально допустимо 64 умови відповідності.

Точна логіка відповідності (в порядку):

  1. Якщо принаймні одна умова відповідності оцінюється як FALSE, то вебхук пропускається.
  2. Якщо ВСІ умови відповідності оцінюються як TRUE, то вебхук викликається.
  3. Якщо принаймні одна умова відповідності оцінюється як помилка (але жодна з них не є FALSE):
    • Якщо failurePolicy=Deny, то вебхук відхиляє запит
    • Якщо failurePolicy=NoOpinion, то помилка ігнорується, і вебхук пропускається

WebhookConnectionInfo

Зʼявляється в:

ПолеОпис
type [Обовʼязкове]
string

Контролює, як вебхук повинен спілкуватися з сервером. Дійсні значення:

  • KubeConfigFile: використовувати файл, зазначений у kubeConfigFile, щоб знайти сервер.
  • InClusterConfig: використовувати внутрішньокластерну конфігурацію для виклику SubjectAccessReview API, який розміщений kube-apiserver. Цей режим не дозволено для kube-apiserver.
kubeConfigFile [Обовʼязкове]
string

Шлях до KubeConfigFile для інформації про підключення. Обовʼязково, якщо connectionInfo.Type є KubeConfig

WebhookMatchCondition

Зʼявляється в:

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінюватися за допомогою CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту SubjectAccessReview у версії v1. Якщо версія, вказана в subjectAccessReviewVersion у змінній запиту, є v1beta1, вміст буде перетворено на версію v1 перед оцінкою виразу CEL.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

14.9 - kube-apiserver Configuration (v1beta1)

Пакет v1beta1 є версією v1beta1 API.

Типи ресурсів

TracingConfiguration

З’являється в:

TracingConfiguration надає версійні налаштування для клієнтів трасування OpenTelemetry.

ПолеОпис
endpoint
string

Точка доступу колектора, до якого цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендовано не встановлювати, стандартна точка доступу для otlp grpc — localhost:4317.

samplingRatePerMillion
int32

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

AuthenticationConfiguration

AuthenticationConfiguration надає версійні налаштування для автентифікації.

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1beta1
kind
string		AuthenticationConfiguration
jwt [Обовʼязково]
[]JWTAuthenticator

jwt — це список автентифікаторів для автентифікації користувачів Kubernetes за допомогою токенів, що відповідають стандартам JWT. Автентифікатор спробує розібрати необроблений ID токен, перевірити, чи підписаний він налаштованим видавцем. Публічний ключ для перевірки підпису виявляється з публічної кінцевої точки видавця за допомогою OIDC discovery. Для вхідного токена кожен JWT автентифікатор буде спробуваний у порядку, в якому він зазначений у цьому списку. Однак зверніть увагу, що інші автентифікатори можуть працювати до або після JWT автентифікаторів. Конкретне положення JWT автентифікаторів щодо інших автентифікаторів не визначено і не стабільне між випусками. Оскільки кожен JWT автентифікатор повинен мати унікальний URL видавця, максимум один JWT автентифікатор спробує криптографічно перевірити токен.

Мінімально допустимий JWT payload повинен містити наступні заявки:

{
"iss": "https://issuer.example.com",
"aud": ["audience"],
"exp": 1234567890,
"": "username"
}

anonymous [Обовʼязково]
AnonymousAuthConfig

Якщо присутній --anonymous-auth не повинен бути встановлений

AuthorizationConfiguration

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1beta1
kind
string		AuthorizationConfiguration
authorizers [Обовʼязково]
[]AuthorizerConfiguration

Authorizers — це впорядкований список авторизаторів для авторизації запитів. Це схоже на прапорець — --authorization-modes kube-apiserver. Має бути принаймні один.

EgressSelectorConfiguration

EgressSelectorConfiguration надає версійні налаштування для клієнтів вибору egress.

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1beta1
kind
string		EgressSelectorConfiguration
egressSelections [Обовʼязково]
[]EgressSelection

connectionServices містить список налаштувань клієнтів вибору egress.

TracingConfiguration

TracingConfiguration надає версійні налаштування для клієнтів трасування.

ПолеОпис
apiVersion
string		apiserver.k8s.io/v1beta1
kind
string		TracingConfiguration
TracingConfiguration [Обовʼязково]
TracingConfiguration		(Елементи TracingConfiguration вбудовані в цей тип.)

Вбудуйте структуру конфігурації трасування компонента.

AnonymousAuthCondition

З’являється в:

AnonymousAuthCondition описує стан, за якого анонімні автентифікації мають бути увімкнені.

ПолеОпис
path [Обовʼязково]
string

Шлях для якого увімкнено анонімну автентифікацію.

AnonymousAuthConfig

З’являється в:

AnonymousAuthConfig надає конфігурацію для анонімного автентифікатора.

ПолеОпис
enabled [Обовʼязково]
bool		Опис не надано.
conditions [Обовʼязково]
[]AnonymousAuthCondition

Якщо встановлено, анонімна автентифікація дозволена, тільки якщо запит відповідає одній з умов.

AudienceMatchPolicyType

(Аліас string)

З’являється в:

AudienceMatchPolicyType — це набір допустимих значень для issuer.audienceMatchPolicy

AuthorizerConfiguration

З’являється в:

ПолеОпис
type [Обовʼязково]
string

Тип відноситься до типу авторизатора "Webhook" підтримується у загальному API сервері Інші API сервери можуть підтримувати додаткові типи авторизаторів такі як Node, RBAC, ABAC і т.д.

name [Обовʼязково]
string

Імʼя, яке використовується для опису webhook Це явно використовується в моніторинговій машинерії для метрик Примітка: Імена повинні бути мітками DNS1123, такими як myauthorizername або піддоменами, такими як myauthorizer.example.domain Обовʼязково, стандартного значення немає

webhook [Обовʼязково]
WebhookConfiguration

Webhook визначає налаштування для Webhook авторизатора Має бути визначено, коли Type=Webhook Не повинно бути визначено, коли Type!=Webhook

ClaimMappings

З’являється в:

ClaimMappings надає налаштування для мапінгу claims.

ПолеОпис
username [Обовʼязково]
PrefixedClaimOrExpression

username представляє опцію для атрибуту username. Значення claim має бути одним рядком. Те ж саме, що й прапори --oidc-username-claim та --oidc-username-prefix. Якщо встановлено username.expression, вираз повинен видавати значення рядка. Якщо username.expression використовує 'claims.email', тоді 'claims.email_verified' повинен використовуватися в username.expression або extra[].valueExpression or claimValidationRules[].expression. Приклад виразу правила валідації claims, який відповідає валідації, що автоматично застосовується, коли username.claim встановлено на 'email', — це 'claims.?email_verified.orValue(true)'.

У підході на основі прапорів, прапорці --oidc-username-claim та --oidc-username-prefix є необовʼязковими. Якщо --oidc-username-claim не встановлено, стандартне значення — "sub". Для конфігурації автентифікації стандартне значення для claim або prefix відсутні. Claim та prefix повинні бути встановлені явно. Для claim, якщо прапорець --oidc-username-claim не було встановлено за допомогою старого підходу, налаштуйте username.claim="sub" у конфігурації автентифікації. Для prefix: (1) --oidc-username-prefix="-", префікс не додавався до імені користувача. Для такої ж поведінки за допомогою конфігурації автентифікації, встановіть username.prefix="" (2) --oidc-username-prefix="" та --oidc-username-claim != "email", префікс був "<значення --oidc-issuer-url>#". Для такої ж поведінки за допомогою конфігурації автентифікації, встановіть username.prefix="#" (3) --oidc-username-prefix="". Для такої ж поведінки за допомогою конфігурації автентифікації, встановіть username.prefix=""

groups
PrefixedClaimOrExpression

groups представляє опцію для атрибуту groups. Значення claim має бути рядком або масивом рядків. Якщо groups.claim встановлено, префікс повинен бути вказаний (і може бути порожнім рядком). Якщо groups.expression встановлено, вираз повинен видавати значення рядка або масиву рядків. "", [], і null значення розглядаються як відсутність мапінгу групи.

uid
ClaimOrExpression

uid представляє опцію для атрибуту uid. Claim повинен бути одним рядковим claim. Якщо uid.expression встановлено, вираз повинен видавати значення рядка.

extra
[]ExtraMapping

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

жорстко закодований extra ключ/значення

  • key: "foo" valueExpression: "'bar'" Це призведе до появи extra атрибуту — foo: ["bar"]

жорстко закодований ключ, значення копіюється з значення claim

  • key: "foo" valueExpression: "claims.some_claim" Це призведе до появи extra атрибуту - foo: [значення some_claim]

жорстко закодований ключ, значення виводиться з значення claim

  • key: "admin" valueExpression: '(has(claims.is_admin) && claims.is_admin) ? "true":""' Це призведе до:
  • якщо claim is_admin присутній та true, extra атрибут — admin: ["true"]
  • якщо claim is_admin присутній та false або claim is_admin не присутній, extra атрибут не буде доданий

ClaimOrExpression

З’являється в:

ClaimOrExpression надає налаштування для одного claim або виразу.

ПолеОпис
claim
string

claim — це JWT claim для використання. Має бути встановлено або claim, або expression. Взаємовиключне з expression.

expression
string

expression представляє вираз, який буде оцінюватися за допомогою CEL.

CEL вирази мають доступ до вмісту claims токену, організованих у CEL змінну:

  • 'claims' — це map з назвами claims до значень claims. Наприклад, змінну з назвою 'sub' можна отримати доступом як 'claims.sub'. Вкладені claims можна отримати доступом за допомогою нотації через крапку, наприклад 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємовиключне з claim.

ClaimValidationRule

З’являється в:

ClaimValidationRule забезпечує конфігурацію для одного правила валідації заяви.

ПолеОпис
claim
string

claim — це імʼя необхідної заяви. Такий же, як прапорець --oidc-required-claim. Підтримуються тільки ключі заяв у форматі рядка. Взаємно виключає з expression та message.

requiredValue
string

requiredValue — це значення необхідної заяви. Такий же, як прапорець --oidc-required-claim. Підтримуються тільки значення заяв у форматі рядка. Якщо claim встановлено, а requiredValue не встановлено, заява повинна бути присутня з значенням, яке дорівнює порожньому рядку. Взаємновиключнє з expression та message.

expression
string

expression представляє вираз, який буде оцінений CEL. Повинен повернути булеве значення.

Вирази CEL мають доступ до вмісту заявок токена, організованого у змінну CEL:

  • 'claims' — це відображення імен заявок на значення заявок. Наприклад, змінна з імʼям 'sub' може бути доступна як 'claims.sub'. Вкладені заяви можна отримати, використовуючи крапкову нотацію, наприклад 'cl ims.foo.bar'. Повинен повернути true для успішної валідації.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємовиключне з claim та requiredValue.

message
string

message налаштовує повідомлення про помилку, яке повертається, коли expression повертає false. message є літералним рядком. Взаємовиключне з claim та requiredValue.

Connection

З’являється в:

Connection надає конфігурацію для одного клієнта вибору egress зʼєднання.

ПолеОпис
proxyProtocol [Обовʼязково]
ProtocolType

Protocol — це протокол, який використовується для зʼєднання клієнта з konnectivity сервером.

transport
Transport

Transport визначає транспортні конфігурації, які ми використовуємо для зʼєднання з konnectivity сервером. Це обовʼязково, якщо ProxyProtocol — це HTTPConnect або GRPC.

EgressSelection

З’являється в:

EgressSelection надає конфігурацію для одного клієнта вибору egress зʼєднання.

ПолеОпис
name [Обовʼязково]
string

name — це назва вибору egress зʼєднання. На даний момент підтримуються значення "controlplane", "master", "etcd" та "cluster". Селекторо egress зʼєднання "master" застарілий і його рекомендується замінити на "controlplane".

connection [Обовʼязково]
Connection

connection — це точна інформація, яка використовується для налаштування вибору вихідного зʼєднання.

ExtraMapping

З’являється в:

ExtraMapping надає конфігурацію для одного додаткового зіставлення.

ПолеОпис
key [Обовʼязково]
string

key — це рядок, який використовується як ключ додаткового атрибуту. key повинен бути шляхом з префіксом домену (наприклад, example.org/foo). Усі символи перед першим "/" повинні бути дійсним субдоменом, як це визначено RFC 1123. Усі символи, що йдуть після першого "/", повинні бути дійсними символами шляху HTTP, як це визначено RFC 3986. key повинен бути написаний малими літерами. Має бути унікальним.

valueExpression [Обовʼязково]
string

valueExpression — це вираз CEL для отримання значення додаткового атрибуту. valueExpression повинен повертати значення рядка або масиву рядків. "", [], та null значення розглядаються як відсутність додаткового зіставлення. Порожні рядкові значення, що містяться у масиві рядків, відфільтровуються.

Вирази CEL мають доступ до вмісту токенів, організованих у змінну CEL:

  • 'claims' — це зіставлення імен вимог до значень вимог. Наприклад, змінна з імʼям 'sub' може бути доступна як 'claims.sub'. Вкладені вимоги можуть бути доступні за допомогою крапкової нотації, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Issuer

З’являється в:

Issuer надає конфігурацію для специфічних налаштувань зовнішнього постачальника.

discoveryURL повинен відрізнятися від url. Має бути унікальним серед усіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору вихідного зʼєднання не використовується для цього мережевого зʼєднання.

ПолеОпис
url [Обовʼязково]
string

url вказує на URL видавця у форматі https://url або https://url/path. Це повинно відповідати вимозі "iss" у наданому JWT і видавцю, який повертається discovery. Таке саме значення, як і прапорець --oidc-issuer-url. Інформація про discovery отримується з "{url}/.well-known/openid-configuration", якщо discoveryURL не перевизначений. Вимагається бути унікальним серед усіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору вихідного зʼєднання не використовується для цього мережевого зʼєднання.

discoveryURL
string

discoveryURL, якщо вказано, перевизначає URL, використовуваний для отримання інформації про discovery, замість використання "{url}/.well-known/openid-configuration". Використовується точне вказане значення, тому "/.well-known/openid-configuration" повинен бути включений у discoveryURL, якщо це необхідно.

Поле "issuer" у отриманій інформації про discovery повинно відповідати полю "issuer.url" в AuthenticationConfiguration і буде використовуватися для перевірки вимоги "iss" у наданому JWT. Це призначено для сценаріїв, коли загальновідомі та точки доступу jwks розміщуються в іншому місці, ніж видавець (наприклад, локально у кластері).

Приклад: URL discovery, який експонується за допомогою сервіса kubernetes 'oidc' у просторі імен 'oidc-namespace' і інформація про discovery доступна за адресою '/.well-known/openid-configuration'. discoveryURL: "https://oidc.oidc-namespace/.well-known/openid-configuration" certificateAuthority використовується для перевірки TLS-зʼєднання, і імʼя хоста на сертифікаті повинно бути налаштовано на 'oidc.oidc-namespace'.

curl https://oidc.oidc-namespace/.well-known/openid-configuration (.discoveryURL поле) { issuer: "https://oidc.example.com" (.url поле) }

certificateAuthority
string

certificateAuthority містить сертифікати уповноважених органів, закодовані в PEM, які використовуються для перевірки зʼєднання під час отримання інформації про discovery. Якщо не встановлено, використовується системний перевіряльник. Таке саме значення, як і вміст файлу, на який посилається прапорець --oidc-ca-file.

audiences [Обовʼязково]
[]string

audiences — це набір прийнятних аудиторій, для яких повинен бути виданий JWT. Щонайменше один з записів повинен відповідати вимозі "aud" у наданих JWT. Таке саме значення, як і прапорець --oidc-client-id (хоча це поле підтримує масив). Має бути непорожнім.

audienceMatchPolicy
AudienceMatchPolicyType

audienceMatchPolicy визначає, як поле "audiences" використовується для співставлення з вимогою "aud" у наданому JWT. Допустимі значення:

  1. "MatchAny", коли вказано кілька аудиторій
  2. порожнє (або не встановлене) або "MatchAny", коли вказано одну аудиторію.

  • MatchAny: вимога "aud" у наданому JWT повинна відповідати щонайменше одному з записів у полі "audiences". Наприклад, якщо "audiences" містить ["foo", "bar"], вимога "aud" у наданому JWT повинна містити або "foo", або "bar" (і може містити обидва).

  • "": Політика співставлення може бути порожньою (або не встановленою), коли у полі "audiences" вказано одну аудиторію. Вимога "aud" у наданому JWT повинна містити одну аудиторію (і може містити інші).

Для більш точного перевірки аудиторій використовуйте claimValidationRules. Приклад: claimValidationRule[].expression: 'sets.equivalent(claims.aud, ["bar", "foo", "baz"])', щоб вимагати точного співпадіння.

JWTAuthenticator

З’являється в:

JWTAuthenticator надає конфігурацію для одного JWT автентифікатора.

ПолеОпис
issuer [Обовʼязково]
Issuer

issuer містить основні параметри підключення постачальника OIDC.

claimValidationRules
[]ClaimValidationRule

claimValidationRules — це правила, які застосовуються для перевірки вимог токенів для автентифікації користувачів.

claimMappings [Обовʼязково]
ClaimMappings

claimMappings вказує вимоги токена, які слід вважати атрибутами користувача.

userValidationRules
[]UserValidationRule

userValidationRules — це правила, які застосовуються до кінцевого користувача перед завершенням автентифікації. Ці правила дозволяють застосовувати інваріанти до вхідних ідентичностей, наприклад, забороняти використання префіксу system:, який зазвичай використовується компонентами Kubernetes. Правила перевірки логічно повʼязані оператором AND і всі повинні повернути true, щоб перевірка пройшла.

PrefixedClaimOrExpression

З’являється в:

PrefixedClaimOrExpression надає конфігурацію для одного префіксованого вимоги або виразу.

ПолеОпис
claim
string

claim — це JWT вимога для використання. Взаємовиключне з expression.

prefix
string

prefix додається до значення вимоги, щоб уникнути конфліктів з існуючими іменами. prefix необхідно встановити, якщо встановлено claim, і він може бути порожнім рядком. Взаємовиключне з expression.

expression
string

expression представляє вираз, який буде оцінюватися за допомогою CEL.

CEL вирази мають доступ до вмісту вимог токену, організованого у змінну CEL:

  • 'claims' є зіставленням імен вимог до значень вимог. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені вимоги можна отримати за допомогою нотації з крапкою, наприклад 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємовиключне з claim і prefix.

TCPTransport

З’являється в:

TCPTransport надає інформацію для підключення до konnectivity серверу через TCP

ПолеОпис
url [Обовʼязково]
string

URL є місцем розташування konnectivity серверу для підключення. Як приклад, це може бути "https://127.0.0.1:8131"

tlsConfig
TLSConfig

TLSConfig є конфігурацією, необхідною для використання TLS при підключенні до konnectivity серверу

TLSConfig

З’являється в:

TLSConfig надає інформацію для автентифікації для підключення до konnectivity серверу. Використовується тільки з TCPTransport

ПолеОпис
caBundle
string

caBundle — це місцезнаходження файлу CA, який буде використовуватися для визначення довіри до konnectivity серверу. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Якщо відсутній, а TCPTransport.URL починається з https://, стандартно використовуються системні корені довіри.

clientKey
string

clientKey — це місцезнаходження файлу клієнтського ключа, який буде використовуватися в mtls рукостисканнях з konnectivity сервером. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Має бути налаштований, якщо TCPTransport.URL починається з https://

clientCert
string

clientCert — це місцезнаходження файлу клієнтського сертифіката, який буде використовуватися в mtls рукостисканнях з konnectivity сервером. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Має бути налаштований, якщо TCPTransport.URL починається з https://

Transport

З’являється в:

Transport визначає конфігурації транспорту, які ми використовуємо для зʼєднання з konnectivity сервером

ПолеОпис
tcp
TCPTransport

TCP — це конфігурація TCP для звʼязку з konnectivity сервером через TCP. ProxyProtocol GRPC наразі не підтримується з TCP транспортом. Вимагає налаштування хоча б одного з TCP або UDS

uds
UDSTransport

UDS — це конфігурація UDS для звʼязку з konnectivity сервером ерез UDS. Вимагає налаштування хоча б одного з TCP або UDS

UDSTransport

З’являється в:

UDSTransport надає інформацію для підключення до konnectivity серверу через UDS

ПолеОпис
udsName [Обовʼязкове]
string

UDSName — це назва unix domain socket для підключення до konnectivity серверу. Не використовує префікс unix://. (Наприклад: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

UserValidationRule

З’являється в:

UserValidationRule надає конфігурацію для одного правила валідації інформації про користувача.

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінено за допомогою CEL. Має повернути true, щоб перевірка була успішною.

CEL вирази мають доступ до вмісту UserInfo, організованого в CEL змінну:

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

message
string

message налаштовує повернуте повідомлення про помилку, коли правилоило повертає false. message є літеральним рядком.

WebhookConfiguration

З’являється в:

ПолеОпис
authorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей 'authorized' від webhook авторизатора. Те ж саме, що і встановлення --authorization-webhook-cache-authorized-ttl прапорця. Стандартно: 5m0s

unauthorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей 'unauthorized' від webhook авторизатора. Те ж саме, що і встановлення --authorization-webhook-cache-unauthorized-ttl прапорця. Стандартно: 30s

timeout [Обовʼязкове]
meta/v1.Duration

Тайм-аут для запиту webhook. Максимальне допустиме значення - 30s. Обовʼязкове, стандартного значення немає.

subjectAccessReviewVersion [Обовʼязкове]
string

Версія API authorization.k8s.io SubjectAccessReview, яка буде відправлена та очікувана від webhook. Те ж саме, що і встановлення --authorization-webhook-version прапорця. Допустимі значення: v1beta1, v1. Обовʼязкове, стандартного значення немає

matchConditionSubjectAccessReviewVersion [Обовʼязкове]
string

MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview, для якої оцінюються CEL вирази. Допустимі значення: v1. Обовʼязкове, стандартного значення немає

failurePolicy [Обовʼязкове]
string

Контролює рішення про авторизацію, коли запит webhook не вдається завершити або повертає некоректну відповідь або помилки при оцінці matchConditions. Допустимі значення:

  • NoOpinion: продовжувати до наступних авторизаторів, щоб перевірити, чи дозволяє запит хоча б один з них
  • Deny: відхилити запит без консультацій з наступними авторизаторами. Обовʼязкове, стандартного значення немає.
connectionInfo [Обовʼязкове]
WebhookConnectionInfo

ConnectionInfo визначає, як ми спілкуємося з webhook

matchConditions [Обовʼязкове]
[]WebhookMatchCondition

matchConditions — це список умов, які повинні бути виконані, щоб запит був відправлений на цей webhook. Порожній список matchConditions відповідає всім запитам. Максимум 64 умови відповідності дозволені.

Точна логіка відповідності (у порядку):

  1. Якщо хоча б одна matchCondition оцінюється як FALSE, то webhook пропускається.
  2. Якщо ВСІ matchConditions оцінюються як TRUE, то викликається webhook.
  3. Якщо хоча б одна matchCondition оцінюється як помилка (але жодна не є FALSE):
    • Якщо failurePolicy=Deny, то webhook відхиляє запит
    • Якщо failurePolicy=NoOpinion, то помилка ігнорується, і webhook пропускається

WebhookConnectionInfo

З’являється в:

ПолеОпис
type [Обовʼязкове]
string

Контролює, як webhook має спілкуватися з сервером. Допустимі значення:

  • KubeConfigFile: використовувати файл, вказаний у kubeConfigFile, для знаходження сервера.
  • InClusterConfig: використовувати конфігурацію у кластері для виклику SubjectAccessReview API, розміщеного kube-apiserver. Цей режим не дозволений для kube-apiserver.
kubeConfigFile [Обовʼязкове]
string

Шлях до KubeConfigFile для інформації про зʼєднання. Обовʼязкове, якщо connectionInfo.Type — KubeConfig

WebhookMatchCondition

З’являється в:

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінюватися CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту SubjectAccessReview у версії v1. Якщо версія, вказана у змінній запиту subjectAccessReviewVersion, є v1beta1, вміст буде конвертовано у версію v1 перед оцінкою виразу CEL.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

14.10 - kube-controller-manager Configuration (v1alpha1)

Типи ресурсів

NodeControllerConfiguration

Зʼявляється у:

NodeControllerConfiguration містить елементи, що описують NodeController.

ПолеОпис
ConcurrentNodeSyncs [Обовʼязкове]
int32

ConcurrentNodeSyncs — це кількість процесів, які одночасно синхронізують вузли

ServiceControllerConfiguration

Зʼявляється у:

ServiceControllerConfiguration містить елементи, що описують ServiceController.

ПолеОпис
ConcurrentServiceSyncs [Обовʼязкове]
int32

concurrentServiceSyncs — це кількість служб, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління службами, але більше навантаження на процесор (і мережу).

CloudControllerManagerConfiguration

CloudControllerManagerConfiguration містить елементи, що описують cloud-controller manager.

ПолеОпис
apiVersion
string		cloudcontrollermanager.config.k8s.io/v1alpha1
kind
string		CloudControllerManagerConfiguration
Generic [Обовʼязкове]
GenericControllerManagerConfiguration

Generic містить конфігурацію для загального контролера-менеджера

KubeCloudShared [Обовʼязкове]
KubeCloudSharedConfiguration

KubeCloudSharedConfiguration містить конфігурацію для функцій, що використовуються як в cloud controller manager, так і в kube-controller manager.

NodeController [Обовʼязкове]
NodeControllerConfiguration

NodeController містить конфігурацію для функцій, повʼязаних з контролером вузлів.

ServiceController [Обовʼязкове]
ServiceControllerConfiguration

ServiceControllerConfiguration містить конфігурацію для функцій, повʼязаних з контролером служб.

NodeStatusUpdateFrequency [Обовʼязкове]
meta/v1.Duration

NodeStatusUpdateFrequency — це частота, з якою контролер оновлює статус вузлів

Webhook [Обовʼязкове]
WebhookConfiguration

Webhook — це конфігурація для вебхуків, розгорнутих в cloud-controller-manager

CloudProviderConfiguration

Зʼявляється у:

CloudProviderConfiguration містить елементи, що описують постачальника хмарних послуг.

ПолеОпис
Name [Обовʼязкове]
string

Name — це постачальник хмарних послуг.

CloudConfigFile [Обовʼязкове]
string

cloudConfigFile — це шлях до файлу конфігурації постачальника хмарних послуг.

KubeCloudSharedConfiguration

Зʼявляється у:

KubeCloudSharedConfiguration містить елементи, які використовуються як kube-controller manager, так і cloud-controller manager, але не genericconfig.

ПолеОпис
CloudProvider [Обовʼязкове]
CloudProviderConfiguration

CloudProviderConfiguration містить конфігурацію для функцій, повʼязаних з CloudProvider.

ExternalCloudVolumePlugin [Обовʼязкове]
string

externalCloudVolumePlugin вказує втулок, який використовувати, коли cloudProvider є "external". Наразі він використовується хмарними провайдерами з репо для керування вузлами та томами в KCM.

UseServiceAccountCredentials [Обовʼязкове]
bool

useServiceAccountCredentials вказує, чи повинні контролери працювати з окремими службовими обліковими даними.

AllowUntaggedCloud [Обовʼязкове]
bool

дозволяє запуск з непозначеними теґами хмарними екземплярами

RouteReconciliationPeriod [Обовʼязкове]
meta/v1.Duration

routeReconciliationPeriod — це період для узгодження маршрутів, створених для вузлів постачальником хмар.

NodeMonitorPeriod [Обовʼязкове]
meta/v1.Duration

nodeMonitorPeriod — це період для синхронізації NodeStatus в NodeController.

ClusterName [Обовʼязкове]
string

clusterName — це префікс екземпляра для кластеру.

ClusterCIDR [Обовʼязкове]
string

clusterCIDR — це CIDR-діапазон для Pods у кластері.

AllocateNodeCIDRs [Обовʼязкове]
bool

AllocateNodeCIDRs дозволяє виділяти CIDR для Podʼів і, якщо ConfigureCloudRoutes є true, налаштовувати їх на постачальнику хмар.

CIDRAllocatorType [Обовʼязкове]
string

CIDRAllocatorType визначає, який тип розподільника Pod CIDR буде використовуватися.

ConfigureCloudRoutes [Обовʼязкове]
bool

configureCloudRoutes дозволяє налаштовувати CIDR, виділені з allocateNodeCIDRs, на постачальнику хмар.

NodeSyncPeriod [Обовʼязкове]
meta/v1.Duration

nodeSyncPeriod — це період для синхронізації вузлів з постачальником хмар. Довші періоди зменшать кількість викликів до постачальника хмар, але можуть затримати додавання нових вузлів в кластер.

WebhookConfiguration

Зʼявляється у:

WebhookConfiguration містить конфігурацію, повʼязану з вебхуками, розгорнутими в cloud-controller-manager.

ПолеОпис
Webhooks [Обовʼязкове]
[]string

Webhooks — це список вебхуків для активації або деактивації: '*' означає "всі стандартно активовані вебхуки" 'foo' означає "активувати 'foo'" '-foo' означає "деактивувати 'foo'" перший елемент для конкретного імені виграє

LeaderMigrationConfiguration

Зʼявляється у:

ControllerLeaderConfiguration надає конфігурацію для блокування мігруючого лідера.

ПолеОпис
apiVersion
string		controllermanager.config.k8s.io/v1alpha1
kind
string		LeaderMigrationConfiguration
leaderName [Обовʼязкове]
string

LeaderName — це назва ресурсу вибору лідера, який захищає міграцію, наприклад, 1-20-KCM-to-1-21-CCM

resourceLock [Обовʼязкове]
string

ResourceLock вказує на тип обʼєкта ресурсу, який буде використовуватися для блокування. Має бути "leases" або "endpoints"

controllerLeaders [Обовʼязкове]
[]ControllerLeaderConfiguration

ControllerLeaders містить список конфігурацій блокувань лідерів, які мігрують.

ControllerLeaderConfiguration

Зʼявляється у:

ControllerLeaderConfiguration надає конфігурацію для блокування мігруючого лідера.

ПолеОпис
name [Обовʼязкове]
string

Name — це назва контролера, що мігрує, наприклад, service-controller, route-controller, cloud-node-controller тощо

component [Обовʼязкове]
string

Component — це назва компонента, в якому контролер має працювати, наприклад, kube-controller-manager, cloud-controller-manager тощо. Або '*' означає, що контролер може працювати під будь-яким компонентом, який бере участь у міграції.

GenericControllerManagerConfiguration

Зʼявляється у:

GenericControllerManagerConfiguration містить конфігурацію для загального контролер-менеджера.

ПолеОпис
Port [Обовʼязкове]
int32

port — це порт, на якому працює HTTP-сервіс контролера-менеджера.

Address [Обовʼязкове]
string

address — це IP-адреса для обслуговування (встановіть на 0.0.0.0 для всіх інтерфейсів).

MinResyncPeriod [Обовʼязкове]
meta/v1.Duration

minResyncPeriod — це період повторної синхронізації в рефлекторах; буде випадковим між minResyncPeriod і 2*minResyncPeriod.

ClientConnection [Обовʼязкове]
ClientConnectionConfiguration

ClientConnection визначає файл kubeconfig та налаштування зʼєднання клієнта для використання проксі-сервером при спілкуванні з apiserver.

ControllerStartInterval [Обовʼязкове]
meta/v1.Duration

Як довго чекати між запуском контролер-менеджерів.

LeaderElection [Обовʼязкове]
LeaderElectionConfiguration

leaderElection визначає конфігурацію клієнта вибору лідера.

Controllers [Обовʼязкове]
[]string

Controllers — це список контролерів для активації або деактивації: '*' означає "всі контролери, що стандартно активовані" 'foo' означає "активувати 'foo'" '-foo' означає "деактивувати 'foo'" перший елемент для конкретного імені виграє

Debugging [Обовʼязкове]
DebuggingConfiguration

DebuggingConfiguration містить конфігурацію для функцій, повʼязаних з відлагодженням.

LeaderMigrationEnabled [Обовʼязкове]
bool

LeaderMigrationEnabled вказує, чи має бути увімкнена міграція лідера для контролер-менеджера.

LeaderMigration [Обовʼязкове]
LeaderMigrationConfiguration

LeaderMigration містить конфігурацію для міграції лідера.

KubeControllerManagerConfiguration

KubeControllerManagerConfiguration містить елементи, що описують kube-controller manager.

ПолеОпис
apiVersion
string		kubecontrollermanager.config.k8s.io/v1alpha1
kind
string		KubeControllerManagerConfiguration
Generic [Обовʼязкове]
GenericControllerManagerConfiguration

Generic містить конфігурацію для загального контролера-менеджера

KubeCloudShared [Обовʼязкове]
KubeCloudSharedConfiguration

KubeCloudSharedConfiguration містить конфігурацію для спільних функцій як в cloud controller manager, так і в kube-controller manager.

AttachDetachController [Обовʼязкове]
AttachDetachControllerConfiguration

AttachDetachControllerConfiguration містить конфігурацію для функцій, повʼязаних з AttachDetachController.

CSRSigningController [Обовʼязкове]
CSRSigningControllerConfiguration

CSRSigningControllerConfiguration містить конфігурацію для функцій, повʼязаних з CSRSigningController.

DaemonSetController [Обовʼязкове]
DaemonSetControllerConfiguration

DaemonSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з DaemonSetController.

DeploymentController [Обовʼязкове]
DeploymentControllerConfiguration

DeploymentControllerConfiguration містить конфігурацію для функцій, повʼязаних з DeploymentController.

StatefulSetController [Обовʼязкове]
StatefulSetControllerConfiguration

StatefulSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з StatefulSetController.

DeprecatedController [Обовʼязкове]
DeprecatedControllerConfiguration

DeprecatedControllerConfiguration містить конфігурацію для деяких застарілих функцій.

EndpointController [Обовʼязкове]
EndpointControllerConfiguration

EndpointControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointController.

EndpointSliceController [Обовʼязкове]
EndpointSliceControllerConfiguration

EndpointSliceControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointSliceController.

EndpointSliceMirroringController [Обовʼязкове]
EndpointSliceMirroringControllerConfiguration

EndpointSliceMirroringControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointSliceMirroringController.

EphemeralVolumeController [Обовʼязкове]
EphemeralVolumeControllerConfiguration

EphemeralVolumeControllerConfiguration містить конфігурацію для функцій, повʼязаних з EphemeralVolumeController.

GarbageCollectorController [Обовʼязкове]
GarbageCollectorControllerConfiguration

GarbageCollectorControllerConfiguration містить конфігурацію для функцій, повʼязаних з GarbageCollectorController.

HPAController [Обовʼязкове]
HPAControllerConfiguration

HPAControllerConfiguration містить конфігурацію для функцій, повʼязаних з HPAController.

JobController [Обовʼязкове]
JobControllerConfiguration

JobControllerConfiguration містить конфігурацію для функцій, повʼязаних з JobController.

CronJobController [Обовʼязкове]
CronJobControllerConfiguration

CronJobControllerConfiguration містить конфігурацію для функцій, повʼязаних з CronJobController.

LegacySATokenCleaner [Обовʼязкове]
LegacySATokenCleanerConfiguration

LegacySATokenCleanerConfiguration містить конфігурацію для функцій, повʼязаних з LegacySATokenCleaner.

NamespaceController [Обовʼязкове]
NamespaceControllerConfiguration

NamespaceControllerConfiguration містить конфігурацію для функцій, повʼязаних з NamespaceController.

NodeIPAMController [Обовʼязкове]
NodeIPAMControllerConfiguration

NodeIPAMControllerConfiguration містить конфігурацію для функцій, повʼязаних з NodeIPAMController.

NodeLifecycleController [Обовʼязкове]
NodeLifecycleControllerConfiguration

NodeLifecycleControllerConfiguration містить конфігурацію для функцій, повʼязаних з NodeLifecycleController.

PersistentVolumeBinderController [Обовʼязкове]
PersistentVolumeBinderControllerConfiguration

PersistentVolumeBinderControllerConfiguration містить конфігурацію для функцій, повʼязаних з PersistentVolumeBinderController.

PodGCController [Обовʼязкове]
PodGCControllerConfiguration

PodGCControllerConfiguration містить конфігурацію для функцій, повʼязаних з PodGCController.

ReplicaSetController [Обовʼязкове]
ReplicaSetControllerConfiguration

ReplicaSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з ReplicaSet.

ReplicationController [Обовʼязкове]
ReplicationControllerConfiguration

ReplicationControllerConfiguration містить конфігурацію для функцій, повʼязаних з ReplicationController.

ResourceQuotaController [Обовʼязкове]
ResourceQuotaControllerConfiguration

ResourceQuotaControllerConfiguration містить конфігурацію для функцій, повʼязаних з ResourceQuotaController.

SAController [Обовʼязкове]
SAControllerConfiguration

SAControllerConfiguration містить конфігурацію для функцій, повʼязаних з ServiceAccountController.

ServiceController [Обовʼязкове]
ServiceControllerConfiguration

ServiceControllerConfiguration містить конфігурацію для функцій, повʼязаних з ServiceController.

TTLAfterFinishedController [Обовʼязкове]
TTLAfterFinishedControllerConfiguration

TTLAfterFinishedControllerConfiguration містить конфігурацію для функцій, повʼязаних з TTLAfterFinishedController.

ValidatingAdmissionPolicyStatusController [Обовʼязкове]
ValidatingAdmissionPolicyStatusControllerConfiguration

ValidatingAdmissionPolicyStatusControllerConfiguration містить конфігурацію для функцій, повʼязаних з ValidatingAdmissionPolicyStatusController.

AttachDetachControllerConfiguration

Зʼявляється в:

AttachDetachControllerConfiguration містить елементи, що описують AttachDetachController.

ПолеОпис
DisableAttachDetachReconcilerSync [Обовʼязкове]
bool

Reconciler виконує періодичний цикл для узгодження бажаного стану з фактичним станом, ініціюючи операції прикріплення/відкріплення. Цей прапорець включає або вимикає узгодження. Станадртне значення — false, отже, включено.

ReconcilerSyncLoopPeriod [Обовʼязкове]
meta/v1.Duration

ReconcilerSyncLoopPeriod — це період часу, протягом якого цикл узгодження станів чекає між наступними виконаннями. Стандартне знаячення — 60 секунд.

disableForceDetachOnTimeout [Обовʼязкове]
bool

DisableForceDetachOnTimeout вимикає примусове відкріплення, коли максимальний час розмонтування перевищено. Стандартне значення — false, отже, примусове відкріплення при відключенні увімкнено.

CSRSigningConfiguration

Зʼявляється в:

CSRSigningConfiguration містить інформацію про конкретного підписувача CSR

ПолеОпис
CertFile [Обовʼязкове]
string

certFile — це імʼя файлу, що містить PEM-кодований сертифікат X509 CA, який використовується для видачі сертифікатів

KeyFile [Обовʼязкове]
string

keyFile — це імʼя файлу, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для видачі сертифікатів

CSRSigningControllerConfiguration

Зʼявляється в:

CSRSigningControllerConfiguration містить елементи, що описують CSRSigningController.

ПолеОпис
ClusterSigningCertFile [Обовʼязкове]
string

clusterSigningCertFile — це імʼя файлу, що містить PEM-кодований сертифікат X509 CA, використовується для видачі сертифікатів з обмеженням на кластер

ClusterSigningKeyFile [Обовʼязкове]
string

clusterSigningKeyFile — це імʼя файлу, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для видачі сертифікатів з обмеженням на кластер

KubeletServingSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

kubeletServingSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kubelet-serving

KubeletClientSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

kubeletClientSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kube-apiserver-client-kubelet

KubeAPIServerClientSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

kubeAPIServerClientSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kube-apiserver-client

LegacyUnknownSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

legacyUnknownSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/legacy-unknown

ClusterSigningDuration [Обовʼязкове]
meta/v1.Duration

clusterSigningDuration — це максимальний період дії сертифікатів, які видаються. Окремі CSR можуть запитувати коротші сертифікати, встановлюючи spec.expirationSeconds.

CronJobControllerConfiguration

Зʼявляється в:

CronJobControllerConfiguration містить елементи, що описують CronJobController.

ПолеОпис
ConcurrentCronJobSyncs [Обовʼязкове]
int32

concurrentCronJobSyncs — це кількість обʼєктів job, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція job, але більше навантаження на CPU (і мережу).

DaemonSetControllerConfiguration

Зʼявляється в:

DaemonSetControllerConfiguration містить елементи, що описують DaemonSetController.

ПолеОпис
ConcurrentDaemonSetSyncs [Обовʼязкове]
int32

concurrentDaemonSetSyncs — це кількість обʼєктів daemonset, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція daemonset, але більше навантаження на CPU (і мережу).

DeploymentControllerConfiguration

Зʼявляється в:

DeploymentControllerConfiguration містить елементи, що описують DeploymentController.

ПолеОпис
ConcurrentDeploymentSyncs [Обовʼязкове]
int32

concurrentDeploymentSyncs — це кількість обʼєктів deployment, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція deployments, але більше навантаження на CPU (і мережу).

DeprecatedControllerConfiguration

Зʼявляється в:

DeprecatedControllerConfiguration містить елементи, що мають бути застарілими.

EndpointControllerConfiguration

Зʼявляється в:

EndpointControllerConfiguration містить елементи, що описують EndpointController

ПолеОпис
ConcurrentEndpointSyncs [Обовʼязкове]
int32

concurrentEndpointSyncs — це кількість операцій синхронізації точок доступу, які будуть виконуватись одночасно. Більше число = швидше оновлення, але більше навантаження на CPU (і мережу).

EndpointUpdatesBatchPeriod [Обовʼязкове]
meta/v1.Duration

EndpointUpdatesBatchPeriod описує тривалість періоду пакетного оновлення точок доступу. Обробка змін у pod буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями та зменшити загальну кількість оновлень точок доступу.

EndpointSliceControllerConfiguration

Зʼявляєтсья в:

EndpointSliceControllerConfiguration містить елементи, що описують EndpointSliceController.

ПолеОпис
ConcurrentServiceEndpointSyncs [Обовʼязкове]
int32

concurrentServiceEndpointSyncs — це кількість операцій синхронізації точок доступу сервісу, які будуть виконуватись одночасно. Більше число = швидше оновлення EndpointSlice, але більше навантаження на CPU (і мережу).

MaxEndpointsPerSlice [Обовʼязкове]
int32

maxEndpointsPerSlice — максимальна кількість точок доступу, які будуть додані до одного EndpointSlice. Більше точок доступу на один slice призведе до меншої кількості та більших за розміром endpoint slices, але більших ресурсів.

EndpointUpdatesBatchPeriod [Обовʼязкове]
meta/v1.Duration

EndpointUpdatesBatchPeriod описує тривалість періоду пакетного оновлення точок доступу. Обробка змін у pod буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями та зменшити загальну кількість оновлень точок доступу.

EndpointSliceMirroringControllerConfiguration

Зʼявляється в:

EndpointSliceMirroringControllerConfiguration містить елементи, що описують EndpointSliceMirroringController.

ПолеОпис
MirroringConcurrentServiceEndpointSyncs [Обовʼязкове]
int32

mirroringConcurrentServiceEndpointSyncs — це кількість операцій синхронізації точок доступу сервісу, які будуть виконуватись одночасно. Більше число = швидше оновлення EndpointSlice, але більше навантаження на CPU (і мережу).

MirroringMaxEndpointsPerSubset [Обовʼязкове]
int32

mirroringMaxEndpointsPerSubset — максимальна кількість точок доступу, які будуть відображені в EndpointSlice для одного EndpointSubset.

MirroringEndpointUpdatesBatchPeriod [Обовʼязкове]
meta/v1.Duration

mirroringEndpointUpdatesBatchPeriod можна використовувати для пакетного оновлення EndpointSlice. Усі оновлення, викликані змінами в EndpointSlice, будуть затримані до 'mirroringEndpointUpdatesBatchPeriod'. Якщо інші адреси в тому ж ресурсі Endpoints зміняться в цей період, вони будуть обʼєднані в одне оновлення EndpointSlice. Стандартне значення 0 означає, що кожне оновлення Endpoints викликає оновлення EndpointSlice.

EphemeralVolumeControllerConfiguration

Зʼявляєтсья в:

EphemeralVolumeControllerConfiguration містить елементи, що описують EphemeralVolumeController.

ПолеОпис
ConcurrentEphemeralVolumeSyncs [Обовʼязкове]
int32

ConcurrentEphemeralVolumeSyncs — це кількість операцій синхронізації ефемерних томів, які будуть виконуватись одночасно. Більше число = швидше оновлення ефемерних томів, але більше навантаження на CPU (і мережу).

GarbageCollectorControllerConfiguration

Зʼявляється в:

GarbageCollectorControllerConfiguration містить елементи, що описують GarbageCollectorController.

ПолеОпис
EnableGarbageCollector [Обовʼязкове]
bool

Увімкнення загального збирача сміття. ПОВИННО бути синхронізовано з відповідним прапорцем kube-apiserver. УВАГА: загальний збирач сміття є альфа-функцією.

ConcurrentGCSyncs [Обовʼязкове]
int32

ConcurrentGCSyncs — це кількість процесів збирача сміття, які дозволяється синхронізувати одночасно.

GCIgnoredResources [Обовʼязкове]
[]GroupResource

gcIgnoredResources — це список GroupResources, які збирач сміття має ігнорувати.

GroupResource

Зʼявляється в:

GroupResource описує груповий ресурс.

ПолеОпис
Group [Обовʼязкове]
string

Group — це частина групи ресурсу GroupResource.

Resource [Обовʼязкове]
string

Resource — це частина ресурсу ресурсу GroupResource.

HPAControllerConfiguration

Зʼявляється в:

HPAControllerConfiguration містить елементи, що описують HPAController.

ПолеОпис
ConcurrentHorizontalPodAutoscalerSyncs [Обовʼязкове]
int32

ConcurrentHorizontalPodAutoscalerSyncs — кількість обʼєктів HPA, які дозволено синхронізувати одночасно. Більше число = більш чутка обробка HPA, але більше навантаження на CPU (та мережу).

HorizontalPodAutoscalerSyncPeriod [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerSyncPeriod — період для синхронізації кількості Podʼів в горизонтальному автомасштабувальнику Podʼів.

HorizontalPodAutoscalerDownscaleStabilizationWindow [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerDownscaleStabilizationWindow — період, протягом якого автомасштабувальник буде переглядати і не зменшувати кількість Podʼів нижче будь-яких рекомендацій, зроблених протягом цього періоду.

HorizontalPodAutoscalerTolerance [Обовʼязкове]
float64

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

HorizontalPodAutoscalerCPUInitializationPeriod [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerCPUInitializationPeriod — період після запуску Podʼа, коли можуть бути пропущені проби CPU.

HorizontalPodAutoscalerInitialReadinessDelay [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerInitialReadinessDelay — період після запуску Podʼа, протягом якого зміни готовності вважаються як готовність, що встановлюється вперше. Єдиний ефект цього — HPA буде ігнорувати проби CPU від неготових Podʼів, у яких остання зміна готовності відбулася під час цього періоду.

JobControllerConfiguration

Зʼявляється в:

JobControllerConfiguration містить елементи, що описують JobController.

ПолеОпис
ConcurrentJobSyncs [Обовʼязкове]
int32

concurrentJobSyncs — кількість обʼєктів job, які дозволено синхронізувати одночасно. Більше число = більш чутка обробка job, але більше навантаження на CPU (та мережу).

LegacySATokenCleanerConfiguration

Зʼявляється в:

LegacySATokenCleanerConfiguration містить елементи, що описують LegacySATokenCleaner

ПолеОпис
CleanUpPeriod [Обовʼязкове]
meta/v1.Duration

CleanUpPeriod — період часу з моменту останнього використання автоматично згенерованого токена службового облікового запису перед тим, як його можна буде видалити.

NamespaceControllerConfiguration

Зʼявляється в:

NamespaceControllerConfiguration містить елементи, що описують NamespaceController.

ПолеОпис
NamespaceSyncPeriod [Обовʼязкове]
meta/v1.Duration

namespaceSyncPeriod — період для синхронізації оновлень життєвого циклу простору імен.

ConcurrentNamespaceSyncs [Обовʼязкове]
int32

concurrentNamespaceSyncs — кількість обʼєктів простору імен, які можуть синхронізуватися одночасно.

NodeIPAMControllerConfiguration

Зʼявляється в:

NodeIPAMControllerConfiguration містить елементи, що описують NodeIpamController.

ПолеОпис
ServiceCIDR [Обовʼязкове]
string

serviceCIDR — CIDR-діапазон для сервісів в кластері.

SecondaryServiceCIDR [Обовʼязкове]
string

secondaryServiceCIDR — CIDR-діапазон для сервісів в кластері, що використовується в двостекових кластерах. SecondaryServiceCIDR має бути іншої IP-сімʼї, ніж ServiceCIDR.

NodeCIDRMaskSize [Обовʼязкове]
int32

NodeCIDRMaskSize — маска розміру для CIDR вузлів в кластері.

NodeCIDRMaskSizeIPv4 [Обовʼязкове]
int32

NodeCIDRMaskSizeIPv4 — маска розміру для CIDR вузлів в двостековому кластері.

NodeCIDRMaskSizeIPv6 [Обовʼязкове]
int32

NodeCIDRMaskSizeIPv6 — маска розміру для CIDR вузлів в двостековому кластері.

NodeLifecycleControllerConfiguration

Зʼявляється в:

NodeLifecycleControllerConfiguration містить елементи, що описують NodeLifecycleController.

ПолеОпис
NodeEvictionRate [Обовʼязкове]
float32

nodeEvictionRate — кількість вузлів за секунду, на яких видаляються контейнери у разі збоїв вузла, коли зона є справною.

SecondaryNodeEvictionRate [Обовʼязкове]
float32

secondaryNodeEvictionRate — кількість вузлів за секунду, на яких видаляються контейнери у разі збоїв вузла, коли зона є несправною.

NodeStartupGracePeriod [Обовʼязкове]
meta/v1.Duration

nodeStartupGracePeriod — період часу, протягом якого дозволяється, щоб вузол не відгукувався, перш ніж позначити його як несправний.

NodeMonitorGracePeriod [Обовʼязкове]
meta/v1.Duration

nodeMonitorGracePeriod — період часу, протягом якого дозволяється вузлу не відгукуватись, перш ніж позначити його як несправний. Має бути N разів більше, ніж nodeStatusUpdateFrequency kubeletʼа, де N означає кількість спроб, дозволених для kubelet для надсилання статусу вузла.

PodEvictionTimeout [Обовʼязкове]
meta/v1.Duration

podEvictionTimeout — період для належного видалення Podʼів на неактивних вузлах.

LargeClusterSizeThreshold [Обовʼязкове]
int32

secondaryNodeEvictionRate явно перезаписується на 0 для кластерів, менших або рівних largeClusterSizeThreshold.

UnhealthyZoneThreshold [Обовʼязкове]
float32

Зона вважається несправною в nodeEvictionRate та secondaryNodeEvictionRate, коли щонайменше unhealthyZoneThreshold (не менше 3) вузлів у зоні є NotReady.

PersistentVolumeBinderControllerConfiguration

Зʼявляється в:

PersistentVolumeBinderControllerConfiguration містить елементи, що описують PersistentVolumeBinderController.

ПолеОпис
PVClaimBinderSyncPeriod [Обовʼязкове]
meta/v1.Duration

pvClaimBinderSyncPeriod — період для синхронізації постійних томів та заявок на постійні томи.

VolumeConfiguration [Обовʼязкове]
VolumeConfiguration

volumeConfiguration містить конфігурацію для функцій, повʼязаних з томами.

PersistentVolumeRecyclerConfiguration

Зʼявляється в:

PersistentVolumeRecyclerConfiguration містить елементи, що описують втулки для постійних томів.

ПолеОпис
MaximumRetry [Обовʼязкове]
int32

maximumRetry — кількість спроб, які recycler PV виконає у разі невдачі при переробці PV.

MinimumTimeoutNFS [Обовʼязкове]
int32

minimumTimeoutNFS — мінімальний ActiveDeadlineSeconds для використання для Podʼа NFS Recycler.

PodTemplateFilePathNFS [Обовʼязкове]
string

podTemplateFilePathNFS — шлях до файлу з визначенням Podʼа, що використовується як шаблон для переробки постійного тому NFS.

IncrementTimeoutNFS [Обовʼязкове]
int32

incrementTimeoutNFS — приріст часу, який додається за кожен Gi до ActiveDeadlineSeconds для Podʼа NFS scrubber.

PodTemplateFilePathHostPath [Обовʼязкове]
string

podTemplateFilePathHostPath — шлях до файлу з визначенням Podʼа, що використовується як шаблон для переробки постійного тому HostPath. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

MinimumTimeoutHostPath [Обовʼязкове]
int32

minimumTimeoutHostPath — мінімальний ActiveDeadlineSeconds для використання для Podʼа HostPath Recycler. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

IncrementTimeoutHostPath [Обовʼязкове]
int32

incrementTimeoutHostPath — приріст часу, який додається за кожен Gi до ActiveDeadlineSeconds для Podʼа HostPath scrubber. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

PodGCControllerConfiguration

Зʼявляється в:

PodGCControllerConfiguration містить елементи, що описують PodGCController.

ПолеОпис
TerminatedPodGCThreshold [Обовʼязкове]
int32

terminatedPodGCThreshold — кількість завершених Podʼів, які можуть існувати перед тим, як збирач сміття завершених почне видаляти завершені поди. Якщо <= 0, збирач сміття завершених Podʼів вимкнено.

ReplicaSetControllerConfiguration

Зʼявляється в:

ReplicaSetControllerConfiguration містить елементи, що описують ReplicaSetController.

ПолеОпис
ConcurrentRSSyncs [Обовʼязкове]
int32

concurrentRSSyncs — кількість replica set, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління репліками, але більше завантаження на процесор (і мережу).

ReplicationControllerConfiguration

Зʼявляється в:

ReplicationControllerConfiguration містить елементи, що описують ReplicationController.

ПолеОпис
ConcurrentRCSyncs [Обовʼязкове]
int32

concurrentRCSyncs — кількість контролерів реплікацій, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління репліками, але більше завантаження на процесор (і мережу).

ResourceQuotaControllerConfiguration

Зʼявляєтсья в:

ResourceQuotaControllerConfiguration містить елементи, що описують ResourceQuotaController.

ПолеОпис
ResourceQuotaSyncPeriod [Обовʼязкове]
meta/v1.Duration

resourceQuotaSyncPeriod — період для синхронізації статусу використання квоти в системі.

ConcurrentResourceQuotaSyncs [Обовʼязкове]
int32

concurrentResourceQuotaSyncs — кількість ресурсних квот, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління квотами, але більше завантаження на процесор (і мережу).

SAControllerConfiguration

Зʼявляється в:

SAControllerConfiguration містить елементи, що описують ServiceAccountController.

ПолеОпис
ServiceAccountKeyFile [Обовʼязкове]
string

serviceAccountKeyFile — імʼя файлу, що містить PEM-кодований приватний RSA-ключ, який використовується для підписання токенів службовиї облікових записів.

ConcurrentSATokenSyncs [Обовʼязкове]
int32

concurrentSATokenSyncs — кількість операцій синхронізації токенів службових облікових записів які будуть виконуватись одночасно.

RootCAFile [Обовʼязкове]
string

rootCAFile — кореневий сертифікат центру сертифікації, який буде включено у секрет токена службових облікових записів. Це має бути дійсний PEM-кодований CA пакет.

StatefulSetControllerConfiguration

Зʼявляється в:

StatefulSetControllerConfiguration містить елементи, що описують StatefulSetController.

ПолеОпис
ConcurrentStatefulSetSyncs [Обовʼязкове]
int32

concurrentStatefulSetSyncs — кількість обʼєктів StatefulSet, які дозволено синхронізувати одночасно. Більше число = більше чутливість statefulsets, але більше навантаження на ЦП (і мережу).

TTLAfterFinishedControllerConfiguration

Зʼявляється в:

TTLAfterFinishedControllerConfiguration містить елементи, що описують TTLAfterFinishedController.

ПолеОпис
ConcurrentTTLSyncs [Обовʼязкове]
int32

concurrentTTLSyncs — кількість колекторів TTL-after-finished, які дозволено синхронізувати одночасно.

ValidatingAdmissionPolicyStatusControllerConfiguration

Зʼявляється в:

ValidatingAdmissionPolicyStatusControllerConfiguration містить елементи, що описують ValidatingAdmissionPolicyStatusController.

ПолеОпис
ConcurrentPolicySyncs [Обовʼязкове]
int32

ConcurrentPolicySyncs — кількість обʼєктів політики, які дозволено синхронізувати одночасно. Більша кількість = швидше перевірка типів, але більше навантаження на ЦП (і мережу). Стандартне значення — 5.

VolumeConfiguration

Зʼявляється в:

VolumeConfiguration містить усі перераховані прапорці, призначені для конфігурації всіх втулків томів. З цієї конфігурації бінарний файл controller-manager створить багато екземплярів volume.VolumeConfig, кожен з яких містить лише конфігурацію, необхідну для конкретного втулка, які потім передаються відповідному втулку. Бінарний файл ControllerManager є єдиною частиною коду, яка знає, які втулки підтримуються і які прапорці відповідають кожному втулку.

ПолеОпис
EnableHostPathProvisioning [Обовʼязкове]
bool

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

EnableDynamicProvisioning [Обовʼязкове]
bool

enableDynamicProvisioning дозволяє створення томів при запуску в середовищі, яке підтримує динамічне створення. Стандартне значення — true.

PersistentVolumeRecyclerConfiguration [Обовʼязкове]
PersistentVolumeRecyclerConfiguration

persistentVolumeRecyclerConfiguration містить конфігурацію для втулків persistent volume.

FlexVolumePluginDir [Обовʼязкове]
string

volumePluginDir — це повний шлях до теки, в якій втулок flex volume має шукати додаткові сторонні втулки томів.

14.11 - kube-proxy Configuration (v1alpha1)

Типи ресурсів

ClientConnectionConfiguration

Appears in:

ClientConnectionConfiguration містить деталі для створення клієнта.

ПолеОпис
kubeconfig [Обовʼязкове]
string

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes [Обовʼязкове]
string

acceptContentTypes визначає заголовок Accept, що надсилається клієнтами при підключенні до сервера, переважаючи стандартне значення 'application/json'. Це поле контролює всі підключення до сервера, що використовуються конкретним клієнтом.

contentType [Обовʼязкове]
string

contentType — це тип вмісту, що використовується при надсиланні даних на сервер з цього клієнта.

qps [Обовʼязкове]
float32

qps контролює кількість запитів на секунду, дозволених для цього зʼєднання.

burst [Обовʼязкове]
int32

burst дозволяє накопичувати додаткові запити, коли клієнт перевищує свій поріг.

DebuggingConfiguration

Appears in:

DebuggingConfiguration містить конфігурацію для функцій, повʼязаних із налагодженням.

ПолеОпис
enableProfiling [Обовʼязкове]
bool

enableProfiling дозволяє профілювання через веб-інтерфейс за адресою host:port/debug/pprof/

enableContentionProfiling [Обовʼязкове]
bool

enableContentionProfiling дозволяє профілювання блокувань, якщо enableProfiling встановлено в true.

LeaderElectionConfiguration

Appears in:

LeaderElectionConfiguration визначає конфігурацію клієнтів вибору лідера для компонентів, які можуть працювати з увімкненим вибором лідера.

ПолеОпис
leaderElect [Обовʼязкове]
bool

leaderElect дозволяє клієнту вибору лідера отримати лідерство перед виконанням основного циклу. Увімкніть це при запуску повторюваних компонентів для високої доступності.

leaseDuration [Обовʼязкове]
meta/v1.Duration

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

renewDeadline [Обовʼязкове]
meta/v1.Duration

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

retryPeriod [Обовʼязкове]
meta/v1.Duration

retryPeriod — це тривалість, протягом якої клієнти повинні чекати між спробами отримання і поновлення лідерства. Це застосовується тільки в разі увімкнення вибору лідера.

resourceLock [Обовʼязкове]
string

resourceLock вказує тип обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceName [Обовʼязкове]
string

resourceName вказує імʼя обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceNamespace [Обовʼязкове]
string

resourceNamespace вказує простір імен обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

KubeProxyConfiguration

KubeProxyConfiguration містить все необхідне для налаштування проксі-сервера Kubernetes.

ПолеОпис
apiVersion
string		kubeproxy.config.k8s.io/v1alpha1
kind
string		KubeProxyConfiguration
featureGates [Обовʼязкове]
map[string]bool

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

clientConnection [Обовʼязкове]
ClientConnectionConfiguration

clientConnection вказує файл kubeconfig і налаштування зʼєднання клієнта для використання проксі-сервером при спілкуванні з apiserver.

logging [Обовʼязкове]
LoggingConfiguration

logging вказує параметри ведення логу. Дивіться Logs Options для додаткової інформації.

hostnameOverride [Обовʼязкове]
string

hostnameOverride, якщо не порожній, буде використовуватися як імʼя вузла, на якому працює kube-proxy. Якщо не задано, імʼя вузла вважається таким же, як і hostname вузла.

bindAddress [Обовʼязкове]
string

bindAddress може бути використано для переозначення IP-адреси вузла, яка є основною для kube-proxy. Зверніть увагу, що імʼя є історичним артефактом, і kube-proxy насправді не привʼязує жодні сокети до цього IP.

healthzBindAddress [Обовʼязкове]
string

healthzBindAddress — це IP-адреса та порт для сервера перевірки стану, на якому він буде служити, стандартно "0.0.0.0:10256" (якщо bindAddress не встановлено або IPv4), або "[::]:10256" (якщо bindAddress є IPv6).

metricsBindAddress [Обовʼязкове]
string

metricsBindAddress — це IP-адреса та порт для сервера метрик, на якому він буде служити, стандартно "127.0.0.1:10249" (якщо bindAddress не встановлено або IPv4), або "[::1]:10249" (якщо bindAddress є IPv6). (Встановіть на "0.0.0.0:10249" / "[::]:10249", щоб привʼязатися до всіх інтерфейсів.)

bindAddressHardFail [Обовʼязкове]
bool

bindAddressHardFail, якщо true, вказує kube-proxy вважати помилку привʼязки до порту фатальною і вийти

enableProfiling [Обовʼязкове]
bool

enableProfiling дозволяє профілювання через веб-інтерфейс на обробнику /debug/pprof. Обробники профілювання будуть оброблені сервером метрик.

showHiddenMetricsForVersion [Обовʼязкове]
string

showHiddenMetricsForVersion — це версія, для якої ви хочете показати приховані метрики.

mode [Обовʼязкове]
ProxyMode

mode вказує, який режим проксі використовувати.

iptables [Обовʼязкове]
KubeProxyIPTablesConfiguration

iptables містить параметри конфігурації, що стосуються iptables.

ipvs [Обовʼязкове]
KubeProxyIPVSConfiguration

ipvs містить параметри конфігурації, що стосуються ipvs.

nftables [Обовʼязкове]
KubeProxyNFTablesConfiguration

nftables містить параметри конфігурації, що стосуються nftables.

winkernel [Обовʼязкове]
KubeProxyWinkernelConfiguration

winkernel містить параметри конфігурації, що стосуються winkernel.

detectLocalMode [Обовʼязкове]
LocalMode

detectLocalMode визначає режим, який використовується для виявлення локального трафіку, стандартно — ClusterCIDR

detectLocal [Обовʼязкове]
DetectLocalConfiguration

detectLocal містить додаткові параметри конфігурації, що стосуються DetectLocalMode.

clusterCIDR [Обовʼязкове]
string

clusterCIDR — це діапазон CIDR для Podʼів у кластері. (Для кластерів з подвійними стеками це може бути пара діапазонів CIDR, розділених комою). Коли DetectLocalMode встановлено в ClusterCIDR, kube-proxy буде вважати трафік локальним, якщо його вихідний IP знаходиться в цьому діапазоні. (Інакше не використовується.)

nodePortAddresses [Обовʼязкове]
[]string

nodePortAddresses — це список діапазонів CIDR, які містять допустимі IP-адреси вузлів, або, як варіант, єдиний рядок 'primary'. Якщо задано список CIDR, зʼєднання з сервісами NodePort будуть прийматися лише на IP-адресах вузлів в одному з вказаних діапазонів. Якщо встановлено значення 'primary', сервіси NodePort будуть прийматися лише на основну IPv4 та/або IPv6 адресу вузла згідно з обʼєктом Node. Якщо не встановлено, зʼєднання NodePort будуть прийматися на всіх локальних IP.

oomScoreAdj [Обовʼязкове]
int32

oomScoreAdj — це значення oom-score-adj для процесу kube-proxy. Значення повинні бути в межах [-1000, 1000]

conntrack [Обовʼязкове]
KubeProxyConntrackConfiguration

conntrack містить параметри конфігурації, що стосуються conntrack.

configSyncPeriod [Обовʼязкове]
meta/v1.Duration

configSyncPeriod — це інтервал часу, через який конфігурація з apiserver оновлюється. Має бути більше 0.

portRange [Обовʼязкове]
string

portRange раніше використовувався для конфігурації проксі користувача, але тепер не використовується.

windowsRunAsService [Обовʼязкове]
bool

windowsRunAsService, якщо значення true, вмикає інтеграцію API диспетчера керування сервісами Windows.

DetectLocalConfiguration

Зʼявляється у:

DetectLocalConfiguration містить необовʼязкові налаштування, що стосуються параметра DetectLocalMode

ПолеОпис
bridgeInterface [Обовʼязкове]
string

bridgeInterface — це імʼя інтерфейсу моста (bridge). Коли DetectLocalMode встановлено в LocalModeBridgeInterface, kube-proxy буде вважати трафік локальним, якщо він походить з цього моста.

interfaceNamePrefix [Обовʼязкове]
string

interfaceNamePrefix — це префікс імені інтерфейсу. Коли DetectLocalMode встановлено в LocalModeInterfaceNamePrefix, kube-proxy буде вважати трафік локальним, якщо він походить з будь-якого інтерфейсу, чиє імʼя починається з цього префіксу.

KubeProxyConntrackConfiguration

Зʼявляється у:

KubeProxyConntrackConfiguration містить налаштування conntrack для Kubernetes proxy server.

ПолеОпис
maxPerCore [Обовʼязкове]
int32

maxPerCore — максимальна кількість NAT зʼєднань, які слід відстежувати на однt процесорнt ядро (0 для того, щоб залишити обмеження без змін і проігнорувати min).

min [Обовʼязкове]
int32

min — мінімальне значення записів connect-tracking, які слід виділити, незалежно від maxPerCore (встановіть maxPerCore=0, щоб залишити обмеження без змін).

tcpEstablishedTimeout [Обовʼязкове]
meta/v1.Duration

tcpEstablishedTimeout — як довго неактивне TCP зʼєднання буде зберігатися (наприклад, '2s'). Має бути більше 0 для встановлення.

tcpCloseWaitTimeout [Обовʼязкове]
meta/v1.Duration

tcpCloseWaitTimeout — як довго неактивний запис conntrack у стані CLOSE_WAIT залишиться в таблиці conntrack (наприклад, '60s'). Має бути більше 0 для встановлення.

tcpBeLiberal [Обовʼязкове]
bool

tcpBeLiberal, якщо true, kube-proxy налаштує conntrack для роботи в ліберальному режимі для TCP зʼєднань, і пакети з послідовними номерами за межами вікна не будуть позначені як INVALID.

udpTimeout [Обовʼязкове]
meta/v1.Duration

udpTimeout — як довго неактивний запис conntrack для UDP у стані UNREPLIED залишиться в таблиці conntrack (наприклад, '30s'). Має бути більше 0 для встановлення.

udpStreamTimeout [Обовʼязкове]
meta/v1.Duration

udpStreamTimeout — як довго неактивний запис conntrack для UDP у стані ASSURED залишиться в таблиці conntrack (наприклад, '300s'). Має бути більше 0 для встановлення.

KubeProxyIPTablesConfiguration

Зʼявляється у:

KubeProxyIPTablesConfiguration містить налаштування, повʼязані з iptables, для Kubernetes proxy server.

ПолеОпис
masqueradeBit [Обовʼязкове]
int32

masqueradeBit — біт iptables fwmark простору, який слід використовувати для SNAT, якщо використовується режим iptables або ipvs. Значення повинні бути в межах [0, 31].

masqueradeAll [Обовʼязкове]
bool

masqueradeAll вказує kube-proxy виконувати SNAT для всього трафіку, надісланого на IP-адреси сервісів кластера, при використанні режиму iptables або ipvs. Це може бути необхідно для деяких плагінів CNI.

localhostNodePorts [Обовʼязкове]
bool

localhostNodePorts, якщо false, вказує kube-proxy вимкнути застарілу поведінку дозволу доступу до сервісів NodePort через localhost. (Застосовується лише для режиму iptables та IPv4; localhost NodePorts ніколи не дозволяються з іншими режимами проксі або з IPv6.)

syncPeriod [Обовʼязкове]
meta/v1.Duration

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod [Обовʼязкове]
meta/v1.Duration

minSyncPeriod — мінімальний період між повторними синхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації iptables.

KubeProxyIPVSConfiguration

Зʼявляється у:

KubeProxyIPVSConfiguration містить деталі конфігурації, що стосуються IPVS для Kubernetes proxy server.

ПолеОпис
syncPeriod [Обовʼязкове]
meta/v1.Duration

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod [Обовʼязкове]
meta/v1.Duration

minSyncPeriod — мінімальний період між повторними синхронізаціями правил IPVS (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації IPVS.

scheduler [Обовʼязкове]
string

scheduler — IPVS планувальник, який слід використовувати

excludeCIDRs [Обовʼязкове]
[]string

excludeCIDRs — список CIDR, які IPVS proxier не повинен торкатися при очищенні IPVS сервісів.

strictARP [Обовʼязкове]
bool

strictARP налаштовує arp_ignore та arp_announce, щоб уникнути відповіді на ARP запити з інтерфейсу kube-ipvs0

tcpTimeout [Обовʼязкове]
meta/v1.Duration

tcpTimeout — значення тайм-ауту для неактивних IPVS TCP сесій. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

tcpFinTimeout [Обовʼязкове]
meta/v1.Duration

tcpFinTimeout — значення тайм-ауту для IPVS TCP сесій після отримання FIN. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

udpTimeout [Обовʼязкове]
meta/v1.Duration

udpTimeout — значення тайм-ауту для IPVS UDP пакетів. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

KubeProxyNFTablesConfiguration

Зʼявляється у:

KubeProxyNFTablesConfiguration містить деталі конфігурації, що стосуються nftables для Kubernetes proxy server.

ПолеОпис
masqueradeBit [Обовʼязкове]
int32

masqueradeBit — це біт простору iptables fwmark, який слід використовувати для SNAT при використанні режиму nftables. Значення повинні бути в межах [0, 31].

masqueradeAll [Обовʼязкове]
bool

masqueradeAll вказує kube-proxy, щоб SNAT весь трафік, що надходить на IP-адреси кластерів Service, при використанні режиму nftables. Це може бути необхідним для деяких CNI втулків.

syncPeriod [Обовʼязкове]
meta/v1.Duration

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod [Обовʼязкове]
meta/v1.Duration

minSyncPeriod — мінімальний період між повторними синхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації iptables.

KubeProxyWinkernelConfiguration

Зʼявляється у:

KubeProxyWinkernelConfiguration містить налаштування Windows/HNS для Kubernetes proxy server.

ПолеОпис
networkName [Обовʼязкове]
string

networkName — це імʼя мережі, яку kube-proxy використовуватиме для створення точок доступу і політик.

sourceVip [Обовʼязкове]
string

sourceVip — це IP-адреса джерела VIP точки доступу, яка використовується для NAT при балансуванні навантаження.

enableDSR [Обовʼязкове]
bool

enableDSR вказує kube-proxy, чи слід створювати HNS політики з DSR.

rootHnsEndpointName [Обовʼязкове]
string

rootHnsEndpointName — це імʼя hnsendpoint, яке прикріплене до l2bridge для кореневого простору мережі.

forwardHealthCheckVip [Обовʼязкове]
bool

forwardHealthCheckVip пересилає VIP сервісу для порту перевірки справності у Windows.

LocalMode

(Аліас для string)

Зʼявляється у:

LocalMode представляє режими для визначення локального трафіку з вузла.

ProxyMode

(Аліас для string)

Зʼявляється у:

ProxyMode представляє режими, що використовуються сервером проксі Kubernetes.

На даний момент доступні два режими проксі на платформах Linux: 'iptables' та 'ipvs'. Один режим проксі доступний на платформах Windows: 'kernelspace'.

Якщо режим проксі не вказано, буде використано найкращий доступний режим проксі (на даний момент це iptables в Linux і kernelspace у Windows). Якщо вибраний режим проксі не може бути використаний (через відсутність підтримки в ядрі, відсутність компонентів користувацького простору тощо), kube-proxy вийде з помилкою.

14.12 - kube-scheduler Configuration (v1)

Типи ресурсів

ClientConnectionConfiguration

Зʼявляється у:

ClientConnectionConfiguration містить деталі для створення клієнта.

ПолеОпис
kubeconfig [Обовʼязкове]
string

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes [Обовʼязкове]
string

acceptContentTypes визначає заголовок Accept, який надсилається клієнтами при підключенні до сервера, перевизначаючи стандатне значення 'application/json'. Це поле буде контролювати всі зʼєднання з сервером, що використовуються певним клієнтом.

contentType [Обовʼязкове]
string

contentType — тип вмісту, який використовується при надсиланні даних на сервер від цього клієнта.

qps [Обовʼязкове]
float32

qps контролює кількість запитів на секунду, дозволених для цього зʼєднання.

burst [Обовʼязкове]
int32

burst дозволяє накопичувати додаткові запити, коли клієнт перевищує свою норму.

DebuggingConfiguration

Зʼявляється у:

DebuggingConfiguration містить конфігурацію для функцій, що повʼязані з налагодженням.

ПолеОпис
enableProfiling [Обовʼязкове]
bool

enableProfiling увімкне профілювання через веб-інтерфейс host:port/debug/pprof/

enableContentionProfiling [Обовʼязкове]
bool

enableContentionProfiling увімкне профілювання блокувань, якщо enableProfiling увімкнено.

LeaderElectionConfiguration

Зʼявляється у:

LeaderElectionConfiguration визначає конфігурацію клієнтів вибору лідера для компонентів, які можуть працювати з увімкненим вибором лідера.

ПолеОпис
leaderElect [Обовʼязкове]
bool

leaderElect увімкне клієнта вибору лідера для отримання лідерства перед виконанням основного циклу. Увімкніть це при запуску реплікованих компонентів для високої доступності.

leaseDuration [Обовʼязкове]
meta/v1.Duration

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

renewDeadline [Обовʼязкове]
meta/v1.Duration

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

retryPeriod [Обовʼязкове]
meta/v1.Duration

retryPeriod — це тривалість, яку клієнти повинні чекати між спробами отримання та оновлення лідерства. Це застосовно тільки тоді, коли вибір лідера увімкнено.

resourceLock [Обовʼязкове]
string

resourceLock вказує тип обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceName [Обовʼязкове]
string

resourceName вказує на імʼя обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceNamespace [Обовʼязкове]
string

resourceNamespace вказує на простір імен обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

DefaultPreemptionArgs

DefaultPreemptionArgs містить аргументи, які використовуються для налаштування втулка DefaultPreemption.

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		DefaultPreemptionArgs
minCandidateNodesPercentage [Обовʼязкове]
int32

MinCandidateNodesPercentage — це мінімальна кількість кандидатів для відбору при тестуванні виселення як відсоток від кількості вузлів. Має бути в межах [0, 100]. Стандартно дорівнює 10% від розміру кластера, якщо не вказано.

minCandidateNodesAbsolute [Обовʼязкове]
int32

MinCandidateNodesAbsolute — це абсолютна мінімальна кількість кандидатів для відбору. Ймовірна кількість кандидатів, які будуть перераховані для тестування виселення, розраховується за формулою:

numCandidates = max(numNodes * minCandidateNodesPercentage, minCandidateNodesAbsolute).

Ми говоримо "ймовірна", оскільки є й інші фактори, такі як порушення PDB, які впливають на кількість кандидатів для відбору. Має бути не менше 0 вузлів. Стандартно дорівнює 100 вузлам, якщо не вказано.

InterPodAffinityArgs

InterPodAffinityArgs містить аргументи, які використовуються для налаштування втулка InterPodAffinity.

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		InterPodAffinityArgs
hardPodAffinityWeight [Обовʼязкове]
int32

HardPodAffinityWeight — це вага оцінки для наявних Podʼів з відповідною жорсткою спорідненністю до вхідного Podʼа.

ignorePreferredTermsOfExistingPods [Обовʼязкове]
bool

IgnorePreferredTermsOfExistingPods налаштовує планувальник ігнорувати бажані правила спорідненості наявних Podʼів при оцінці кандидатів вузлів, якщо вхідний Pod не має спорідненості між Podʼами.

KubeSchedulerConfiguration

KubeSchedulerConfiguration налаштовує планувальник

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		KubeSchedulerConfiguration
parallelism [Обовʼязкове]
int32

Parallelism визначає кількість паралелізму в алгоритмах для планування Podʼів. Має бути більше 0. Стандартно — 16

leaderElection [Обовʼязкове]
LeaderElectionConfiguration

LeaderElection визначає конфігурацію клієнта виборів лідера.

clientConnection [Обовʼязкове]
ClientConnectionConfiguration

ClientConnection визначає файл kubeconfig і налаштування підключення клієнта для використання проксі-сервером при спілкуванні з apiserver.

DebuggingConfiguration [Обовʼязкове]
DebuggingConfiguration		(Члени DebuggingConfiguration вбудовані в цей тип.)

DebuggingConfiguration містить налаштування для функцій, повʼязаних із налагодженням. TODO: Ми можемо зробити це підструктурою як налагодження componentbaseconfigv1alpha1.DebuggingConfiguration

percentageOfNodesToScore [Обовʼязкове]
int32

PercentageOfNodesToScore — це відсоток усіх вузлів, які, як тільки будуть визнані придатними для запуску Podʼа, планувальник припиняє пошук інших придатних вузлів у кластері. Це допомагає покращити продуктивність планувальника. Планувальник завжди намагається знайти принаймні "minFeasibleNodesToFind" придатних вузлів незалежно від значення цього прапорця. Приклад: якщо розмір кластера 500 вузлів і значення цього прапорця 30, то планувальник припиняє пошук далі придатних вузлів, як тільки знайде 150 придатних. Коли значення дорівнює 0, стандартно буде оцінено відсоток вузлів (5%—50% залежно від розміру кластера). Він перекривається рівнем профілю PercentageOfNodesToScore.

podInitialBackoffSeconds [Обовʼязкове]
int64

PodInitialBackoffSeconds — це початкова фора для непридатних для планування Podʼів. Якщо вказано, він повинен бути більше 0. Якщо це значення нульове, буде використано стандартне значення (1s).

podMaxBackoffSeconds [Обовʼязкове]
int64

PodMaxBackoffSeconds — це максимальна фора для непридатних для планування Podʼів. Якщо вказано, він повинен бути більше podInitialBackoffSeconds. Якщо це значення нульове, буде використано стандартне значення (10s).

profiles [Обовʼязкове]
[]KubeSchedulerProfile

Profiles — це профілі планування, які підтримує kube-scheduler. Podʼи можуть вибрати, щоб їх планували за певним профілем, встановивши відповідну назву планувальника. Podʼи, які не вказують жодної назви планувальника, плануються за допомогою профілю "default-scheduler", якщо він присутній тут.

extenders [Обовʼязкове]
[]Extender

Extenders — це список розширень планувальника, кожне з яких містить значення, як спілкуватися з розширенням. Ці розширення використовуються всіма профілями планувальника.

delayCacheUntilActive [Обовʼязкове]
bool

DelayCacheUntilActive визначає, коли починати кешування. Якщо це true і вибори лідера увімкнені, планувальник чекатиме, щоб заповнити кеші інформаторів, поки не стане лідером. Це призведе до повільнішого перемикання з резервного на основний вузол із перевагою нижчого використання пам’яті під час очікування стати лідером. Стандартно — false.

NodeAffinityArgs

NodeAffinityArgs містить аргументи для налаштування втулка NodeAffinity.

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		NodeAffinityArgs
addedAffinity
core/v1.NodeAffinity

AddedAffinity застосовується до всіх Podʼів додатково до NodeAffinity, вказаного в PodSpec. Тобто вузли повинні відповідати AddedAffinity І .spec.NodeAffinity. AddedAffinity є станадртно порожнім (є збіг зі всіма вузлами). Коли використовується AddedAffinity, деякі Podʼи з вимогами щодо спорідненості, які збігаються з конкретним вузлом (наприклад, Podʼи Daemonset), можуть залишатися непридатними для планування.

NodeResourcesBalancedAllocationArgs

NodeResourcesBalancedAllocationArgs містить аргументи для налаштування втулка NodeResourcesBalancedAllocation.

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		NodeResourcesBalancedAllocationArgs
resources [Обовʼязково]
[]ResourceSpec

Ресурси, якими потрібно керувати, стандартно: "cpu" та "memory", якщо не вказано інше.

NodeResourcesFitArgs

NodeResourcesFitArgs містить аргументи для налаштування втулка NodeResourcesFit.

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		NodeResourcesFitArgs
ignoredResources [Обовʼязково]
[]string

IgnoredResources — список ресурсів, які фільтр NodeResources повинен ігнорувати. Це не застосовується до оцінювання.

ignoredResourceGroups [Обовʼязково]
[]string

IgnoredResourceGroups визначає список груп ресурсів, які фільтр NodeResources повинен ігнорувати. наприклад, якщо група - ["example.com"], вона ігноруватиме всі імена ресурсів, які починаються з "example.com", такі як "example.com/aaa" і "example.com/bbb". Імʼя групи ресурсів не може містити '/'. Це не застосовується до оцінювання.

scoringStrategy [Обовʼязково]
ScoringStrategy

ScoringStrategy вибирає стратегію оцінювання ресурсів вузлів. Стандартно використовується стратегія LeastAllocated з рівною вагою "cpu" та "memory".

PodTopologySpreadArgs

PodTopologySpreadArgs містить аргументи для налаштування втулка PodTopologySpread.

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		PodTopologySpreadArgs
defaultConstraints
[]core/v1.TopologySpreadConstraint

DefaultConstraints визначає обмеження на розподіл топології, які будуть застосовані до Podʼів, що не мають визначених обмежень у pod.spec.topologySpreadConstraints. .defaultConstraints[*].labelSelectors повинні бути порожніми, оскільки вони виводяться з приналежності Podʼа до Services, ReplicationControllers, ReplicaSets або StatefulSets. Якщо не порожньо, .defaultingType має бути "List".

defaultingType
PodTopologySpreadConstraintsDefaulting

DefaultingType визначає, як виводяться .defaultConstraints. Може бути одним з "System" або "List".

  • "System": Використовувати визначені kubernetes обмеження, які розподіляють Podʼи серед вузлів і зон.
  • "List": Використовувати обмеження, визначені в .defaultConstraints.

Стандартно "System".

VolumeBindingArgs

VolumeBindingArgs містить аргументи для налаштування втулка VolumeBinding.

ПолеОпис
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		VolumeBindingArgs
bindTimeoutSeconds [Обовʼязкове]
int64

BindTimeoutSeconds — це тайм-аут в секундах у операції привʼязки томів. Значення повинно бути невідʼємним цілим числом. Значення нуль означає, що немає очікування. Якщо це значення не вказано, буде використано стандартне значення (600).

shape
[]UtilizationShapePoint

Shape вказує точки, що визначають форму функції оцінки, яка використовується для оцінки вузлів на основі використання статично наданих PV. Використання розраховується шляхом поділу загального запитаного обсягу сховища Podʼа на загальну ємність доступних PV на кожному вузлі. Кожна точка містить використання (у діапазоні від 0 до 100) та відповідну оцінку (у діапазоні від 0 до 10). Ви можете налаштувати пріоритет, вказуючи різні оцінки для різних рівнів використання. Стандартні точки Shape:

  1. 0 для 0 використання
  2. 10 для 100 використання. Всі точки повинні бути відсортовані у зростаючому порядку за використанням.

Extender

Зʼявляється в:

Extender містить параметри, що використовуються для звʼязку з розширювачем. Якщо дієслово не вказано/пусте, вважається, що розширювач вирішів не надавати це розширення.

ПолеОпис
urlPrefix [Обовʼязкове]
string

URLPrefix за яким доступний розширювач

filterVerb [Обовʼязкове]
string

Дієслово для виклику фільтрації, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику фільтрації розширювача.

preemptVerb [Обовʼязкове]
string

Дієслово для виклику витіснення, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику витіснення розширювача.

prioritizeVerb [Обовʼязкове]
string

Дієслово для виклику пріоритезації, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику пріоритезації розширювача.

weight [Обовʼязкове]
int64

Числовий множник для оцінок вузлів, які генерує виклик пріоритезації. Вага повинна бути додатним цілим числом

bindVerb [Обовʼязкове]
string

Дієслово для виклику привʼязки, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику привʼязки розширювача. Якщо цей метод реалізовано розширювачем, це відповідальність розширювача привʼязати Pod до apiserver. Тільки один розширювач може реалізовувати цю функцію.

enableHTTPS [Обовʼязкове]
bool

EnableHTTPS вказує, чи слід використовувати https для звʼязку з розширювачем

tlsConfig [Обовʼязкове]
ExtenderTLSConfig

TLSConfig вказує налаштування транспортного рівня безпеки

httpTimeout [Обовʼязкове]
meta/v1.Duration

HTTPTimeout вказує тривалість тайм-ауту для виклику розширювача. Тайм-аут фільтрації призводить до невдалої спроби планування Podʼа. Тайм-аут пріоритезації ігнорується, пріоритети k8s/інших розширювачів використовуються для вибору вузла.

nodeCacheCapable [Обовʼязкове]
bool

NodeCacheCapable вказує, що розширювач здатний кешувати інформацію про вузли, отже, планувальник повинен надсилати лише мінімальну інформацію про придатні вузли, припускаючи, що розширювач вже кешував повні дані про всі вузли в кластері

managedResources
[]ExtenderManagedResource

ManagedResources — це список розширених ресурсів, що керуються цим розширювачем.

  • Pod буде надіслано до розширювача на етапах фільтрації, пріоритезації та привʼязки (якщо розширювач є звʼязувальним) тільки якщо Pod запитує принаймні один з розширених ресурсів у цьому списку. Якщо список порожній або не вказаний, всі Podʼи будуть надіслані до цього розширювача.
  • Якщо IgnoredByScheduler встановлено в true для ресурсу, kube-scheduler буде пропускати перевірку ресурсу в предикатах.
ignorable [Обовʼязкове]
bool

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

ExtenderManagedResource

Зʼявляється в:

ExtenderManagedResource описує аргументи розширених ресурсів, якими керує розширювач.

ПолеОпис
name [Обовʼязкове]
string

Назва розширеного ресурсу.

ignoredByScheduler [Обовʼязкове]
bool

IgnoredByScheduler вказує, чи слід kube-scheduler ігнорувати цей ресурс при застосуванні предикатів.

ExtenderTLSConfig

Зʼявляється в:

ExtenderTLSConfig містить налаштування для увімкнення TLS з розширювачем

ПолеОпис
insecure [Обовʼязкове]
bool

Сервер повинен бути доступний без перевірки сертифікату TLS. Тільки для тестування.

serverName [Обовʼязкове]
string

ServerName передається серверу для SNI та використовується в клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, яке використовується для звʼязку з сервером.

certFile [Обовʼязкове]
string

Сервер вимагає автентифікацію клієнтського сертифікату TLS

keyFile [Обовʼязкове]
string

Сервер вимагає автентифікацію клієнтського сертифікату TLS

caFile [Обовʼязкове]
string

Довірені кореневі сертифікати для сервера

certData [Обовʼязкове]
[]byte

CertData містить PEM-кодовані байти (зазвичай зчитуються з файлу клієнтського сертифіката). CertData має пріоритет над CertFile

keyData [Обовʼязкове]
[]byte

KeyData містить PEM-кодовані байти (зазвичай зчитуються з файлу ключа клієнтського сертифіката). KeyData має пріоритет над KeyFile

caData [Обовʼязкове]
[]byte

CAData містить PEM-кодовані байти (зазвичай зчитуються з файлу з кореневими сертифікатами). CAData має пріоритет над CAFile

KubeSchedulerProfile

Зʼявляється в:

KubeSchedulerProfile є профілем планувальника.

ПолеОпис
schedulerName [Обовʼязкове]
string

SchedulerName є імʼям планувальника, асоційованого з цим профілем. Якщо SchedulerName відповідає значенню "spec.schedulerName" Podʼа, то Pod буде плануватися з цим профілем.

percentageOfNodesToScore [Обовʼязкове]
int32

PercentageOfNodesToScore є відсотком усіх вузлів, після знаходження яких, планувальник припиняє пошук більш придатних вузлів у кластері для запуску Podʼа. Це допомагає покращити продуктивність планувальника. Планувальник завжди намагається знайти принаймні "minFeasibleNodesToFind" придатних вузлів незалежно від значення цього прапорця. Наприклад, якщо розмір кластера становить 500 вузлів і значення цього прапорця становить 30, то планувальник припиняє пошук далі, як тільки знаходить 150 придатних вузлів. Коли значення 0, стандартно буде оцінено відсоток (5%–50% в залежності від розміру кластера) вузлів. Це матиме перевагу перед глобальним PercentageOfNodesToScore. Якщо це пусто, буде використано глобальний PercentageOfNodesToScore.

plugins [Обовʼязкове]
Plugins

Plugins визначають набір втулків, які мають бути увімкнені або вимкнені. Увімкнені втулки — це ті, які мають бути увімкнені додатково до стандартних втулків. Вимкнені втулки — це будь-які зі стандартних втулків, які мають бути вимкнені. Коли жоден увімкнений або вимкнений втулок не зазначений для точки розширення, будуть використані стандартні втулки для цієї точки розширення, якщо такі є. Якщо зазначено втулок QueueSort, то той самий втулок QueueSort та PluginConfig повинні бути зазначені для всіх профілів.

pluginConfig [Обовʼязкове]
[]PluginConfig

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

Plugin

Зʼявляється в:

Plugin визначає імʼя втулка та його вагу, якщо це застосовується. Вага використовується лише для втулків типу Score.

ПолеОпис
name [Обовʼязкове]
string

Name визначає імʼя втулка

weight [Обовʼязкове]
int32

Weight визначає вагу втулка, використовується лише для втулків типу Score.

PluginConfig

Зʼявляється в:

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

ПолеОпис
name [Обовʼязкове]
string

Name визначає імʼя втулка, що конфігурується

args [Обовʼязкове]
k8s.io/apimachinery/pkg/runtime.RawExtension

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

PluginSet

Зʼявляється в:

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

ПолеОпис
enabled [Обовʼязкове]
[]Plugin

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

disabled [Обовʼязкове]
[]Plugin

Disabled визначає стандартні втулки, які повинні бути вимкнені. Коли всі стандартні втулки потрібно вимкнути, слід надати масив, що містить лише один символ "*".

Plugins

Зʼявляється в:

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

ПолеОпис
preEnqueue [Обовʼязкове]
PluginSet

PreEnqueue ` це список втулків, які повинні бути викликані перед додаванням Podʼів у чергу планування.

queueSort [Обовʼязкове]
PluginSet

QueueSort — це список втулків, які повинні бути викликані під час сортування Podʼів у черзі планування.

preFilter [Обовʼязкове]
PluginSet

PreFilter — це список втулків, які повинні бути викликані на точці розширення "PreFilter" фреймворку планування.

filter [Обовʼязкове]
PluginSet

Filter — це список втулків, які повинні бути викликані при фільтрації вузлів, що не можуть запустити Pod.

postFilter [Обовʼязкове]
PluginSet

PostFilter — це список втулків, які викликаються після фази фільтрації, але лише коли для Podʼа не були знайдені підходящі вузли.

preScore [Обовʼязкове]
PluginSet

PreScore — це список втулків, які викликаються перед оцінюванням.

score [Обовʼязкове]
PluginSet

Score — це список втулків, які повинні бути викликані при ранжуванні вузлів, які пройшли фазу фільтрації.

reserve [Обовʼязкове]
PluginSet

Reserve — це список втулків, які викликаються при резервуванні/анулюванні резервування ресурсів після того, як вузол призначений для запуску Podʼа.

permit [Обовʼязкове]
PluginSet

Permit — це список втулків, які контролюють привʼязування Podʼа. Ці втулки можуть запобігти або затримати привʼязування Podʼа.

preBind [Обовʼязкове]
PluginSet

PreBind — це список втулків, які повинні бути викликані перед привʼязуванням Podʼа.

bind [Обовʼязкове]
PluginSet

Bind — це список втулків, які повинні бути викликані на точці розширення "Bind" фреймворку планування. Планувальник викликає ці втулки по порядку. Планувальник пропускає решту цих втулків, як тільки один з них повертає успіх.

postBind [Обовʼязкове]
PluginSet

PostBind — це список втулків, які повинні бути викликані після успішного привʼязування Podʼа.

multiPoint [Обовʼязкове]
PluginSet

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

Що стосується пріоритету, конфігурація втулків дотримується цієї основної ієрархії

  1. Специфічні точки розширення
  2. Явно сконфігуровані втулки MultiPoint
  3. Набір стандартних втулків, як втулки MultiPoint. Це означає, що втулок з вищим пріоритетом буде виконуватися першим і перезаписувати будь-які налаштування всередині MultiPoint. Явно сконфігуровані втулки користувача також мають вищий пріоритет над стандартними втулками. В межах цієї ієрархії, параметр Enabled має вищий пріоритет над Disabled. Наприклад, якщо втулок зазначено як в multiPoint.Enabled та multiPoint.Disabled, втулок буде активовано. Подібним чином, включення multiPoint.Disabled = '*' і multiPoint.Enabled = pluginA все ще зареєструє цей конкретний втулок через MultiPoint. Це слідує тій же поведінці, що й у всіх інших конфігураціях точок розширення.

PodTopologySpreadConstraintsDefaulting

(Аліас для string)

Зʼявляється в:

PodTopologySpreadConstraintsDefaulting визначає, як встановлювати стандартне значення для втулка PodTopologySpread.

RequestedToCapacityRatioParam

Зʼявляється в:

RequestedToCapacityRatioParam визначає параметри RequestedToCapacityRatio.

ПолеОпис
shape [Обовʼязково]
[]UtilizationShapePoint

Shape є списком точок, що визначають форму функції оцінки.

ResourceSpec

Зʼявляється в:

ResourceSpec представляє один ресурс.

ПолеОпис
name [Обовʼязково]
string

Назва ресурсу.

weight [Обовʼязково]
int64

Вага ресурсу.

ScoringStrategy

Зʼявляється в:

ScoringStrategy визначає ScoringStrategyType для втулка ресурсів вузла.

ПолеОпис
type [Обовʼязково]
ScoringStrategyType

Тип обирає стратегію для виконання.

resources [Обовʼязково]
[]ResourceSpec

Ресурси, які слід враховувати при оцінюванні. Стандартний набір ресурсів включає "cpu" та "memory" з однаковою вагою. Дозволені ваги від 1 до 100. Стандартна вага дорівнює 1, якщо не вказана або явно встановлена в 0.

requestedToCapacityRatio [Обовʼязково]
RequestedToCapacityRatioParam

Аргументи, специфічні для стратегії RequestedToCapacityRatio.

ScoringStrategyType

(Аліас string)

Зʼявляється в:

ScoringStrategyType визначає тип стратегії оцінювання, яка використовується у втулку NodeResourcesFit.

UtilizationShapePoint

Зʼявляється в:

UtilizationShapePoint представляє окрему точку функції пріоритету.

ПолеОпис
utilization [Обовʼязково]
int32

Utilization (вісь x). Дійсні значення від 0 до 100. Повністю використаний вузол відповідає 100.

score [Обовʼязково]
int32

Оцінка, присвоєна даній утилізації (вісь y). Дійсні значення від 0 до 10.

14.13 - kubeadm Configuration (v1beta3)

Огляд

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

Список змін з версії v1beta2:

  • Видалено застаріле поле "ClusterConfiguration.useHyperKubeImage". Kubeadm більше не підтримує образ hyperkube.
  • Поле "ClusterConfiguration.dns.type" було видалено, оскільки CoreDNS є єдиним типом DNS-сервера, який підтримується kubeadm.
  • Додано теги "datapolicy" до полів, які містять секрети. Це призведе до того, що значення полів буде пропущено, коли структури API буде надруковано за допомогою klog.
  • Додано "InitConfiguration.skipPhases", "JoinConfiguration.SkipPhases", щоб дозволити пропустити список фаз під час виконання команд kubeadm init/join.
  • Додано "InitConfiguration.nodeRegistration.imagePullPolicy" та "JoinConfiguration.nodeRegistration.imagePullPolicy", щоб дозволити вказати політику отримання образів під час kubeadm "init" та "join". Значення має бути одним з "Always", "Never" або "IfNotPresent". "IfNotPresent" — це стандартне значення, яке використовувалося до цього оновлення.
  • Додано "InitConfiguration.patches.directory", "JoinConfiguration.patches.directory", щоб дозволити користувачеві конфігурувати теку, з якої буде братися патч для компонентів, розгорнутих за допомогою kubeadm.
  • Перенесено API BootstrapToken* та повʼязані з ним утиліти з групи API "kubeadm" до нової групи "bootstraptoken". API kubeadm версії v1beta3 більше не містить структур BootstrapToken*.

Міграція зі старих версій конфігурації kubeadm

  • kubeadm v1.15.x і новіше можна використовувати для міграції з v1beta1 на v1beta2.
  • kubeadm v1.22.x і новіші більше не підтримують v1beta1 і старіші API, але можуть бути використані для міграції з v1beta2 на v1beta3.
  • kubeadm v1.27.x і новіші більше не підтримують v1beta2 і старіші API.

Основи

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

Конфігураційний файл kubeadm може містити декілька типів конфігурацій, розділених трьома тире (---).

kubeadm підтримує наступні типи конфігурацій:

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration

apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration

Щоб вивести стандартні значення для дій "init" і "join", скористайтеся наступними командами:

kubeadm config print init-defaults
kubeadm config print join-defaults

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

Якщо деякі типи конфігурацій не передбачено або передбачено лише частково, kubeadm використовуватиме стандартні значення; стандартно kubeadm також забезпечує узгодженість значень між компонентами, коли це необхідно (наприклад, прапорець --cluster-cidr на менеджері контролерів та clusterCIDR у kube-proxy).

Користувачам завжди дозволено перевизначати стандартні значення, за винятком невеликої підгрупи налаштувань, що мають стосунок до безпеки (наприклад, примусово вмикати режим авторизації Node і RBAC на api-сервері).

Якщо користувач надасть типи конфігурації, які не очікуються для дії, яку ви виконуєте, kubeadm проігнорує ці типи і видасть попередження.

Типи конфігурації Kubeadm init

При виконанні kubeadm init з опцією --config можуть бути використані наступні типи конфігурацій: InitConfiguration, ClusterConfiguration, KubeProxyConfiguration, KubeletConfiguration, але тільки один з них поміж InitConfiguration та ClusterConfiguration є обовʼязковим.

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
bootstrapTokens:
  ...
nodeRegistration:
  ...

Тип InitConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm init є конфігурація токена завантажувача та всі параметри, специфічні для вузла, на якому виконується kubeadm, включно з ними:

  • NodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • LocalAPIEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі; використовуйте його, наприклад, для налаштування адреси оголошення сервера API.
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  ...
etcd:
  ...
apiServer:
  extraArgs:
    ...
  extraVolumes:
    ...
...

Тип InitConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm init є конфігурація токена завантажувача та всі параметри, специфічні для вузла, на якому виконується kubeadm, включно з ними:

  • NodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • LocalAPIEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі; використовуйте його, наприклад, для налаштування адреси оголошення сервера API.
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  ...
etcd:
  ...
apiServer:
  extraArgs:
    ...
  extraVolumes:
    ...
...

Тип ClusterConfiguration слід використовувати для налаштування параметрів всього кластера, включаючи налаштування для:

  • networking, що містить конфігурацію мережевої топології кластера; використовуйте їх, наприклад, для налаштування підмережі Pod або підмережі сервісів.
  • etcd: використовуйте для налаштування локального etcd або для налаштування сервера API для використання зовнішнього кластера etcd.
  • конфігурації kube-apiserver, kube-scheduler, kube-controller-manager; використовуйте для налаштування компонентів панелі управління шляхом додавання індивідуальних налаштувань або перевизначення стандартних налаштувань kubeadm.
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
  ...

Тип KubeProxyConfiguration слід використовувати для зміни конфігурації, що передається екземплярам kube-proxy, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні значення.

Офіційну документацію про kube-proxy можна знайти на https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ або https://pkg.go.dev/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
  ...

Тип KubeletConfiguration слід використовувати для зміни конфігурацій, які буде передано всім екземплярам kubelet, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні налаштування.

Офіційну документацію про kubelet див. на https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ або https://pkg.go.dev/k8s.io/kubelet/config/v1beta1#KubeletConfiguration.

Ось повністю заповнений приклад одного YAML-файлу, що містить декілька типів конфігурації для використання під час запуску kubeadm init.

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
bootstrapTokens:
  - token: "9a08jv.c0izixklcxtmnze7"
    description: "kubeadm bootstrap token"
    ttl: "24h"
  - token: "783bde.3f89s0fje9f38fhf"
    description: "another bootstrap token"
    usages:
      - authentication
      - signing
    groups:
      - system:bootstrappers:kubeadm:default-node-token
nodeRegistration:
  name: "ec2-10-100-0-1"
  criSocket: "/var/run/dockershim.sock"
  taints:
    - key: "kubeadmNode"
      value: "someValue"
      effect: "NoSchedule"
  kubeletExtraArgs:
    v: 4
  ignorePreflightErrors:
    - IsPrivilegedUser
  imagePullPolicy: "IfNotPresent"
localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443
certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
skipPhases:
  - addon/kube-proxy
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
  # локальний або зовнішній etcd
  local:
    imageRepository: "registry.k8s.io"
    imageTag: "3.2.24"
    dataDir: "/var/lib/etcd"
    extraArgs:
      listen-client-urls: "http://10.100.0.1:2379"
    serverCertSANs:
      -  "ec2-10-100-0-1.compute-1.amazonaws.com"
    peerCertSANs:
      - "10.100.0.1"
  # external:
    # endpoints:
    # - "10.100.0.1:2379"
    # - "10.100.0.2:2379"
    # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"
networking:
  serviceSubnet: "10.96.0.0/16"
  podSubnet: "10.244.0.0/24"
  dnsDomain: "cluster.local"
kubernetesVersion: "v1.21.0"
controlPlaneEndpoint: "10.100.0.1:6443"
apiServer:
  extraArgs:
    authorization-mode: "Node,RBAC"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
  certSANs:
    - "10.100.1.1"
    - "ec2-10-100-0-1.compute-1.amazonaws.com"
  timeoutForControlPlane: 4m0s
controllerManager:
  extraArgs:
    "node-cidr-mask-size": "20"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
scheduler:
  extraArgs:
    bind-address: "10.100.0.1"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
certificatesDir: "/etc/kubernetes/pki"
imageRepository: "registry.k8s.io"
clusterName: "example-cluster"
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# параметри kubelet вказуються тут
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
# параметри kube-proxy вказуються тут

Типи конфігурації Kubeadm join

При виконанні kubeadm join з опцією --config слід вказати тип JoinConfiguration.

apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
  ...

Тип JoinConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm join є метод виявлення, що використовується для доступу до інформації про кластер, а також всі налаштування, специфічні для вузла, на якому виконується kubeadm, включно з:

  • nodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • apiEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі.

Типи ресурсів

BootstrapToken

Зʼявляється в:

BootstrapToken описує один bootstrap токен, збережений як Secret у кластері

ПолеОпис
token [Обовʼязково]
BootstrapTokenString

token використовується для встановлення двосторонньої довіри між вузлами та панелями управління. Використовується для приєднання вузлів до кластера.

description
string

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

ttl
meta/v1.Duration

ttl визначає час життя цього токена. Стандартно — 24h. expires та ttl взаємовиключні.

expires
meta/v1.Time

expires вказує на мітку часу, коли цей токен закінчується. Стандартно встановлюється динамічно під час виконання на основі ttl. expires та ttl взаємовиключні.

usages
[]string

usages описує способи, якими цей токен може бути використаний. Стандартно може бути використаний для встановлення двосторонньої довіри, але це можна змінити тут.

groups
[]string

groups визначає додаткові групи, з якими цей токен буде автентифікуватися, якщо/коли використовуватиметься для автентифікації

BootstrapTokenString

Зʼявляється в:

BootstrapTokenString — це токен у форматі abcdef.abcdef0123456789, який використовується як для валідації практичності API-сервера з погляду вузла, що приєднується, так і як метод автентифікації вузла на етапі завантаження у фазі "kubeadm join". Цей токен є і повинен бути короткотривалим.

ПолеОпис
- [Обовʼязково]
string		Опис відсутній.
- [Обовʼязково]
string		Опис відсутній.

ClusterConfiguration

ClusterConfiguration містить конфігурацію для всього кластера kubeadm.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta3
kind
string		ClusterConfiguration
etcd
Etcd

etcd містить конфігурацію для etcd.

networking
Networking

networking містить конфігурацію для мережевої топології кластера.

kubernetesVersion
string

kubernetesVersion — це цільова версія панелі управління.

controlPlaneEndpoint
string

controlPlaneEndpoint встановлює стабільну IP-адресу або DNS-імʼя для панелі управління. Це може бути дійсна IP-адреса або субдомен RFC-1123 DNS з додатковим TCP портом. Якщо controlPlaneEndpoint не вказано, використовуються advertiseAddress + bindPort; якщо controlPlaneEndpoint вказано без TCP порту, використовується bindPort. Можливі варіанти використання:

  • У кластері з більше ніж одним екземпляром панелі управління це поле повинно бути присвоєно адресу зовнішнього балансувальника навантаження перед екземплярами панелі управління.
  • У середовищах з обовʼязковим перерозподілом вузлів controlPlaneEndpoint може бути використаний для призначення стабільного DNS панелі управління.
apiServer
APIServer

apiServer містить додаткові налаштування для API сервера.

controllerManager
ControlPlaneComponent

controllerManager містить додаткові налаштування для менеджера контролерів.

scheduler
ControlPlaneComponent

scheduler містить додаткові налаштування для планувальника.

dns
DNS

dns визначає опції для DNS надбудови, встановленої в кластері.

certificatesDir
string

certificatesDir вказує, де зберігати або шукати всі необхідні сертифікати.

imageRepository
string

imageRepository встановлює реєстр контейнерів для завантаження образів. Якщо порожнє, стандартно буде використано registry.k8s.io. Якщо версія Kubernetes є CI-збіркою (версія Kubernetes починається з ci/), gcr.io/k8s-staging-ci-images буде використовуватись для компонентів панелі управління та для kube-proxy, тоді як registry.k8s.io буде використано для всіх інших образів.

featureGates
map[string]bool

featureGates містить функціональні можливості, увімкнені користувачем.

clusterName
string

Назва кластера.

InitConfiguration

InitConfiguration містить список елементів, специфічних для "kubeadm init"-тільки під час виконання. Тільки інформація kubeadm init. Ці поля використовуються виключно під час першого запуску kubeadm init. Після цього інформація в цих полях НЕ завантажується в kubeadm-config ConfigMap, який використовується, наприклад, під час kubeadm upgrade. Ці поля мають бути порожніми.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta3
kind
string		InitConfiguration
bootstrapTokens
[]BootstrapToken

bootstrapTokens використовується під час kubeadm init і описує набір Bootstrap Tokens для створення. Ця інформація НЕ завантажується в kubeadm cluster configmap, частково через її конфіденційний характер

nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

localAPIEndpoint
APIEndpoint

localAPIEndpoint представляє точку доступу екземпляра API сервера, яка розгорнута на цьому вузлі панелі управління. У HA-налаштуваннях це відрізняється від ClusterConfiguration.controlPlaneEndpoint в тому сенсі, що controlPlaneEndpoint є глобальною точкою доступу для кластера, яка потім розподіляє запити на кожен окремий API сервер. Цей конфігураційний обʼєкт дозволяє налаштувати, яку IP-адресу/DNS-імʼя та порт локальний API сервер оголошує як доступні. Стандартно kubeadm намагається автоматично визначити типову IP-адресу інтерфейсу та використовувати її, але в разі невдачі ви можете встановити бажане значення тут.

certificateKey
string

certificateKey встановлює ключ, яким сертифікати та ключі шифруються перед завантаженням у Secret в кластері під час фази uploadcerts init. Ключ сертифіката є кодуванням шістнадцяткового рядка, який є AES ключем розміром 32 байти.

skipPhases
[]string

skipPhases — це список фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm init --help. Прапорець "--skip-phases" має пріоритет перед цим полем.

patches
Patches

patches містить опції, повʼязані з застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm під час kubeadm init.

JoinConfiguration

JoinConfiguration містить елементи, що описують певний вузол.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta3
kind
string		JoinConfiguration
nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

caCertPath
string

caCertPath — це шлях до SSL центра сертифікації, що використовується для захисту звʼязку між вузлом та панеллю управління. Стандартно — /etc/kubernetes/pki/ca.crt.

discovery [Обовʼязкове]
Discovery

discovery визначає параметри, які kubelet використовує під час процесу TLS старту.

controlPlane
JoinControlPlane

controlPlane визначає додатковий екземпляр панелі управління, який буде розгорнутий на приєднаному вузлі. Якщо nil, додатковий екземпляр панелі управління не буде розгорнуто.

skipPhases
[]string

skipPhases — це список фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm join --help. Прапорець --skip-phases має пріоритет перед цим полем.

patches
Patches

patches містить параметри, повʼязані із застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm під час kubeadm join.

APIEndpoint

Зʼявляється в:

Структура APIEndpoint містить елементи екземпляра API сервера, розгорнутого на вузлі.

ПолеОпис
advertiseAddress
string

advertiseAddress встановлює IP-адресу, яку буде оголошувати API сервер.

bindPort
int32

bindPort встановлює безпечний порт, до якого буде привʼязаний API сервер. Стандартно — 6443.

APIServer

Зʼявляється в:

APIServer містить налаштування, необхідні для розгортання API сервера в кластері.

ПолеОпис
ControlPlaneComponent [Обовʼязкове]
ControlPlaneComponent		(Члени ControlPlaneComponent вбудовані в цей тип.) Опис відсутній.
certSANs
[]string

certSANs встановлює додаткові альтернативні імена субʼєктів (SANs) для сертифіката підпису API сервера.

timeoutForControlPlane
meta/v1.Duration

timeoutForControlPlane контролює тайм-аут, який ми очікуємо для появи API сервера.

BootstrapTokenDiscovery

Зʼявляється в:

BootstrapTokenDiscovery використовується для налаштування параметрів виявлення на основі маркера початкового завантаження.

ПолеОпис
token [Обовʼязкове]
string

token — це маркер, що використовується для перевірки інформації про кластер, отриманої з панелі управління.

apiServerEndpoint
string

apiServerEndpoint — це IP-адреса або доменне імʼя до API сервера, з якого буде отримана інформація.

caCertHashes
[]string

caCertHashes вказує набір публічних ключів для перевірки при використанні виявлення на основі маркера. Кореневий сертифікат CA, знайдений під час виявлення, повинен відповідати одному з цих значень. Зазначення порожнього набору відключає закріплення кореневого сертифіката CA, що може бути небезпечним. Кожен хеш зазначається у форматі <type>:<value>, де єдиним підтримуваним типом на даний момент є "sha256". Це хеш SHA-256 у шістнадцятковому форматі, який обчислюється за допомогою обʼєкта Subject Public Key Info (SPKI) у DER-кодованому форматі ASN.1. Ці хеші можна обчислити за допомогою, наприклад, OpenSSL.

unsafeSkipCAVerification
bool

unsafeSkipCAVerification дозволяє виявлення на основі маркера без перевірки CA за допомогою caCertHashes. Це може послабити безпеку kubeadm, оскільки інші вузли можуть видавати себе за панель управління.

ControlPlaneComponent

Зʼявляється в:

ControlPlaneComponent містить налаштування, спільні для компонентів панелі управління кластера.

ПолеОпис
extraArgs
map[string]string

extraArgs — це додатковий набір параметрів, що передаються компоненту панелі кправління. Ключ у цьому map — це імʼя параметра, як воно зʼявляється в командному рядку, без попереднього дефіса(ів).

extraVolumes
[]HostPathMount

extraVolumes — це додатковий набір хост-томів, змонтованих до компоненту панелі управління.

DNS

Зʼявляється в:

DNS визначає надбудовою DNS, що має використовуватися в кластері.

ПолеОпис
ImageMeta [Обовʼязкове]
ImageMeta		(Члени ImageMeta вбудовані в цей тип.)

imageMeta дозволяє налаштувати образ, яке використовується для компонента DNS.

Discovery

Зʼявляється в:

Discovery визначає параметри для kubelet, які використовуються під час процесу TLS Bootstrap.

ПолеОпис
bootstrapToken
BootstrapTokenDiscovery

bootstrapToken використовується для налаштування параметрів на основі токена bootstrap. bootstrapToken і file є взаємовиключними.

file
FileDiscovery

file використовується для вказівки файлу або URL-адреси до файлу kubeconfig, з якого завантажується інформація про кластер. bootstrapToken і file є взаємовиключними.

tlsBootstrapToken
string

tlsBootstrapToken є токеном, який використовується для TLS bootstrapping. Якщо bootstrapToken встановлено, це поле стандартно встановлюється на .bootstrapToken.token, але може бути перевизначено. Якщо встановлено file, це поле має бути встановлено у випадку, якщо KubeConfigFile не містить іншої інформації для автентифікації.

timeout
meta/v1.Duration

timeout змінює час очікування під час виявлення.

Etcd

Зʼявляється в:

Etcd містить елементи, що описують конфігурацію Etcd.

ПолеОпис
local
LocalEtcd

local надає параметри конфігурації для налаштування локального екземпляра etcd. local і external є взаємовиключними.

external
ExternalEtcd

external описує, як підключитися до зовнішнього кластера etcd. local і external є взаємовиключними.

ExternalEtcd

Зʼявляється в:

ExternalEtcd описує зовнішній кластер etcd. Kubeadm не має знань про знаходження файлів сертифікатів, і вони повинні бути надані.

ПолеОпис
endpoints [Обовʼязково]
[]string

endpoints містить список учасників etcd.

caFile [Обовʼязково]
string

caFile є файлом сертифіката SSL Certificate Authority (CA), який використовується для захисту звʼязку etcd. Обовʼязковий, якщо використовується TLS-зʼєднання.

certFile [Обовʼязково]
string

certFile є файлом сертифіката SSL, який використовується для захисту звʼязку etcd. Обовʼязковий, якщо використовується TLS-зʼєднання.

keyFile [Обовʼязково]
string

keyFile є файлом ключа SSL, який використовується для захисту звʼязку etcd. Обовʼязковий, якщо використовується TLS-зʼєднання.

FileDiscovery

Зʼявляється в:

FileDiscovery використовується для вказання файлу або URL до файлу kubeconfig, з якого завантажується інформація про кластер.

ПолеОпис
kubeConfigPath [Обовʼязково]
string

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

HostPathMount

Зʼявляється в:

HostPathMount містить елементи, що описують томи, які монтуються з хоста.

ПолеОпис
name [Обовʼязково]
string

name — це імʼя тому всередині шаблону Pod.

hostPath [Обовʼязково]
string

hostPath — це шлях на хості, який буде змонтовано всередині Pod.

mountPath [Обовʼязково]
string

mountPath — це шлях всередині Pod, куди буде змонтовано hostPath.

readOnly
bool

readOnly контролює доступ на запис до тому.

pathType
core/v1.HostPathType

pathType — це тип hostPath.

ImageMeta

Зʼявляється в:

ImageMeta дозволяє налаштувати образи, що використовуються для компонентів, які не походять з процесу випуску Kubernetes/Kubernetes

ПолеОпис
imageRepository
string

imageRepository встановлює реєстр контейнерів, з якого будуть завантажені образи. Якщо не встановлено, буде використовуватися imageRepository, визначений у ClusterConfiguration.

imageTag
string

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

JoinControlPlane

Зʼявляється в:

JoinControlPlane містить елементи, що описують додатковий екземпляр панелі управління, який потрібно розгорнути на приєднаному вузлі.

ПолеОпис
localAPIEndpoint
APIEndpoint

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

certificateKey
string

certificateKey є ключем, який використовується для дешифрування сертифікатів після їх завантаження з секрету під час приєднання нового вузла панелі упралвіння. Відповідний ключ шифрування знаходиться в InitConfiguration. Ключ сертифіката є рядком у шістнадцятковому кодуванні, що є AES-ключем розміром 32 байти.

LocalEtcd

Зʼявляється в:

LocalEtcd описує, що kubeadm має запускати кластер etcd локально.

ПолеОпис
ImageMeta [Обовʼязкове]
ImageMeta		(Члени ImageMeta інтегровані в цей тип.)

ImageMeta дозволяє налаштувати контейнер, що використовується для etcd.

dataDir [Обовʼязкове]
string

dataDir — це тека, в якій etcd розміщуватиме свої дані. Стандартно використовується "/var/lib/etcd".

extraArgs
map[string]string

extraArgs — додаткові аргументи, що передаються бінарному файлу etcd при його запуску всередині статичного Pod. Ключ у цьому map є імʼям прапорця, як він зʼявляється на командному рядку, але без дефісів на початку.

serverCertSANs
[]string

serverCertSANs задає додаткові Subject Alternative Names (SANs) для сертифіката підпису сервера etcd.

peerCertSANs
[]string

peerCertSANs задає додаткові Subject Alternative Names (SANs) для сертифіката підпису peer etcd.

Networking

Зʼявляється в:

Networking містить елементи, що описують конфігурацію мережі кластера.

ПолеОпис
serviceSubnet
string

serviceSubnet — це підмережа, що використовується Kubernetes Services. Стандртно — "10.96.0.0/12".

podSubnet
string

podSubnet — це підмережа, що використовується Pod.

dnsDomain
string

dnsDomain — це DNS домен, що використовується Kubernetes Services. Стандартно — "cluster.local".

NodeRegistrationOptions

Зʼявляється в:

NodeRegistrationOptions містить поля, що стосуються реєстрації нової панелі управління або вузла в кластері, як через kubeadm init, так і через kubeadm join.

ПолеОпис
name
string

name — це поле .metadata.name обʼєкта Node API, який буде створений в процесі kubeadm init або kubeadm join. Це поле також використовується в полі CommonName клієнтського сертифікату kubelet до API сервера. Стандартно буде використано імʼя хоста вузла, якщо не надано.

criSocket
string

criSocket використовується для отримання інформації про середовище виконання контейнерів. Ця інформація буде анотована до обʼєкта Node API для подальшого використання.

taints [Обовʼязково]
[]core/v1.Taint

taints вказує на taints, з якими обʼєкт Node API повинен бути зареєстрований. Якщо це поле не встановлено, тобто nil, воно буде стандартно з control-plane taint для вузлів control-plane. Якщо ви не хочете taint для вашого вузла control-plane, встановіть в це поле порожній список, тобто taints: [] у YAML файлі. Це поле використовується виключно для реєстрації вузлів.

kubeletExtraArgs
map[string]string

kubeletExtraArgs передає додаткові аргументи до kubelet. Аргументи тут передаються в командний рядок kubelet через файл середовища kubeadm, що створюється під час виконання, щоб kubelet міг його використовувати. Це переважає загальну базову конфігурацію в ConfigMap kubelet-config. Прапорці мають вищий пріоритет під час парсингу. Ці значення локальні та специфічні для вузла, на якому виконується kubeadm. Ключ у цьому словнику — це назва прапорці, як вона зʼявляється в командному рядку, але без початкових дефісів.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок перед запуском, які слід ігнорувати під час реєстрації поточного вузла, наприклад, IsPrevilegedUser,Swap. Значення all ігнорує помилки від усіх перевірок.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy вказує політику для витягування образів під час операцій kubeadm "init" та "join". Значення цього поля повинно бути одне з "Always", "IfNotPresent" або "Never". Якщо це поле не встановлено, kubeadm стандартно встановить його в "IfNotPresent", або витягне необхідні образи, якщо вони не присутні на хості.

Patches

Зʼявляється в:

Patches містить параметри, повʼязані з застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm.

ПолеОпис
directory
string

directory — це шлях до теки, що містить файли, названі "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" може бути одним з "strategic", "merge" або "json" та відповідати форматам патчів, підтримуваних kubectl. Стандартно "patchtype" — "strategic". "extension" повинна бути або "json", або "yaml". "suffix" — це необовʼязковий рядок, який може бути використаний для визначення, які патчі застосовуються першими за алфавітним порядком.

14.14 - kubeadm Configuration (v1beta4)

Огляд

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

Список змін з версії v1beta3:

  • TODO https://github.com/kubernetes/kubeadm/issues/2890
  • Підтримуйте власні змінні оточення у компонентах панелі управління у розділі ClusterConfiguration. Використовуйте apiServer.extraEnvs, controllerManager.extraEnvs, scheduler.extraEnvs, etcd.local.extraEnvs.
  • Тип API ResetConfiguration тепер підтримується у v1beta4. Користувачі можуть скинути конфігурацію вузла, передавши kubeadm reset файл --config.
  • режим dry-run тепер налаштовується у InitConfiguration та JoinConfiguration.
  • Замінено існуючі map додаткових аргументів типу рядок/рядок на структуровані додаткові аргументи, які підтримують дублікати. Зміни застосовано до ClusterConfiguration — apiServer.extraArgs, controllerManager.extraArgs, scheduler.extraArgs, etcd.local.extraArgs. Також до nodeRegistration.kubeletExtraArgs.
  • Додано ClusterConfiguration.encryptionAlgorithm, за допомогою якого можна задати алгоритм асиметричного шифрування, що використовується для ключів і сертифікатів цього кластера. Може бути один з "RSA-2048" (стандартно), "RSA-3072", "RSA-4096" або "ECDSA-P256".
  • Додано ClusterConfiguration.dns.disabled та ClusterConfiguration.proxy.disabled, за допомогою яких можна вимкнути надбудови CoreDNS та kube-proxy під час ініціалізації кластера. Якщо пропустити повʼязані з ними етапи під час створення кластера, ці ж поля буде встановлено у значення false.
  • Додано поле nodeRegistration.imagePullSerial у InitConfiguration та JoinConfiguration, за допомогою якого можна контролювати, чи kubeadm витягує образи послідовно або паралельно.
  • API kubeadm UpgradeConfiguration тепер підтримується у v1beta4 при передачі --config до команд kubeadm upgrade. Використання конфігурації компонентів для kubelet та kube-proxy, InitConfiguration та ClusterConfiguration є застарілим і буде проігноровано при передачі --config до команд upgrade.
  • Додано структуру Timeouts до InitConfiguration, JoinConfiguration, ResetConfiguration та UpgradeConfiguration, яку можна використовувати для налаштування різних тайм-аутів.
  • Додано поля certificateValidityPeriod та caCertificateValidityPeriod до ClusterConfiguration. Ці поля можна використовувати для контролю терміну дії сертифікатів, згенерованих kubeadm під час виконання таких підкоманд, як init, join, upgrade і certs. Стандартні значення залишаються 1 рік для сертифікатів без CA і 10 років для сертифікатів з CA. Лише сертифікати без CA можна поновлювати командою kubeadm certs renew.

Міграція зі старих версій конфігурації kubeadm

  • kubeadm v1.15.x і новіше можна використовувати для міграції з v1beta1 на v1beta2.
  • kubeadm v1.22.x і новіші більше не підтримують v1beta1 і старіші API, але можуть бути використані для міграції з v1beta2 на v1beta3.
  • kubeadm v1.27.x і новіші більше не підтримують v1beta2 і старіші API.
  • TODO: https://github.com/kubernetes/kubeadm/issues/2890 додати версію, яку можна використовувати для конвертації у v1beta4

Основи

Найкращим способом налаштування kubeadm є передача конфігураційного файлу у форматі YAML з опцією --config. Деякі з параметрів конфігурації, визначених у конфігураційному файлі kubeadm, також доступні як прапорці командного рядка, але цей спосіб підтримує лише найпоширеніші/найпростіші випадки використання.

Конфігураційний файл kubeadm може містити декілька типів конфігурацій, розділених трьома тире (---).

kubeadm підтримує наступні типи конфігурацій:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration


apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration


apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration


apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration


apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration

apiVersion: kubeadm.k8s.io/v1beta4
kind: ResetConfiguration

apiVersion: kubeadm.k8s.io/v1beta4
kind: UpgradeConfiguration

Для виведення стандартних значень для дій init та join скористайтеся наступними командами:

kubeadm config print init-defaults
kubeadm config print join-defaults
kubeadm config print reset-defaults
kubeadm config print upgrade-defaults

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

Якщо деякі типи конфігурацій не передбачено або передбачено лише частково, kubeadm використовуватиме стандартні значення; стандартне налаштування kubeadm включає також забезпечення узгодженості значень між компонентами, коли це необхідно (наприклад, прапорець --cluster-cidr на менеджері контролерів та clusterCIDR на kube-proxy).

Користувачам завжди дозволено перевизначати стандартні значення, за винятком невеликої підгрупи налаштувань, що мають відношення до безпеки (наприклад, включення режиму авторизації Node і RBAC на api-сервері).

Якщо користувач надасть типи конфігурації, які не очікуються для дії, яку ви виконуєте, kubeadm проігнорує ці типи та виведе попередження.

Типи конфігурацій Kubeadm init

При виконанні kubeadm init з опцією --config можуть бути використані наступні типи конфігурацій: InitConfiguration, ClusterConfiguration, KubeProxyConfiguration, KubeletConfiguration, але тільки один з них між InitConfiguration і ClusterConfiguration є обовʼязковим.

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
bootstrapTokens:

	...

nodeRegistration:

	...

Тип InitConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm init є конфігурація токена завантажувача та всі параметри, специфічні для вузла, на якому виконується kubeadm, включно з:

  • NodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • LocalAPIEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі; використовуйте його, наприклад, для налаштування адреси оголошень сервера API.
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:

	...

etcd:

	...

apiServer:

	extraArgs:
	  ...
	extraVolumes:
	  ...

...

Тип ClusterConfiguration слід використовувати для налаштування параметрів всього кластера, включаючи налаштування для:

  • networking, що зберігає конфігурацію мережевої топології кластера; використовуйте його, наприклад, для налаштування підмережі Pod або підмережі сервісів.
  • etcd: використовуйте його, наприклад, для налаштування локального etcd або для налаштування сервера API для використання зовнішнього кластера etcd.
  • конфігурації kube-apiserver, kube-scheduler, kube-controller-manager; використовуйте його для налаштування компонентів панелі управління, додаючи індивідуальні налаштування або перевизначаючи стандартні налаштування kubeadm.
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration

	...

Тип KubeProxyConfiguration слід використовувати для зміни конфігурації, що передається екземплярам kube-proxy, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні значення.

Офіційну документацію про kube-proxy можна знайти на https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ або https://pkg.go.dev/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

	...

Тип KubeletConfiguration слід використовувати для зміни конфігурацій, які буде передано всім екземплярам kubelet, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні налаштування.

Офіційну документацію про kubelet можна знайти на https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ або https://pkg.go.dev/k8s.io/kubelet/config/v1beta1#KubeletConfiguration.

Ось повністю заповнений приклад одного YAML-файлу, що містить декілька типів конфігурації для використання під час запуску kubeadm init.

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
bootstrapTokens:
  - token: "9a08jv.c0izixklcxtmnze7"
    description: "kubeadm bootstrap token"
    ttl: "24h"
  - token: "783bde.3f89s0fje9f38fhf"
    description: "another bootstrap token"
    usages:
  - authentication
  - signing
    groups:
  - system:bootstrappers:kubeadm:default-node-token

nodeRegistration:
  name: "ec2-10-100-0-1"
  criSocket: "unix:///var/run/containerd/containerd.sock"
  taints:
    - key: "kubeadmNode"
      value: "someValue"
      effect: "NoSchedule"
  kubeletExtraArgs:
    - name: v
      value: 5
  ignorePreflightErrors:
     - IsPrivilegedUser
  imagePullPolicy: "IfNotPresent"

localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443

certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
skipPhases:
  - preflight

timeouts:
  controlPlaneComponentHealthCheck: "60s
  kubernetesAPICall: "40s"
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
etcd:

  # локальний або зовнішній etcd
  local:
    imageRepository: "registry.k8s.io"
    imageTag: "3.2.24"
    dataDir: "/var/lib/etcd"
    extraArgs:
      - name: listen-client-urls
        value: http://10.100.0.1:2379
    extraEnvs:
      - name: SOME_VAR
        value: SOME_VALUE
    serverCertSANs:
      -  "ec2-10-100-0-1.compute-1.amazonaws.com"
    peerCertSANs:
      - "10.100.0.1"
# external:
  # endpoints:
  # - "10.100.0.1:2379"
  # - "10.100.0.2:2379"
  # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
  # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
  # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"

networking:
  serviceSubnet: "10.96.0.0/16"
  podSubnet: "10.244.0.0/24"
  dnsDomain: "cluster.local"

kubernetesVersion: "v1.21.0"
controlPlaneEndpoint: "10.100.0.1:6443"
apiServer:

  extraArgs:
    - name: authorization-mode
      value: "Node,RBAC"
  extraEnvs:
    - name: SOME_VAR
      value: SOME_VALUE
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
  certSANs:
    - "10.100.1.1"
    - "ec2-10-100-0-1.compute-1.amazonaws.com"

controllerManager:
  extraArgs:
    - name: node-cidr-mask-size
      value: "20"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File

scheduler:
  extraArgs:
    - name: address
      value: "10.100.0.1"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File

certificatesDir: "/etc/kubernetes/pki"
imageRepository: "registry.k8s.io"
clusterName: "example-cluster"
encryptionAlgorithm: ECDSA-P256
dns:
  disabled: true  # disable CoreDNS
proxy:
  diabled: true   # disable kube-proxy
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# параметри kubelet вказуються тут
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
# параметри kube-proxy вказуються тут

Типи конфігурацій Kubeadm join

При виконанні kubeadm join з опцією --config слід вказати тип JoinConfiguration.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: some-address:6443
    token: abcdef.0123456789abcdef
    unsafeSkipCAVerification: true
  tlsBootstrapToken: abcdef.0123456789abcdef

Тип JoinConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm join є метод виявлення, що використовується для доступу до інформації про кластер, а також всі налаштування, специфічні для вузла, на якому виконується kubeadm, включно з:

  • nodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • apiEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі.

Типи конфігурацій Kubeadm reset

При виконанні kubeadm reset з опцією --config слід вказати тип ResetConfiguration.

apiVersion: kubeadm.k8s.io/v1beta4
kind: ResetConfiguration
...

Типи конфігурацій Kubeadm upgrade

При виконанні kubeadm upgrade з опцією --config слід вказати тип UpgradeConfiguration.

apiVersion: kubeadm.k8s.io/v1beta4
kind: UpgradeConfiguration
apply:
  ...

diff:
  ...

node:
  ...

plan:
  ...

Структура UpgradeConfiguration містить кілька підструктур, які застосовуються тільки різних команд kubeadm upgrade. Наприклад, apply використовується з командою kubeadm upgrade apply тож всі інші підструктури будуть проігноровані.

Типи ресурсів

BootstrapToken

Зʼявляється в:

BootstrapToken описує один bootstrap token, зберігається як Secret у кластері

ПолеОпис
token [Обовʼязкове]
BootstrapTokenString

token використовується для встановлення двосторонньої довіри між вузлами та панеллю управління. Використовується для приєднання вузлів до кластера.

description
string

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

ttl
meta/v1.Duration

ttl визначає час життя цього токена. Стандартно — 24h. expires та ttl є взаємовиключними.

expires
meta/v1.Time

expires вказує на момент, коли цей токен закінчує свою дію. Стандартно встановлюється динамічно під час виконання на основі ttl. expires та ttl є взаємовиключними.

usages
[]string

usages описує способи, якими цей токен може бути використаний. Може стандартно використовуватися для встановлення двосторонньої довіри, але це можна змінити тут.

groups
[]string

groups вказує на додаткові групи, до яких цей токен буде автентифікуватися при використанні для автентифікації

BootstrapTokenString

Зʼявляється в:

BootstrapTokenString є токеном формату abcdef.abcdef0123456789, який використовується як для перевірки практичності API сервера з погляду вузла, що приєднується, так і як метод автентифікації вузла в фазі bootstrap команди "kubeadm join". Цей токен є і має бути короткочасним.

ПолеОпис
- [Обовʼязкове]
string		Опис не надано.
- [Обовʼязкове]
string		Опис не надано.

ClusterConfiguration

ClusterConfiguration містить конфігурацію на рівні кластера для кластера kubeadm.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta4
kind
string		ClusterConfiguration
etcd
Etcd

etcd містить конфігурацію для etcd.

networking
Networking

networking містить конфігурацію для мережевої топології кластера.

kubernetesVersion
string

kubernetesVersion — це цільова версія панелі управління.

controlPlaneEndpoint
string

controlPlaneEndpoint встановлює стабільну IP-адресу або DNS-імʼя для панелі управління; Може бути дійсною IP-адресою або піддоменом RFC-1123 DNS, обидва з необовʼязковим TCP портом. Якщо controlPlaneEndpoint не зазначено, використовуються advertiseAddress + bindPort; якщо controlPlaneEndpoint зазначено, але без TCP порту, використовується bindPort. Можливі використання:

  • У кластері з більше ніж однією панеллю управління, це поле має бути присвоєно адресі зовнішнього балансувальника навантаження перед екземплярами панелі управління.
  • У середовищах з примусовою утилізацією вузлів, controlPlaneEndpoint може використовуватися для присвоєння стабільного DNS панелі управління.
apiServer
APIServer

apiServer містить додаткові налаштування для API сервера.

controllerManager
ControlPlaneComponent

controllerManager містить додаткові налаштування для менеджера контролерів.

scheduler
ControlPlaneComponent

scheduler містить додаткові налаштування для планувальника.

dns
DNS

dns визначає параметри для нпдбудови DNS, встановленої в кластері.

proxy [Обовʼязкове]
Proxy

proxy визначає параметри для надбудови проксі, встановленої в кластері.

certificatesDir
string

certificatesDir вказує, де зберігати або шукати всі необхідні сертифікати.

imageRepository
string

imageRepository встановлює реєстр контейнерів для витягування зображень. Якщо порожньо, стандартно використовується registry.k8s.io. У випадку, якщо версія Kubernetes є CI-збіркою (версія Kubernetes починається з ci/) gcr.io/k8s-staging-ci-images буде використовуватись для компонентів панелі управління та для kube-proxy, тоді як registry.k8s.io буде використовуватися для всіх інших образів.

featureGates
map[string]bool

featureGates містить функціональні можливості, увімкнені користувачем.

clusterName
string

Назва кластера.

encryptionAlgorithm
EncryptionAlgorithmType

encryptionAlgorithm містить тип асиметричного алгоритму шифрування, що використовується для ключів та сертифікатів. Може бути "RSA" (стандартний алгоритм, розмір ключа 2048) або "ECDSA" (використовує еліптичну криву P-256).

certificateValidityPeriod
meta/v1.Duration

certificateValidityPeriod вказує термін дії для не-СА сертифікату, згенерованого kubeadm. Стандартне значення: 8760h (365 днів * 24 години = 1 рік)

caCertificateValidityPeriod
meta/v1.Duration

caCertificateValidityPeriod вказує термін дії для СА сертифікату, згенерованого kubeadm. Стандартне значення: 87600h (365 днів * 24 годин * 10 = 10 років)

InitConfiguration

InitConfiguration містить список елементів, що специфічні для тільки для запуску kubeadm init. Ці поля використовуються лише під час першого запуску kubeadm init. Після цього інформація в цих полях НЕ завантажується до ConfigMap kubeadm-config, який використовується, наприклад, при kubeadm upgrade. Ці поля повинні бути опущені.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta4
kind
string		InitConfiguration
bootstrapTokens
[]BootstrapToken

bootstrapTokens враховується під час kubeadm init і описує набір Bootstrap Token для створення. Ця інформація НЕ завантажується до ConfigMap кластера kubeadm, частково через її чутливий характер.

dryRun [Обовʼязкове]
bool

dryRun вказує, чи увімкнено режим перевірки, не застосовувати жодні зміни в режимі перевірки, просто вивести те, що буде зроблено.

nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

localAPIEndpoint
APIEndpoint

localAPIEndpoint представляє точку доступу до екземпляра API сервера, що розгорнутий на цьому вузлі панелі управління. У налаштуваннях HA це відрізняється від ClusterConfiguration.controlPlaneEndpoint тим, що controlPlaneEndpoint є глобальною точкою доступу для кластера, яка потім розподіляє запити між кожним окремим API сервером. Цей обʼєкт конфігурації дозволяє налаштувати, на якій IP/DNS-імʼя та порт локальний API сервер оголошує свою доступність. Стандартно kubeadm намагається автоматично визначити IP адресу інтерфейсу та використовувати її, але якщо цей процес не вдалося, ви можете встановити бажане значення тут.

certificateKey
string

certificateKey встановлює ключ, яким шифруються сертифікати та ключі перед завантаженням в Secret в кластері під час фази uploadcerts init. Ключ сертифіката є рядком у форматі hex, що є AES ключем розміром 32 байти.

skipPhases
[]string

skipPhases є списком фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm init --help. Прапорець --skip-phases має пріоритет над цим полем.

patches
Patches

patches містить параметри, що стосуються застосування патчів до компонентів, розгорнутих kubeadm під час kubeadm init.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

JoinConfiguration

JoinConfiguration містить елементи, що описують конкретний вузол.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta4
kind
string		JoinConfiguration
dryRun
bool

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

nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

caCertPath
string

caCertPath є шляхом до SSL центру сертифікації, що використовується для забезпечення комунікацій між вузлом та панеллю управління. Стандартно — /etc/kubernetes/pki/ca.crt.

discovery [Обовʼязкове]
Discovery

discovery вказує параметри, які kubelet використовує під час процесу TLS bootstrap.

controlPlane
JoinControlPlane

controlPlane визначає додатковий екземпляр панелі управління, який буде розгорнуто на вузлі, що приєднується. Якщо nil, жоден додатковий екземпляр панелі управління не буде розгорнуто.

skipPhases
[]string

skipPhases є списком фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm join --help. Прапорець --skip-phases має пріоритет над цим полем.

patches
Patches

patches містить параметри, що стосуються застосування патчів до компонентів, розгорнутих kubeadm під час kubeadm join.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

ResetConfiguration

ResetConfiguration містить список полів, що є специфічними для режиму kubeadm reset.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta4
kind
string		ResetConfiguration
cleanupTmpDir
bool

cleanupTmpDir вказує, чи слід очищати теку /etc/kubernetes/tmp під час процесу скидання.

certificatesDir
string

certificatesDir вказує теку, де зберігаються сертифікати. Якщо вказано, вона буде очищена під час процесу скидання.

criSocket
string

criSocket використовується для отримання інформації про середовище виконання контейнерів для видалення контейнерів. Якщо criSocket не вказано через прапорець або файл конфігурації, kubeadm спробує виявити дійсний CRI сокет.

dryRun
bool

dryRun вказує, чи увімкнено режим перевірки. Якщо так, жодні зміни не застосовуються, а просто виводиться те, що буде зроблено.

force
bool

Флаг force інструктує kubeadm скинути вузол без запиту підтвердження.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок перед стартом, які слід ігнорувати під час процесу скидання, наприклад, IsPrivilegedUser,Swap. Значення all ігнорує помилки з усіх перевірок.

skipPhases
[]string

skipPhases є списком фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm reset phase --help.

unmountFlags
[]string

unmountFlags — список прапорців syscall unmount2(), які kubeadm може використовувати при розмонтуванні тек під час " reset". Цей прапорець може бути одним з: "MNT_FORCE", "MNT_DETACH", "MNT_EXPIRE", "UMOUNT_NOFOLLOW". Стандартно цей список порожній.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

UpgradeConfiguration

UpgradeConfiguration містить список опцій, специфічних для підкоманд kubeadm upgrade.

ПолеОпис
apiVersion
string		kubeadm.k8s.io/v1beta4
kind
string		UpgradeConfiguration
apply
UpgradeApplyConfiguration

apply містить список опцій, специфічних для команди kubeadm upgrade apply.

diff
UpgradeDiffConfiguration

diff містить список опцій, специфічних для команди kubeadm upgrade diff.

node
UpgradeNodeConfiguration

node містить список опцій, специфічних для команди kubeadm upgrade node.

plan
UpgradePlanConfiguration

plan містить список опцій, специфічних для команди kubeadm upgrade plan.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

APIEndpoint

Зʼявляється в:

Структура APIEndpoint містить елементи для екземпляра API сервера, розгорнутого на вузлі.

ПолеОпис
advertiseAddress
string

advertiseAddress встановлює IP-адресу, яку API сервер буде оголошувати.

bindPort
int32

bindPort встановлює захищений порт, до якого API сервер буде привʼязаний. Стандартно — 6443.

APIServer

Зʼявляється в:

APIServer містить налаштування, необхідні для розгортання API сервера в кластері.

ПолеОпис
ControlPlaneComponent [Обовʼязкове]
ControlPlaneComponent		(Члени ControlPlaneComponent вбудовані в цей тип.) Опис не надано.
certSANs
[]string

certSANs встановлює додаткові альтернативні імена субʼєкта (SAN) для сертифіката підпису API сервера.

Arg

Зʼявляється в:

Arg представляє собою аргумент з імʼям і значенням.

ПолеОпис
name [Обовʼязкове]
string

Імʼя аргументу.

value [Обовʼязкове]
string

Значення аргументу.

BootstrapTokenDiscovery

Зʼявляється в:

BootstrapTokenDiscovery використовується для налаштування параметрів для виявлення з використанням токенів.

ПолеОпис
token [Обовʼязкове]
string

token є токеном, що використовується для перевірки інформації про кластер, отриманої від панелі управління.

apiServerEndpoint
string

apiServerEndpoint є IP-адресою або доменним імʼям API-сервера, з якого буде отримана інформація.

caCertHashes
[]string

caCertHashes вказує набір публічних ключів, які потрібно перевірити при використанні виявлення на основі токенів. Кореневий CA, знайдений під час виявлення, повинен відповідати одному з цих значень. Вказівка порожнього набору вимикає привʼязку кореневого CA, що може бути небезпечним. Кожен хеш вказується як <type>:<value>, де єдиний підтримуваний тип наразі — "sha256". Це хеш SHA-256 коду обʼєкта Subject Public Key Info (SPKI) у DER-кодованому ASN.1. Ці хеші можна розрахувати за допомогою, наприклад, OpenSSL.

unsafeSkipCAVerification
bool

unsafeSkipCAVerification дозволяє виявлення на основі токенів без перевірки CA через caCertHashes. Це може ослабити безпеку kubeadm, оскільки інші вузли можуть видавати себе за панель управління.

ControlPlaneComponent

Зʼявляється в:

ControlPlaneComponent містить налаштування, загальні для компонентів панелі управління кластера.

ПолеОпис
extraArgs
[]Arg

extraArgs — це додатковий набір прапорців, які передаються компоненту панелі управління. Назва аргументу в цьому списку є назвою прапорця, як вона зʼявляється в командному рядку, але без початковиї дефісів. Додаткові аргументи переважатимуть існуючі стандартні аргументи. Дублікати додаткових аргументів дозволені.

extraVolumes
[]HostPathMount

extraVolumes — це додатковий набір томів хостів, які монтуються до компонента панелі управління.

extraEnvs
[]EnvVar

extraEnvs — це додатковий набір змінних середовища, які передаються компоненту панелі управління. Змінні середовища, передані за допомогою extraEnvs, переважатимуть будь-які існуючі змінні середовища або змінні середовища *_proxy, які kubeadm додає стандартно.

DNS

Зʼявляється в:

DNS визначає аддон DNS, який має бути використаний у кластері.

ПолеОпис
ImageMeta [Обовʼязково]
ImageMeta		(Члени ImageMeta вбудовані в цей тип.)

imageMeta дозволяє налаштувати образ, що використовується для надбудови DNS.

disabled [Обовʼязково]
bool

disabled вказує, чи слід вимкнути цю надбудовув кластері.

Discovery

Зʼявляється в:

Discovery визначає параметри для kubelet під час процесу TLS Bootstrap.

ПолеОпис
bootstrapToken
BootstrapTokenDiscovery

bootstrapToken використовується для налаштування параметрів для виявлення за допомогою токена Bootstrap. bootstrapToken і file є взаємовиключними.

file
FileDiscovery

file використовується для вказівки файлу або URL на kubeconfig файл, з якого завантажується інформація про кластер. bootstrapToken і file є взаємовиключними.

tlsBootstrapToken
string

tlsBootstrapToken є токеном, що використовується для TLS bootstrapping. Якщо bootstrapToken встановлено, це поле стандартно буде дорівнювати bootstrapToken.token, але його можна перевизначити. Якщо file встановлено, це поле повинно бути встановлено, якщо файл KubeConfigFile не містить іншої інформації для автентифікації.

EncryptionAlgorithmType

(Аліас для string)

Зʼявляється в:

EncryptionAlgorithmType може визначити тип асиметричного алгоритму шифрування.

EnvVar

Зʼявляється в:

EnvVar представляє змінну середовища, присутню в контейнері.

ПолеОпис
EnvVar [Обовʼязкове]
core/v1.EnvVar		(Члени EnvVar вбудовані в цей тип.) Опис не надано.

Etcd

Зʼявляється в:

Etcd містить елементи, що описують конфігурацію Etcd.

ПолеОпис
local
LocalEtcd

local надає конфігураційні параметри для налаштування локального екземпляра etcd. local та external є взаємовиключними.

external
ExternalEtcd

external описує, як підключитися до зовнішнього кластеру etcd. local та external є взаємовиключними.

ExternalEtcd

Зʼявляється в:

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

ПолеОпис
endpoints [Обовʼязкове]
[]string

endpoints містить список членів etcd.

caFile [Обовʼязкове]
string

caFile є файлом центру сертифікації (CA) SSL, що використовується для захисту комунікації etcd. Необхідний, якщо використовується зʼєднання TLS.

certFile [Обовʼязкове]
string

certFile є файлом сертифікації SSL, що використовується для захисту комунікації etcd. Необхідний, якщо використовується зʼєднання TLS.

keyFile [Обовʼязкове]
string

keyFile є файлом ключа SSL, що використовується для захисту комунікації etcd. Необхідний, якщо використовується зʼєднання TLS.

FileDiscovery

Зʼявляється в:

FileDiscovery використовується для вказівки файлу або URL на kubeconfig файл, з якого слід завантажити інформацію про кластер.

ПолеОпис
kubeConfigPath [Обовʼязкове]
string

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

HostPathMount

Зʼявляється в:

HostPathMount містить елементи, що описують томи, які монтуються з хоста.

ПолеОпис
name [Обовʼязкове]
string

name — це назва тому всередині шаблону Pod.

hostPath [Обовʼязкове]
string

hostPath — це шлях на хості, який буде змонтований всередині Pod.

mountPath [Обовʼязкове]
string

mountPath — це шлях всередині Pod, де буде змонтований hostPath.

readOnly
bool

readOnly контролює доступ на запис до тому.

pathType
core/v1.HostPathType

pathType — це тип hostPath.

ImageMeta

Зʼявляється в:

ImageMeta дозволяє налаштувати образ, що використовується для компонентів, які не походять з процесу релізу Kubernetes/Kubernetes.

ПолеОпис
imageRepository
string

imageRepository визначає реєстр контейнерів, з якого потрібно завантажити образи. Якщо не вказано, буде використано imageRepository, визначений в ClusterConfiguration.

imageTag
string

imageTag дозволяє вказати тег для образу. У випадку, якщо це значення вказане, kubeadm не змінює автоматично версію вищезазначених компонентів під час оновлень.

JoinControlPlane

Зʼявляється в:

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

ПолеОпис
localAPIEndpoint
APIEndpoint

localAPIEndpoint представляє точку доступу екземпляра API сервера, яка має бути розгорнута на цьому вузлі.

certificateKey
string

certificateKey є ключем, що використовується для розшифрування сертифікатів після їх завантаження з Secret при приєднанні нового вузла панелі управління. Відповідний ключ шифрування знаходиться в InitConfiguration. Ключ сертифіката є рядком у шістнадцятковому кодуванні, який є AES ключем розміром 32 байти.

LocalEtcd

Зʼявляється в:

LocalEtcd описує, що kubeadm має запустити кластер etcd локально.

ПолеОпис
ImageMeta [Обовʼязково]
ImageMeta		(Члени ImageMeta вбудовані в цей тип.)

ImageMeta дозволяє налаштувати контейнер, що використовується для etcd.

dataDir [Обовʼязково]
string

dataDir є текою, в якій etcd розміщуватиме свої дані. Стандартно це "/var/lib/etcd".

extraArgs [Обовʼязково]
[]Arg

extraArgs є додатковими аргументами, що передаються бінарному файлу etcd при його запуску всередині статичного Pod. Назва аргументу в цьому списку є іменем прапорця, як вона зʼявляється в командному рядку, за винятком тире на початку. Додаткові аргументи переважатимуть існуючі стандартні аргументи. Дублювання додаткових аргументів дозволяється.

extraEnvs
[]EnvVar

extraEnvs є додатковим набором змінних середовища для передачі компоненту панелі управління. Змінні середовища, передані за допомогою extraEnvs, перезаписуватимуть будь-які існуючі змінні середовища або змінні середовища *_proxy, які kubeadm додає стандартно.

serverCertSANs
[]string

serverCertSANs встановлює додаткові Subject Alternative Names (SANs) для сертифіката підпису сервера etcd.

peerCertSANs
[]string

peerCertSANs встановлює додаткові Subject Alternative Names (SANs) для сертифіката підпису peer etcd.

Networking

Зʼявляється в:

Networking містить елементи, що описують конфігурацію мережі кластера.

ПолеОпис
serviceSubnet
string

serviceSubnet є підмережею, що використовується сервісами Kubernetes. Стандартно це "10.96.0.0/12".

podSubnet
string

podSubnet є підмережею, що використовується Pod.

dnsDomain
string

dnsDomain є доменом DNS, що використовується сервісами Kubernetes. Стандартно це "cluster.local".

NodeRegistrationOptions

Зʼявляється в:

NodeRegistrationOptions містить поля, що стосуються реєстрації новоїпанелі управління або вузла в кластері, або через kubeadm init, або kubeadm join.

ПолеОпис
name
string

name є полем .Metadata.Name обʼєкта Node API, який буде створений в операціях kubeadm init або kubeadm join. Це поле також використовується в полі CommonName клієнтського сертифіката kubelet для API сервера. Стандартно використовується імʼя хосту вузла, якщо не задано.

criSocket
string

criSocket використовується для отримання інформації про середовище виконання контейнерів. Ця інформація буде анотована до обʼєкта Node API для подальшого використання.

taints [Обовʼязкове]
[]core/v1.Taint

taints

taints вказує на taints, з якими обʼєкт Node API повинен бути зареєстрований. Якщо це поле не встановлено, тобто nil, воно буде стандартно з control-plane taint для вузлів control-plane. Якщо ви не хочете taint для вашого вузла control-plane, встановіть в це поле порожній список, тобто taints: [] у YAML файлі. Це поле використовується виключно для реєстрації вузлів.

kubeletExtraArgs
[]Arg

kubeletExtraArgs передає додаткові аргументи до kubelet. Аргументи тут передаються командному рядку kubelet через файл середовища, який kubeadm записує під час виконання для джерела kubelet. Це переважає загальну базову конфігурацію у ConfigMap kubelet-config. Прапорці мають вищий пріоритет при розборі. Ці значення є локальними і специфічними для вузла, на якому виконується kubeadm. Назва аргументу в цьому списку є назвою прапорця, як вона зʼявляється в командному рядку, крім дефісів на початку. Додаткові аргументи переважають існуючі стандартні значення. Дублікати додаткових аргументів дозволені.

ignorePreflightErrors
[]string

ignorePreflightErrors надає масив помилок перед польотом, які слід ігнорувати при реєстрації поточного вузла, наприклад, 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy вказує політику витягування образів під час kubeadm init та join операцій. Значення цього поля має бути одне з "Always", "IfNotPresent" або "Never". Якщо це поле не задане, kubeadm стандартно встановить його в "IfNotPresent", або витягне необхідні образи, якщо вони не присутні на хості.

imagePullSerial
bool

imagePullSerial вказує, чи витягування образів, яке виконує kubeadm, має відбуватися послідовно або паралельно. Стандартно: true

Patches

Зʼявляється в:

Patches містить опції, повʼязані із застосуванням патчів до компонентів, розгорнутих kubeadm.

ПолеОпис
directory
string

directory є шляхом до теки, що містить файли, названі "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json" і відповідає форматам патчів, підтримуваним kubectl. Стандартно "patchtype" є "strategic". "extension" має бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення порядку застосування патчів за алфавітним порядком.

Proxy

Зʼявляється в:

Proxy визначає надбудову проксі, яка має використовуватися в кластері.

ПолеОпис
disabled [Обовʼязкове]
bool

disabled визначає, чи слід вимкнути цю надбудову у кластері.

Timeouts

Зʼявляється в:

Timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

ПолеОпис
controlPlaneComponentHealthCheck
meta/v1.Duration

controlPlaneComponentHealthCheck є часом очікування для перевірки справності компонентів панелі управління, таких як API сервер, під час kubeadm init та kubeadm join. Стандартно — 4м

kubeletHealthCheck
meta/v1.Duration

kubeletHealthCheck є часом очікування для перевірки здоровʼя kubelet під час kubeadm init та kubeadm join. Стандартно — 4м

kubernetesAPICall
meta/v1.Duration

kubernetesAPICall є часом очікування для завершення запиту клієнта kubeadm до API сервера. Це застосовується до всіх типів методів (GET, POST тощо). Стандартно — 1м

etcdAPICall
meta/v1.Duration

etcdAPICall є часом очікування для завершення запиту клієнта kubeadm до кластера etcd. Стандартно — 2м

tlsBootstrap
meta/v1.Duration

tlsBootstrap є часом очікування для завершення TLS bootstrap для приєднуючого вузла. Стандартно — 5м

discovery
meta/v1.Duration

discovery є часом очікування для перевірки ідентичності API сервера для приєднуючого вузла. Стандартно — 5м

upgradeManifests [Обовʼязкове]
meta/v1.Duration

upgradeManifests є тайм-аутом для оновлення статичних манифестів Pod. Стандартно — 5м

UpgradeApplyConfiguration

Зʼявляється в:

UpgradeApplyConfiguration містить список параметрів конфігурації, які специфічні для команди kubeadm upgrade apply.

ПолеОпис
kubernetesVersion
string

kubernetesVersion є цільовою версією панелі управління.

allowExperimentalUpgrades
bool

allowExperimentalUpgrades інструктує kubeadm показувати нестабільні версії Kubernetes як альтернативу оновленню та дозволяє оновлення до альфа/бета/версії-кандидата Kubernetes. Стандартно — false

allowRCUpgrades
bool

Увімкнення allowRCUpgrades покаже версії-кандидати релізів Kubernetes як альтернативу оновленню та дозволяє оновлення до версії-кандидата Kubernetes.

certificateRenewal
bool

certificateRenewal інструктує kubeadm виконати поновлення сертифікатів під час оновлень. Стандартно — true

dryRun
bool

dryRun вказує, чи увімкнено режим перевірки без змін, не застосовувати жодних змін, а лише виводити те, що буде зроблено.

etcdUpgrade
bool

etcdUpgrade інструктує kubeadm виконати оновлення etcd під час оновлень. Стандартно — true

forceUpgrade
bool

forceUpgrade вказує kubeadm оновити кластер без запиту підтвердження.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок перевірки перед виконанням, які слід ігнорувати під час процесу оновлення, наприклад, IsPrivilegedUser,Swap. Значення all ігнорує помилки з усіх перевірок.

patches
Patches

patches містить параметри, повʼязані із застосуванням патчів до компонентів, розгорнутих kubeadm під час kubeadm upgrade.

printConfig
bool

printConfig вказує, чи слід вивести конфігураційний файл, який буде використаний в оновленні.

skipPhases [Обовʼязкове]
[]string

SkipPhases є списком фаз, які слід пропустити під час виконання команди. ПРИМІТКА: Це поле наразі ігнорується для kubeadm upgrade apply, але в майбутньому буде підтримуватися.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy визначає політику витягування образів під час операцій kubeadm upgrade apply. Значення цього поля має бути одним з "Always", "IfNotPresent" або "Never". Якщо це поле не встановлено, kubeadm автоматично встановить значення "IfNotPresent", або витягне потрібні образи, якщо їх немає на хості.

imagePullSerial
bool

imagePullSerial вказує, чи витягування образів, яке виконує kubeadm, має відбуватися послідовно або паралельно. Стандартно: true

UpgradeDiffConfiguration

Зʼявляється в:

UpgradeDiffConfiguration містить список параметрів конфігурації, які специфічні для команди kubeadm upgrade diff.

ПолеОпис
kubernetesVersion
string

kubernetesVersion є цільовою версією панелі управління.

contextLines
int

diffContextLines є кількістю рядків контексту в diff.

UpgradeNodeConfiguration

Зʼявляється в:

UpgradeNodeConfiguration містить список параметрів конфігурації, які специфічні для команди "kubeadm upgrade node".

ПолеОпис
certificateRenewal
bool

certificateRenewal інструктує kubeadm виконати поновлення сертифікатів під час оновлень. Стандартно — true.

dryRun
bool

dryRun вказує, чи увімкнено режим попереднього перегляду. Якщо так, зміни не будуть застосовані, а буде виведено тільки те, що було б зроблено.

etcdUpgrade
bool

etcdUpgrade інструктує kubeadm виконати оновлення etcd під час оновлень. Стандартно — true.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок попередньої перевірки, які слід ігнорувати під час процесу оновлення, наприклад, 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

skipPhases
[]string

skipPhases є списком фаз, які слід пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm upgrade node phase --help.

patches
Patches

patches містить параметри, повʼязані із застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm під час kubeadm upgrade.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy визначає політику витягування образів під час операцій kubeadm upgrade node. Значенням цього поля має бути одне з "Always", "IfNotPresent" або "Never". Якщо це поле не встановлено, kubeadm автоматично встановить значення "IfNotPresent", або витягне потрібні образи, якщо їх немає на хості.

imagePullSerial
bool

imagePullSerial вказує, чи витягування образів, яке виконує kubeadm, має відбуватися послідовно або паралельно. Стандартно: true

UpgradePlanConfiguration

Зʼявляється в:

UpgradePlanConfiguration містить список параметрів конфігурації, які специфічні для команди "kubeadm upgrade plan".

ПолеОпис
kubernetesVersion [Обовʼязкове]
string

kubernetesVersion є цільовою версією панелі управління.

allowExperimentalUpgrades
bool

allowExperimentalUpgrades інструктує kubeadm показувати нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/реліз кандидата версій Kubernetes. Стандартно — false

allowRCUpgrades
bool

Увімкнення allowRCUpgrades показуватиме версії-кандидати релізу Kubernetes як альтернативу для оновлення та дозволить оновлення до версії кандидата релізу Kubernetes.

dryRun
bool

dryRun вказує, чи увімкнено режим попереднього перегляду. Якщо так, зміни не будуть застосовані, а буде виведено тільки те, що було б зроблено.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок попередньої перевірки, які слід ігнорувати під час процесу оновлення, наприклад, 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

printConfig
bool

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

14.15 - kubeconfig (v1)

Типи ресурсів

Config

Config містить інформацію, необхідну для підключення до віддалених кластерів Kubernetes як вказаний користувач

ПолеОпис
apiVersion
string		/v1
kind
string		Config
kind
string

Спадкове поле з pkg/api/types.go TypeMeta. TODO(jlowdermilk): видалити його після усунення залежностей з низхідних напрямків.

apiVersion
string

Спадкове поле з pkg/api/types.go TypeMeta. TODO(jlowdermilk): видалити його після усунення залежностей з низхідних напрямків.

preferences [Обовʼязкове]
Preferences

Preferences містить загальну інформацію для використання у взаємодії з CLI

clusters [Обовʼязкове]
[]NamedCluster

Clusters — це map імен, на які можна посилатися в конфігураціях кластерів

users [Обовʼязкове]
[]NamedAuthInfo

AuthInfos — це map імен, на які можна посилатися в конфігураціях користувача

contexts [Обовʼязкове]
[]NamedContext

Контексти — це map імен, на які можна посилатися, до конфігурацій контекстів

current-context [Обовʼязкове]
string

CurrentContext — це імʼя контексту, який ви хочете використовувати стандартно

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання та запис не знищували невідомі поля

AuthInfo

Зʼявляється в:

AuthInfo містить інформацію, яка описує ідентифікаційні дані. Це використовується для інформування кластера Kubernetes, хто ви є.

ПолеОпис
client-certificate
string

ClientCertificate — це шлях до файлу клієнтського сертифіката для TLS.

client-certificate-data
[]byte

ClientCertificateData містить дані в кодуванні PEM з файлу клієнтського сертифіката для TLS. Перезаписує ClientCertificate.

client-key
string

ClientKey — це шлях до файлу клієнтського ключа для TLS.

client-key-data
[]byte

ClientKeyData містить дані в кодуванні PEM з файлу клієнтського ключа для TLS. Перезаписує ClientKey.

token
string

Token — це токен, що підтверджує право на доступ до кластера Kubernetes.

tokenFile
string

TokenFile — це вказівка на файл, який містить токен (як описано вище). Якщо присутні як Token, так і TokenFile, перевага надається Token.

as
string

Impersonate — імʼя користувача, від імені якого потрібно діяти. Імʼя збігається з прапорцем.

as-uid
string

ImpersonateUID — це UID, від імені якого потрібно діяти.

as-groups
[]string

ImpersonateGroups — це групи, від імені якої потрібно діяти.

as-user-extra
map[string][]string

ImpersonateUserExtra містить додаткову інформацію для користувача, від імені якого потрібно діяти.

username
string

Username — це імʼя користувача для базової автентифікації в кластері Kubernetes.

password
string

Password — це пароль для базової автентифікації в кластері Kubernetes.

auth-provider
AuthProviderConfig

AuthProvider вказує на власний втулок автентифікації для кластера Kubernetes.

exec
ExecConfig

Exec вказує на власний втулок автентифікації на основі виконання для кластера Kubernetes.

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання та запис не знищували невідомі поля.

AuthProviderConfig

Зʼявляється в:

AuthProviderConfig містить конфігурацію для вказаного провайдера автентифікації.

ПолеОпис
name [Обовʼязково]
string		Опис не надано.
config [Обовʼязково]
map[string]string		Опис не надано.

Cluster

Зʼявляється в:

Cluster містить інформацію про те, як спілкуватися з кластером Kubernetes.

ПолеОпис
server [Обовʼязково]
string

Server — це адреса кластера Kubernetes (https://hostname:port).

tls-server-name
string

TLSServerName використовується для перевірки сертифіката сервера. Якщо TLSServerName порожній, використовується імʼя хоста, щоб звʼязатися з сервером.

insecure-skip-tls-verify
bool

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

certificate-authority
string

CertificateAuthority - це шлях до файлу сертифіката для сертифікаційного центру.

certificate-authority-data
[]byte

CertificateAuthorityData містить PEM-кодовані сертифікати сертифікаційного центру. Перекриває CertificateAuthority.

proxy-url
string

ProxyURL — це URL-адреса проксі, яка буде використовуватися для всіх запитів, здійснюваних цим клієнтом. Підтримуються URL-адреси зі схемами "http", "https" та "socks5". Якщо ця конфігурація не надана або порожній рядок, клієнт спробує створити конфігурацію проксі з змінних середовища http_proxy та https_proxy. Якщо ці змінні середовища не встановлені, клієнт не спробує проксіювати запити.

Проксіювання socks5 наразі не підтримує точки доступу потокової передачі spdy (exec, attach, port forward).

disable-compression
bool

DisableCompression дозволяє клієнту відмовитися від стиснення відповіді для всіх запитів до сервера. Це корисно для прискорення запитів (зокрема списків), коли пропускна здатність мережі між клієнтом і сервером достатня, заощаджуючи час на стисненні (на стороні сервера) та розпакуванні (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання і запис не пошкоджували невідомі поля

Context

Зʼявляється в:

Context — це набір посилань на кластер (як спілкуватись з кластером Kubernetes), користувача (як користувач ідентифікує себе) і простір імен (з якою підмножиною ресурсів стандартно працювати)

ПолеОпис
cluster [Обовʼязково]
string

Cluster —це імʼя кластера для цього контексту

user [Обовʼязково]
string

AuthInfo — це імʼя authInfo для цього контексту

namespace
string

Namespace — це стандартний простір імен, який використовується для запитів, де простір імен не вказаний

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання і запис не пошкоджували невідомі поля

ExecConfig

Зʼявляється в:

ExecConfig визначає команду для надання клієнтських облікових даних. Команда виконується і виводить структурований stdout, що містить облікові дані.

Дивіться групу API client.authentication.k8s.io для специфікацій точного формату вводу та виводу.

ПолеОпис
command [Обовʼязково]
string

Команда для виконання.

args
[]string

Аргументи для передачі команді під час її виконання.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища для експонування процесу. Вони обʼєднуються з середовищем хосту, а також зі змінними, які client-go використовує для передачі аргументів втулку.

apiVersion [Обовʼязково]
string

Бажана версія введення ExecInfo. Повернені ExecCredentials МАЮТЬ використовувати те ж саме кодування версії, що й ввод.

installHint [Обовʼязково]
string

Цей текст показується користувачеві, коли виконуваний файл здається відсутнім. Наприклад, brew install foo-cli може бути гарною підказкою для встановлення foo-cli на системах Mac OS.

provideClusterInfo [Обовʼязково]
bool

ProvideClusterInfo визначає, чи слід надавати інформацію про кластер, яка може потенційно містити дуже великі дані CA, цьому exec втулку як частину змінної середовища KUBERNETES_EXEC_INFO. Стандартно встановлено на false. Пакет k8s.io/client-go/tools/auth/exec надає допоміжні методи для отримання цієї змінної середовища.

interactiveMode
ExecInteractiveMode

InteractiveMode визначає звʼязки цього втулку зі стандартним вводом. Дійсні значення: "Never" (цей exec втулок ніколи не використовує стандартний ввод), "IfAvailable" (цей exec втулок хоче використовувати стандартний ввод, якщо він доступний) або "Always" (цей exec втулок вимагає стандартний ввод для функціонування). Див. значення ExecInteractiveMode для більш детальної інформації.

Якщо APIVersion — client.authentication.k8s.io/v1alpha1 або client.authentication.k8s.io/v1beta1, то це поле є необовʼязковим і стандартно встановлено у "IfAvailable" при відсутності значення. В іншому випадку це поле є обовʼязковим.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для налаштування змінних середовища під час виконання втулка облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string		Опис не надано.
value [Обовʼязково]
string		Опис не надано.

ExecInteractiveMode

(Аліас для string)

Зʼявляється в:

ExecInteractiveMode є рядком, який описує взаємодію exec втулка зі стандартним вводом.

NamedAuthInfo

Зʼявляється в:

NamedAuthInfo повʼязує псевдоніми з інформацією для автентифікації.

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цієї AuthInfo

user [Обовʼязкове]
AuthInfo

AuthInfo містить інформацію для автентифікації

NamedCluster

Зʼявляється в:

NamedCluster повʼязує псевдоніми з інформацією про кластер.

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цього кластера

cluster [Обовʼязкове]
Cluster

Cluster містить інформацію про кластер

NamedContext

Зʼявляється в:

NamedContext повʼязує псевдоніми з інформацією про контекст

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цього контексту

context [Обовʼязкове]
Context

Context містить інформацію про контекст

NamedExtension

Зʼявляється в:

NamedExtension повʼязує псевдоніми з інформацією про розширення

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цього розширення

extension [Обовʼязкове]
k8s.io/apimachinery/pkg/runtime.RawExtension

Extension містить інформацію про розширення

Preferences

Зʼявляється в:

ПолеОпис
colors
bool		Опис не надано.
extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання і запис не пошкоджували невідомі поля

14.16 - Kubelet Configuration (v1)

Типы ресурсов

CredentialProviderConfig

CredentialProviderConfig є конфігурацією, що містить інформацію про кожного exec credential provider. Kubelet читає цю конфігурацію з диска та активує кожного провайдера відповідно до типу CredentialProvider.

ПолеОпис
apiVersion
string		kubelet.config.k8s.io/v1
kind
string		CredentialProviderConfig
providers [Обовʼязково]
[]CredentialProvider

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

CredentialProvider

Зʼявляється в:

CredentialProvider представляє exec втулок, який буде викликаний kubelet. Втулок викликається лише тоді, коли образ, що завантажується, відповідає образам, які обробляє втулок (див. matchImages).

ПолеОпис
name [Обовʼязково]
string

name є обовʼязковим імʼям провайдера облікових даних. Назва повинна відповідати імені виконуваного файлу провайдера, яке бачить kubelet. Виконуваний файл повинен бути в директорії bin kubelet (встановленій за допомогою прапорця --image-credential-provider-bin-dir).

matchImages [Обовʼязково]
[]string

matchImages є обовʼязковим списком рядків, які використовуються для зіставлення з образами, щоб визначити, чи потрібно викликати цього провайдера. Якщо один з рядків відповідає запитаному образу від kubelet, втулок буде викликаний і отримає можливість надати облікові дані. Образи повинні містити домен реєстрації та URL шлях.

Кожен запис у matchImages є шаблоном, який може містити порт і шлях. Глоби можна використовувати в домені, але не в порті чи шляху. Глоби підтримуються як піддомени, наприклад '*.k8s.io' або 'k8s.*.io', та топ-рівневі домени, такі як 'k8s.*'. Підмножки часткових піддоменів, такі як 'app*.k8s.io', також підтримуються. Кожен глоб може відповідати тільки одному сегменту піддомену, тому '*.io' не відповідає '*.k8s.io'.

Зіставлення існує між образом і matchImage, коли всі з нижченаведених умов є істинними:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • URL шлях образу має бути префіксом цільового URL шляху образу.
  • Якщо imageMatch містить порт, порт також повинен мати збіг в образі.

Приклади значень matchImages:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path
defaultCacheDuration [Обовʼязково]
meta/v1.Duration

defaultCacheDuration є стандартною тривалістю, впродовж якої втулок кешуватиме облікові дані в памʼяті, якщо тривалість кешу не надана у відповіді втулка. Це поле є обовʼязковим.

apiVersion [Обовʼязково]
string

Обовʼязкова версія вхідного exec CredentialProviderRequest. Повернута CredentialProviderResponse МУСИТЬ використовувати таку ж версію кодування, як і вхідна. Поточні підтримувані значення:

  • credentialprovider.kubelet.k8s.io/v1
args
[]string

Аргументи для передачі команді при її виконанні.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища для передачі процесу. Вони обʼєднуються з середовищем хоста, а також змінними, які client-go використовує для передачі аргументів втулку.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для встановлення змінних середовища при виконанні втулка для облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string		Опис не надано.
value [Обовʼязково]
string		Опис не надано.

14.17 - Kubelet Configuration (v1alpha1)

Типи ресурсів

CredentialProviderConfig

CredentialProviderConfig є конфігурацією, що містить інформацію про кожен втулок облікових даних exec. Kubelet читає цю конфігурацію з диска та активує кожен втулок відповідно до типу CredentialProvider.

ПолеОпис
apiVersion
string		kubelet.config.k8s.io/v1alpha1
kind
string		CredentialProviderConfig
providers [Обовʼязково]
[]CredentialProvider

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

CredentialProvider

Зʼявляється в:

CredentialProvider представляє втулок exec, який буде викликаний kubelet. Втулок буде викликаний тільки тоді, коли образ, який завантажується, відповідає образам, які підтримуються втулком (див. matchImages).

ПолеОпис
name [Обовʼязково]
string

name є обовʼязковою назвою постачальника облікових даних. Назва повинна відповідати назві виконуваного файлу постачальника, як його бачить kubelet. Виконуваний файл повинен знаходитися в теці bin kubelet (встановленій за допомогою прапорця --image-credential-provider-bin-dir).

matchImages [Обовʼязково]
[]string

matchImages є обовʼязковим списком рядків, які використовуються для зіставлення з образами, щоб визначити, чи потрібно викликати цього провайдера. Якщо один з рядків відповідає запитаному образу від kubelet, втулок буде викликаний і отримає можливість надати облікові дані. Образи повинні містити домен реєстрації та URL шлях.

Кожен запис у matchImages є шаблоном, який може містити порт і шлях. Глоби можуть використовуватися в домені, але не в порту чи шляху. Глоби підтримуються як піддомени, такі як *.k8s.io або k8s.*.io, і домени верхнього рівня, такі як k8s.*. Піддомени з частковими збігами, такі як app*.k8s.io, також підтримуються. Кожен шаблон може відповідати лише одному сегменту піддомена, тому *.io не відповідає *.k8s.io.

Відповідність існує між образами і matchImage, коли все з наведеного нижче є істинними:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • Шлях URL образу matchImage повинен бути префіксом шляху URL цільового образу.
  • Якщо imageMatch містить порт, порт також повинен мати збіг в образі.

Приклади значень matchImages:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path
defaultCacheDuration [Обовʼязково]
meta/v1.Duration

defaultCacheDuration є стандартною тривалістю, впродовж якої втулок кешуватиме облікові дані в памʼяті, якщо тривалість кешу не надана у відповіді втулка. Це поле є обовʼязковим.

apiVersion [Обовʼязково]
string

Обовʼязкова версія вхідного exec CredentialProviderRequest. Повернута CredentialProviderResponse МУСИТЬ використовувати таку ж версію кодування, як і вхідна. Поточні підтримувані значення:

  • credentialprovider.kubelet.k8s.io/v1alpha1
args
[]string

Аргументи, які слід передати команді при її виконанні.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища, які слід надати процесу. Вони обʼєднуються з середовищем хоста, а також з змінними, які використовує client-go для передачі аргументів втулку.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для встановлення змінних середовища при виконанні втулка облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string		Опис не надано.
value [Обовʼязково]
string		Опис не надано.

14.18 - Kubelet Configuration (v1beta1)

Типи ресурсів

FormatOptions

Зʼявляється в:

FormatOptions містить параметри для різних форматів логування.

ПолеОпис
text [Обовʼязково]
TextOptions

[Alpha] Text містить параметри для формату логування "text". Доступно лише при увімкненій функціональній можливості LoggingAlphaOptions.

json [Обовʼязково]
JSONOptions

[Alpha] JSON містить параметри для формату журналювання "json". Доступно лише при увімкненій функціональній можливості LoggingAlphaOptions.

JSONOptions

Зʼявляється в:

JSONOptions містить параметри для формату логування "json".

ПолеОпис
OutputRoutingOptions [Обовʼязково]
OutputRoutingOptions		(Члени OutputRoutingOptions вбудовані в цей тип.) Опис не надано.

LogFormatFactory

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

LoggingConfiguration

Зʼявляється в:

LoggingConfiguration містить параметри для логування.

ПолеОпис
format [Обовʼязково]
string

Format Flag визначає структуру повідомлень логу. Станадртне значення для формату — text

flushFrequency [Обовʼязково]
TimeOrMetaDuration

Максимальний час між очищенням логів. Якщо рядок, розбирається як тривалість (наприклад, "1s"). Якщо ціле число, максимальна кількість наносекунд (наприклад, 1с = 1000000000). Ігнорується, якщо обраний механізм логування записує повідомлення без буферизації.

verbosity [Обовʼязково]
VerbosityLevel

Verbosity є порогом, який визначає, які повідомлення логу записуються. Стандартне значення — нуль, що записує лише найбільш важливі повідомлення. Більші значення дозволяють додаткові повідомлення. Повідомлення про помилки завжди записуються.

vmodule [Обовʼязково]
VModuleConfiguration

VModule переозначає поріг детальності для окремих файлів. Підтримується тільки для формату логу "text".

options [Обовʼязково]
FormatOptions

[Alpha] Options містить додаткові параметри, специфічні для різних форматів логування. Використовуються лише параметри для обраного формату, але всі вони перевіряються. Доступно тільки при увімкненій функціональній можливості LoggingAlphaOptions.

LoggingOptions

LoggingOptions можна використовувати з ValidateAndApplyWithOptions для перевизначення деяких глобальних стандартних значень.

ПолеОпис
ErrorStream [Обовʼязково]
io.Writer

ErrorStream можна використовувати для перевизначення стандартного значення os.Stderr.

InfoStream [Обовʼязково]
io.Writer

InfoStream можна використовувати для перевизначення стандартного значення os.Stdout.

OutputRoutingOptions

Зʼявляється в:

OutputRoutingOptions містить параметри, що підтримуються як для формату "text", так і для "json".

ПолеОпис
splitStream [Обовʼязково]
bool

[Alpha] SplitStream перенаправляє повідомлення про помилки на stderr, тоді як інформаційні повідомлення відправляються на stdout з буферизацією. Стандартне значення — записувати обидва потоки у stdout без буферизації. Доступно тільки коли увімкнено функціональну можливість LoggingAlphaOptions.

infoBufferSize [Обовʼязково]
k8s.io/apimachinery/pkg/api/resource.QuantityValue

[Alpha] InfoBufferSize встановлює розмір інформаційного потоку при використанні розділених потоків. Стандартне значення — нуль, що вимикає буферизацію. Доступно тільки коли увімкнено функціональну можливість LoggingAlphaOptions.

TextOptions

Зʼявляється в:

TextOptions містить параметри для формату логування "text".

ПолеОпис
OutputRoutingOptions [Обовʼязково]
OutputRoutingOptions		(Члени OutputRoutingOptions вбудовані в цей тип.) Опис не надано.

TimeOrMetaDuration

Зʼявляється в:

TimeOrMetaDuration присутній лише для зворотної сумісності з полем flushFrequency, і нові поля повинні використовувати metav1.Duration.

ПолеОпис
Duration [Обовʼязково]
meta/v1.Duration

Duration містить тривалість

- [Обовʼязково]
bool

SerializeAsString контролює, чи буде значення серіалізоване як рядок чи ціле число

TracingConfiguration

Зʼявляється в:

TracingConfiguration надає версіоновану конфігурацію для клієнтів OpenTelemetry tracing.

ПолеОпис
endpoint
string

Endpoint колектора, до якого цей компонент буде відправляти трасування. Зʼєднання не є захищеним і наразі не підтримує TLS. Рекомендується не задавати, і endpoint буде за замовчуванням otlp grpc, localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — кількість зразків для збору на мільйон спанів. Рекомендується не задавати. Якщо не задано, пробник поважає темп рідного спану, але в іншому випадку ніколи не здійснює пробу.

VModuleConfiguration

(Аліас для []k8s.io/component-base/logs/api/v1.VModuleItem)

Зʼявляється в:

VModuleConfiguration — це колекція окремих імен файлів або шаблонів та відповідний поріг докладності.

VerbosityLevel

(Аліас для uint32)

Зʼявляється в:

VerbosityLevel представляє поріг докладності для klog або logr.

CredentialProviderConfig

CredentialProviderConfig — це конфігурація, яка містить інформацію про кожного постачальника облікових даних exec. Kubelet зчитує цю конфігурацію з диска та активує кожного постачальника, як зазначено в типі CredentialProvider.

ПолеОпис
apiVersion
string		kubelet.config.k8s.io/v1beta1
kind
string		CredentialProviderConfig
providers [Обовʼязково]
[]CredentialProvider

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

KubeletConfiguration

KubeletConfiguration містить конфігурацію для Kubelet.

ПолеОпис
apiVersion
string		kubelet.config.k8s.io/v1beta1
kind
string		KubeletConfiguration
enableServer [Обовʼязково]
bool

enableServer вмикає захищений сервер Kubelet. Примітка: незахищений порт Kubelet контролюється параметром readOnlyPort. Стандартне значення: true

staticPodPath
string

staticPodPath — це шлях до теки з локальними (статичними) Podʼами для запуску, або шлях до окремого статичного файлу Podʼа. Стандартно: ""

podLogsDir
string

podLogsDir - власний шлях до кореневої теки, який kubelet використовуватиме для розміщення лог-файлів под'ів. Стандартно: "/var/log/pods/" Примітка: не рекомендується використовувати теку temp як теку логу, оскільки це може спричинити неочікувану поведінку у багатьох місцях.

syncFrequency
meta/v1.Duration

syncFrequency — максимальний період між синхронізацією запущених контейнерів і конфігурацією. Стандартно: "1m"];

fileCheckFrequency
meta/v1.Duration

fileCheckFrequency — тривалість між перевірками конфігураційних файлів на наявність нових даних. Стандартно: "20s"];

httpCheckFrequency
meta/v1.Duration

httpCheckFrequency — інтервал між перевірками http на наявність нових даних. Стандартно: "20s"];

staticPodURL
string

staticPodURL — це URL-адреса для доступу до статичних Podʼів для запуску. Стандартно: ""

staticPodURLHeader
map[string][]string

staticPodURLHeader — map slice із заголовками HTTP, які потрібно використовувати при доступі до podURL. Стандартно: nil

address
string

address — IP-адреса, на якій буде працювати Kubelet (встановлено на 0.0.0.0 для всіх інтерфейсів). Стандартно: "0.0.0.0";

port
int32

port — це порт, на якому буде обслуговуватися Kubelet. Номер порту має бути в діапазоні від 1 до 65535 включно. Стандартно: 10250

readOnlyPort
int32

readOnlyPort - це порт тільки для читання, на якому Kubelet буде працювати без автентифікації/авторизації. Номер порту повинен бути в діапазоні від 1 до 65535 включно. Встановлення цього поля у 0 вимикає сервіс тільки для читання. Стандартно: 0 (вимкнено)

tlsCertFile
string

tlsCertFile — файл, що містить сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо tlsCertFile і tlsPrivateKeyFile не вказано, самопідписаний сертифікат і ключ генеруються для публічної адреси і зберігаються у теці, яку передано у прапорці Kubelet --cert-dir. Стандартно: ""

tlsPrivateKeyFile
string

tlsPrivateKeyFile — файл, що містить приватний ключ x509, який відповідає tlsCertFile. Стандартно: ""

tlsCipherSuites
[]string

tlsCipherSuites — список дозволених наборів шифрів для сервера. Зверніть увагу, що набори шифрів TLS 1.3 не налаштовуються. Значення беруться з констант пакета tls (https://golang.org/pkg/crypto/tls/#pkg-constants). Стандартно: nil

tlsMinVersion
string

tlsMinVersion — мінімальна підтримувана версія TLS. Значення беруться з констант пакета tls (https://golang.org/pkg/crypto/tls/#pkg-constants). Стандартно: ""

rotateCertificates
bool

rotateCertificates дозволяє ротацію клієнтських сертифікатів. Kubelet запросить новий сертифікат з API certificates.k8s.io. Для цього потрібен затверджувач, який схвалює запити на підписання сертифікатів. Стандартно: false

serverTLSBootstrap
bool

serverTLSBootstrap вмикає bootstrap серверного сертифікату. Замість того, щоб самостійно підписувати серверний сертифікат, Kubelet буде запитувати сертифікат з API 'certificates.k8s.io'. Для цього потрібен затверджувач для схвалення запитів на підписання сертифікатів (CSR). Функція RotateKubeletServerCertificate має бути ввімкнена при встановленні цього поля. Стандартно: false

authentication
KubeletAuthentication

authentication визначає спосіб автентифікації запитів до сервера Kubelet. Стандартно:

anonymous:
  enabled: false
webhook:
  enabled: true
  cacheTTL: "2m"

authorization
KubeletAuthorization

authorization визначає спосіб авторизації запитів до сервера Kubelet. Стандартно:

mode: Webhook
webhook:
  cacheAuthorizedTTL: "5m"
  cacheUnauthorizedTTL: "30s"

registryPullQPS
int32

registryPullQPS — ліміт отримання образів з реєстру за секунду. Значення не повинно бути відʼємним числом. Встановлення значення 0 означає відсутність обмеження. Стандартно: 5

registryBurst
int32

registryBurst — максимальний розмір стрімких витягань, тимчасово дозволяє стрімким витяганням досягати цього числа, але при цьому не перевищувати registryPullQPS. Значення не повинно бути відʼємним числом. Використовується тільки якщо registryPullQPS більше 0. Стандартно: 10

eventRecordQPS
int32

eventRecordQPS — максимальна кількість створених подій за секунду. Якщо 0, то обмеження не застосовується. Значення не може бути відʼємним. Стандартно: 50

eventBurst
int32

eventBurst - максимальний розмір сплеску створення подій, тимчасово дозволяє створювати події до цього числа, але не більше ніж eventRecordQPS. Це поле не може бути відʼємним числом і використовується лише тоді, коли eventRecordQPS > 0. Стандартно: 100

enableDebuggingHandlers
bool

enableDebuggingHandlers вмикає точки доступу до логів на сервері та локальний запуск контейнерів і команд, включно з функціями exec, attach, logs та portforward. Стандартно: true

enableContentionProfiling
bool

enableContentionProfiling вмикає профілювання блоків, якщо enableDebuggingHandlers має значення true. Стандартно: false

healthzPort
int32

healthzPort — порт точки доступу localhost healthz (для вимкнення встановлюється на 0). Допустиме значення від 1 до 65535. Стандартне значення: 10248

healthzBindAddress
string

healthzBindAddress - IP-адреса для сервера healthz. Стандартно: "127.0.0.1";

oomScoreAdj
int32

oomScoreAdj — значення oom-score-adj для процесу kubelet. Значення має бути в діапазоні [-1000, 1000]. Стандартно: -999

clusterDomain
string

clusterDomain — DNS-домен для цього кластера. Якщо задано, kubelet налаштує всі контейнери на пошук у цьому домені на додаток до пошукових доменів хоста. Стандартно: ""

clusterDNS
[]string

clusterDNS — список IP-адрес для DNS-сервера кластера. Якщо встановлено, kubelet налаштує всі контейнери на використання цього списку для DNS-розпізнавання замість DNS-серверів хоста. Стандартно: nil

streamingConnectionIdleTimeout
meta/v1.Duration

streamingConnectionIdleTimeout — максимальний час, протягом якого потокове зʼєднання може простоювати, перш ніж зʼєднання буде автоматично закрито. Стандартно: "4h";

nodeStatusUpdateFrequency
meta/v1.Duration

nodeStatusUpdateFrequency - частота, з якою kubelet обчислює статус вузла. Якщо функцію оренди вузлів не увімкнено, це також частота, з якою kubelet надсилає статус вузла майстру. Примітка: Якщо функцію оренди вузла не увімкнено, будьте обережні при зміні константи, вона має працювати з nodeMonitorGracePeriod у nodecontroller. Стандартно: "10s"

nodeStatusReportFrequency
meta/v1.Duration

nodeStatusReportFrequency — частота, з якою kubelet надсилає статус вузла майстру, якщо статус вузла не змінюється. Kubelet ігноруватиме цю частоту і відправлятиме статус вузла негайно, якщо буде виявлено будь-яку зміну. Використовується лише тоді, коли увімкнено функцію оренди вузлів. nodeStatusReportFrequency має стандартне значення 5m. Але якщо nodeStatusUpdateFrequency задано явно, стандартне значення nodeStatusReportFrequency буде встановлено на nodeStatusUpdateFrequency для зворотної сумісності. Стандартно: "5m"];

nodeLeaseDurationSeconds
int32

nodeLeaseDurationSeconds - це тривалість, яку Kubelet встановить для відповідного lease. NodeLease надає індикатор справності вузла, змушуючи Kubelet створювати та періодично поновлювати договір оренди, названий на честь вузла, у просторі імен kube-node-lease. Якщо термін дії договору закінчується, вузол можна вважати несправним. Наразі оренда поновлюється кожні 10 секунд, згідно з KEP-0009. У майбутньому інтервал поновлення оренди може бути встановлений на основі тривалості оренди. Значення поля має бути більше 0. Стандартно: 40

imageMinimumGCAge
meta/v1.Duration

imageMinimumGCAge — мінімальний вік невикористаного образу перед тим, як його буде вилучено. Стандартно: "2m"];

imageMaximumGCAge
meta/v1.Duration

imageMaximumGCAge — максимальний вік, протягом якого образ може бути невикористаним, перш ніж його буде вилучено у смітник. Стандартне значення цього поля - "0s", що вимикає це поле - тобто образи не буде вилучено у смітник через те, що їх не було використано надто довго. Стандартно: "0s" (вимкнено)

imageGCHighThresholdPercent
int32

imageGCHighThresholdPercent — це відсоток використання диска, після якого завжди запускається прибирання образів. Відсоток обчислюється діленням значення цього поля на 100, тому значення цього поля має бути від 0 до 100 включно. Якщо вказано, значення має бути більшим за imageGCLowThresholdPercent. Стандартно: 85

imageGCLowThresholdPercent
int32

imageGCLowThresholdPercent — це відсоток використання диска, до якого прибирання образів ніколи не виконуватиметься. Найнижчий відсоток використання диска для збирання сміття. Відсоток обчислюється діленням значення цього поля на 100, тому значення поля має бути у діапазоні від 0 до 100 включно. Якщо вказано, значення має бути меншим за imageGCHighThresholdPercent. Стандартно: 80

volumeStatsAggPeriod
meta/v1.Duration

volumeStatsAggPeriod — це частота для обчислення та кешування обсягу використання диска для всіх Podʼів. Стандартно: "1m"

kubeletCgroups
string

kubeletCgroups — абсолютна назва cgroups для ізоляції kubelet. Стандартно: ""

systemCgroups
string

systemCgroups — абсолютна назва cgroups, до якої слід помістити усі неядерні процеси, які ще не знаходяться у контейнері. Порожньо, якщо немає контейнера. Скидання прапорця вимагає перезавантаження. Якщо це поле не порожнє, слід вказати cgroupRoot. Стандартно: ""

cgroupRoot
string

cgroupRoot - це коренева cgroup, яку слід використовувати для Podʼів. Ця група обробляється під час виконання контейнера на основі принципу найкращих зусиль.

cgroupsPerQOS
bool

cgroupsPerQOS вмикає ієрархію CGroup на основі QoS: CGroups верхнього рівня для класів QoS і всі Burstable та BestEffort Pods підпорядковуються певній CGroup QoS верхнього рівня. Стандартно: true

cgroupDriver
string

cgroupDriver — це драйвер, який kubelet використовує для керування CGroups на хості (cgroupfs або systemd). Стандартно: "cgroupfs";

cpuManagerPolicy
string

cpuManagerPolicy - назва політики, яку буде використано. Потребує увімкнення функціональних можливостей CPUManager. Стандартно: "None"

cpuManagerPolicyOptions
map[string]string

cpuManagerPolicyOptions — це набір key=value, який дозволяє встановити додаткові опції для точного налаштування поведінки політик диспетчера процесорів. Потребує увімкнення функціональних можливостей "CPUManager" та "CPUManagerPolicyOptions". Стандартно: nil

cpuManagerReconcilePeriod
meta/v1.Duration

cpuManagerReconcilePeriod - період узгодження для CPU Manager. Потребує увімкнення функціональної можливості CPUManager. Стандартне значення: "10s"

memoryManagerPolicy
string

memoryManagerPolicy - назва політики, яку використовуватиме менеджер памʼяті. Потребує увімкнення функціональної можливості MemoryManager. Стандартно: "none"

topologyManagerPolicy
string

topologyManagerPolicy — назва політики менеджера топології, яку слід використовувати. Допустимі значення включають:

  • restricted: kubelet дозволяє лише ті Podʼи, які мають оптимальне вирівнювання вузлів NUMA для запитуваних ресурсів;
  • best-effort: kubelet надаватиме перевагу Podʼам з NUMA-вирівнюванням ресурсів процесора та пристроїв;
  • none: kubelet не знає про вирівнювання NUMA ресурсів процесора та пристроїв під час роботи.
  • single-numa-node: kubelet дозволяє використовувати лише Podʼи з єдиним NUMA-вирівнюванням ресурсів процесора та пристроїв.

Default: "none"

topologyManagerScope
string

topologyManagerScope представляє обсяг генерації підказок топології, які запитує менеджер топології та генерують постачальники підказок. Допустимі значення включають:

  • container: політика топології застосовується для кожного контейнера окремо.
  • pod: політика топології застосовується на основі кожного окремого блоку.

Default: "container"

topologyManagerPolicyOptions
map[string]string

TopologyManagerPolicyOptions - це набір key=value, який дозволяє встановити додаткові опції для точного налаштування поведінки політик менеджера топології. Потребує увімкнення обох функціональних можливостей — "TopologyManager" та "TopologyManagerPolicyOptions". Стандартно: nil

qosReserved
map[string]string

qosReserved — це набір пар імені ресурсу та відсотка, які визначають мінімальний відсоток ресурсу, зарезервований для ексклюзивного використання на рівні гарантованого QoS. Наразі підтримувані ресурси: "памʼять" Потребує увімкнення функціональної можливості QOSReserved. Стандартно: nil

runtimeRequestTimeout
meta/v1.Duration

runtimeRequestTimeout — це таймаут для всіх запитів часу виконання, окрім довготривалих запитів — pull, logs, exec та attach. Стандартно: "2m"

hairpinMode
string

hairpinMode вказує, як Kubelet має налаштувати міст контейнера для пакета hairpin. Встановлення цього прапорця дозволяє точкам доступу в Service перерозподіляти навантаження на себе, якщо вони намагаються отримати доступ до свого власного Service. Значення:

  • "promiscuous-bridge": зробити контейнерний міст невпорядкованим.
  • "hairpin-veth": встановити прапорець hairpin на інтерфейсах container veth.
  • "none": нічого не робити.

Зазвичай, для досягнення hairpin NAT потрібно встановити --hairpin-mode=hairpin-veth, оскільки promiscuous-bridge передбачає наявність контейнерного моста з назвою cbr0. Стандартно: "promiscuous-bridge"

maxPods
int32

maxPods — максимальна кількість Podʼів, які можуть бути запущені на цьому Kubelet. Значення має бути цілим невідʼємним числом. Стандартно: 110

podCIDR
string

podCIDR — це CIDR для IP-адрес pod, який використовується лише в режимі standalone. У кластерному режимі він отримується з панелі управління. Стандартно: ""

podPidsLimit
int64

podPidsLimit — максимальна кількість PID у будь-якому pod. Default: -1

resolvConf
string

resolvConf — це файл конфігурації резолвера, який використовується як основа для налаштування DNS-резолюції контейнера. Якщо встановлено порожній рядок, він перевизначає стандартне значення і фактично вимикає DNS-запити. Стандартно: "/etc/resolv.conf"

runOnce
bool

runOnce змушує Kubelet один раз перевірити сервер API на наявність Podʼів, запустити ті з них, які вказані у статичних файлах Podʼів, і вийти. Стандартно: false

cpuCFSQuota
bool

cpuCFSQuota вмикає застосування квоти CPU CFS для контейнерів, які визначають ліміти процесора. Стандартно: true

cpuCFSQuotaPeriod
meta/v1.Duration

cpuCFSQuotaPeriod — це значення періоду квоти CFS процесора, cpu.cfs_period_us. Значення має бути від 1 мс до 1 секунди включно. Потребує увімкнення функціональної можливості CustomCPUCFSQuotaPeriod. Стандартно: "100ms";

nodeStatusMaxImages
int32

nodeStatusMaxImages обмежує кількість зображень, про які повідомляється у Node.status.images. Значення має бути більшим за -2. Зауваження: Якщо вказано -1, обмеження не буде застосовано. Якщо вказано 0, жодного образу не буде повернуто. Стандартно: 50

maxOpenFiles
int64

maxOpenFiles - кількість файлів, які може відкрити процес Kubelet. Значення має бути невідʼємним числом. Стандартно: 1000000

contentType
string

contentType — тип вмісту запитів, що надсилаються до apiserver. Стандартно: "application/vnd.kubernetes.protobuf";

kubeAPIQPS
int32

kubeAPIQPS - це QPS, який слід використовувати під час спілкування з apiserver'ом kubernetes. Стандартно: 50

kubeAPIBurst
int32

kubeAPIBurst — це кількість пакетів, які слід дозволити під час спілкування з сервером API kubernetes. Це поле не може бути відʼємним числом. Стандартно: 100

serializeImagePulls
bool

serializeImagePulls, якщо увімкнено, вказує Kubelet завантажувати образи один за одним. Ми рекомендуємо не змінювати стандартні значення на вузлах, де працює демон docker версії < 1.9 або сховище Aufs. Деталі наведено у Issue #10959. Стандартно: true

maxParallelImagePulls
int32

MaxParallelImagePulls задає максимальну кількість паралельних завантажень образів. Це поле не можна встановити, якщо SerializeImagePulls має значення true. Встановлення значення nil означає відсутність обмежень. Стандартно: nil

evictionHard
map[string]string

evictionHard — це map назв сигналів до величин, що визначає жорсткі пороги виселення. Наприклад: {"memory.available": "300Mi"}. Щоб явно вимкнути, передайте порогове значення 0% або 100% для довільного ресурсу. Стандартно:

memory.available:  "100Mi"
nodefs.available:  "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"

evictionSoft
map[string]string

evictionSoft це map імен сигналів до величин, яка визначає мʼякі пороги виселення. Наприклад: {"memory.available": "300Mi"}. Стандартно: nil

evictionSoftGracePeriod
map[string]string

evictionSoftGracePeriod це map назв сигналів до величин, яка визначає пільгові періоди для кожного сигналу мʼякого виселення. Наприклад: {"memory.available": "30s"}. Стандартно: nil

evictionPressureTransitionPeriod
meta/v1.Duration

evictionPressureTransitionPeriod — це тривалість, протягом якої kubelet має зачекати, перш ніж вийти зі стану тиску витіснення. Стандартно: "5m"

evictionMaxPodGracePeriod
int32

evictionMaxPodGracePeriod - це максимально дозволений пільговий період (у секундах), який можна використовувати при завершенні роботи pods у відповідь на досягнення порогу мʼякого виселення. Це значення фактично обмежує значення terminationGracePeriodSeconds під час мʼякого виселення. Примітка: У звʼязку з issue #64530 у поведінці є помилка, коли це значення наразі просто перевизначає пільговий період під час мʼякого виселення, що може збільшити пільговий період порівняно з тим, що встановлено в Pod. Ця помилка буде виправлена в наступному випуску. Стандартно: 0

evictionMinimumReclaim
map[string]string

evictionMinimumReclaim це map імен сигналів до величин, що визначає мінімальні відновлення, які описують мінімальну кількість заданого ресурсу, яку kubelet буде відновлювати при виконанні виселення pod, поки цей ресурс знаходиться під тиском. Наприклад: {"imagefs.available": "2Gi"}. Стандартно: nil

podsPerCore
int32

podsPerCore — максимальна кількість Podʼів на ядро. Не може перевищувати maxPods. Значення має бути цілим невідʼємним числом. Якщо 0, то немає обмеження на кількість Podʼів. Стандартно: 0

enableControllerAttachDetach
bool

enableControllerAttachDetach дозволяє контролеру Attach/Detach керувати приєднанням/відʼєднанням томів, запланованих для цього вузла, і забороняє kubelet виконувати будь-які операції приєднання/відʼєднання. Зауваження: приєднання/відʼєднання томів CSI не підтримується kubelet, тому для цього варіанту використання ця опція має мати значення true. Стандартно: true

protectKernelDefaults
bool

protectKernelDefaults, якщо значення true, призводить до помилки Kubelet, якщо прапорці ядра не відповідають його очікуванням. В іншому випадку Kubelet спробує змінити прапорці ядра так, щоб вони відповідали його очікуванням. Стандартно: false

makeIPTablesUtilChains
bool

makeIPTablesUtilChains, якщо значення true, змушує Kubelet створювати ланцюжок KUBE-IPTABLES-HINT у iptables як підказку іншим компонентам про конфігурацію iptables у системі. Стандартно: true

iptablesMasqueradeBit
int32

iptablesMasqueradeBit раніше контролював створення ланцюжка KUBE-MARK-MASQ. Застарілий: більше не має жодного впливу. Стандартно: 14

iptablesDropBit
int32

iptablesDropBit раніше контролював створення ланцюжка KUBE-MARK-DROP. Застаріла: більше не має жодного впливу. Стандартно: 15

featureGates
map[string]bool

featureGates - це map імен функціональних можливостей до bools, які вмикають або вимикають експериментальні можливості. Це поле змінює вбудовані стандартні значення з "k8s.io/kubernetes/pkg/features/kube_features.go". Стандартно: nil

failSwapOn
bool

failSwapOn вказує Kubelet не запускатися, якщо на вузлі увімкнено підкачку. Стандартно: true

memorySwap
MemorySwapConfiguration

memorySwap налаштовує памʼять підкачки, доступну для контейнерних робочих навантажень.

containerLogMaxSize
string

containerLogMaxSize — величина, що визначає максимальний розмір лог-файлу контейнера перед його ротацією. Наприклад: "5Mi" або "256Ki". Стандартно: "10Mi"";

containerLogMaxFiles
int32

containerLogMaxFiles визначає максимальну кількість файлів логу контейнера, які можуть бути присутніми для контейнера. Стандартно: 5

containerLogMaxWorkers
int32

ContainerLogMaxWorkers визначає максимальну кількість паралельних робочих процесів для виконання операцій ротації логів. Встановіть це значення рівним 1, щоб вимкнути паралельні робочі процеси ротації логу. Стандартно: 1

containerLogMonitorInterval
meta/v1.Duration

ContainerLogMonitorInterval визначає тривалість, протягом якої контейнерні логи відстежуються для виконання операції ротації логів. Стандартно це значення дорівнює 10 * time.Seconds. Але його можна налаштувати на менше значення залежно від частоти генерації логів і розміру, щодо якого потрібно виконати ротацію. Стандартно: 10s

configMapAndSecretChangeDetectionStrategy
ResourceChangeDetectionStrategy

configMapAndSecretChangeDetectionStrategy - режим, у якому працюють менеджери ConfigMap і Secret. Допустимі значення включають:

  • Get: kubelet отримує необхідні обʼєкти безпосередньо з сервера API;
  • Cache: kubelet використовує TTL кеш для обʼєктів, отриманих з сервера API;
  • Watch: kubelet використовує watch для спостереження за змінами в обʼєктах, які його цікавлять.

Default: "Watch"

systemReserved
map[string]string

systemReserved - це набір пар ResourceName=ResourceQuantity (наприклад, cpu=200m,memory=150G), які описують ресурси, зарезервовані для компонентів, що не належать до kubernetes. Наразі підтримуються лише процесор і памʼять. Дивіться http://kubernetes.io/docs/user-guide/compute-resources для більш детальної інформації. Стандартно: nil

kubeReserved
map[string]string

kubeReserved — це набір пар ResourceName=ResourceQuantity (наприклад, cpu=200m,memory=150G), які описують ресурси, зарезервовані для компонентів системи kubernetes. Наразі підтримуються процесор, памʼять та локальне сховище для кореневої файлової системи. Більш детальну інформацію можна знайти на сторінці https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/. Стандартно: nil

reservedSystemCPUs [Обовʼязково]
string

Параметр reservedSystemCPUs визначає список процесорів, зарезервованих для системних потоків рівня хоста та потоків, повʼязаних з kubernetes. Це забезпечує "статичний" список процесорів, а не "динамічний" список за допомогою systemReserved та kubeReserved. Цей параметр не підтримує systemReservedCgroup або kubeReservedCgroup.

showHiddenMetricsForVersion
string

showHiddenMetricsForVersion — це попередня версія, для якої ви хочете показати приховані метрики. Тільки попередня мінорна версія є значущою, інші значення не допускаються. Формат <major>.<minor>, наприклад: 1.16. Метою цього формату є забезпечення можливості помітити, якщо в наступному випуску будуть приховані додаткові метрики, а не бути здивованими, коли вони будуть остаточно видалені в наступному випуску. Стандартно: ""

systemReservedCgroup
string

systemReservedCgroup допомагає kubelet ідентифікувати абсолютну назву верхнього рівня CGroup, який використовується для забезпечення systemReserved обчислювального резервування ресурсів для системних демонів ОС. Дивіться Node Allocatable документацію для отримання додаткової інформації. Стандартно: ""

kubeReservedCgroup
string

kubeReservedCgroup допомагає kubelet ідентифікувати абсолютну назву верхнього рівня CGroup, який використовується для забезпечення KubeReserved обчислювального резервування ресурсів для системних демонів вузла Kubernetes. Дивіться Node Allocatable документацію для отримання додаткової інформації. Стандартно: ""

enforceNodeAllocatable
[]string

Цей прапорець визначає різні примусові дії Node Allocatable, які Kubelet повинен виконувати. Цей прапорець приймає список опцій. Прийнятні опції: none, pods, system-reserved і kube-reserved. Якщо вказано none, інші опції не можуть бути вказані. Коли system-reserved є в списку, має бути вказано systemReservedCgroup. Коли kube-reserved є в списку, має бути вказано kubeReservedCgroup. Це поле підтримується тільки тоді, коли cgroupsPerQOS встановлено на true. Дивіться Node Allocatable для отримання додаткової інформації. Стандартно: ["pods"]

allowedUnsafeSysctls
[]string

Список небезпечних sysctl або шаблонів sysctl, розділених комами (які закінчуються на *). Небезпечні групи sysctl включають kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.* та net.*. Наприклад: "kernel.msg*,net.ipv4.route.min_pmtu". Стандартно: []

volumePluginDir
string

volumePluginDir — це повний шлях до теки, в якій слід шукати додаткові втулки томів сторонніх розробників. Стандартно: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"

providerID
string

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

kernelMemcgNotification
bool

kernelMemcgNotification, якщо вказано, інструктує kubelet інтегруватися з нотифікацією memcg ядра для визначення, чи перевищені порогові значення памʼяті для виселення, замість опитування. Стандартно: false

logging [Обовʼязково]
LoggingConfiguration

logging вказує параметри логування. Для отримання додаткової інформації зверніться до Options for Logs. стандартно: Format: text

enableSystemLogHandler
bool

enableSystemLogHandler дозволяє отримати доступ до системних логів через веб-інтерфейс за адресою host:port/logs/. Стандартно: true

enableSystemLogQuery
bool

enableSystemLogQuery активує функцію запиту логів вузла на точці доступу /logs. Для роботи цієї функції також потрібно включити EnableSystemLogHandler. Стандартно: false

shutdownGracePeriod
meta/v1.Duration

shutdownGracePeriod вказує загальну тривалість, на яку вузол повинен затримати завершення роботи і загальний період належного завершення роботи для завершення роботи Podʼів під час завершення роботи вузла. Стандартно: "0s"

shutdownGracePeriodCriticalPods
meta/v1.Duration

shutdownGracePeriodCriticalPods вказує тривалість, що використовується для завершення критичних Podʼів під час завершення роботи вузла. Це повинно бути менше ніж shutdownGracePeriod. Наприклад, якщо shutdownGracePeriod=30s, і shutdownGracePeriodCriticalPods=10s, під час завершення роботи вузла перші 20 секунд будуть зарезервовані для мʼякого завершення роботи звичайних Podʼів, а останні 10 секунд будуть зарезервовані для завершення роботи критичних Podʼів. Стандартно: "0s"

shutdownGracePeriodByPodPriority
[]ShutdownGracePeriodByPodPriority

shutdownGracePeriodByPodPriority вказує період часу для належного завершення роботи Podʼів на основі їх значення класу пріоритету. Коли отримано запит на завершення роботи, Kubelet ініціює завершення роботи для всіх Podʼів, що працюють на вузлі, з періодом часу, що залежить від пріоритету Podʼа, і потім чекає на завершення роботи всіх Podʼів. Кожен запис у масиві представляє час належного завершення роботи для Podʼа з значенням класу пріоритету, що лежить у діапазоні цього значення та наступного вищого запису в списку під час завершення роботи вузла. Наприклад, щоб дозволити критичним Podʼам 10 секунд для завершення роботи, Podʼам з пріоритетом >=10000 — 20 секунд, а всім іншим Podʼам — 30 секунд.

shutdownGracePeriodByPodPriority:

  • priority: 2000000000 shutdownGracePeriodSeconds: 10
  • priority: 10000 shutdownGracePeriodSeconds: 20
  • priority: 0 shutdownGracePeriodSeconds: 30

Час, який Kubelet чекатиме перед завершенням роботи, буде максимумом з усіх shutdownGracePeriodSeconds для кожного діапазону класів пріоритету, представленого на вузлі. Коли всі Podʼи завершать роботу або досягнуть своїх періодівналежного завершення, Kubelet звільнить блокування інгібіції завершення роботи. Потрібно, щоб була ввімкнена функція GracefulNodeShutdown. Ця конфігурація має бути порожньою, якщо встановлено або ShutdownGracePeriod, або ShutdownGracePeriodCriticalPods. Стандартно: nil

reservedMemory
[]MemoryReservation

reservedMemory визначає список резервувань памʼяті для NUMA-вузлів, розділений комами. Цей параметр має сенс лише в контексті функції керування памʼяттю. Менеджер памʼяті не виділятиме зарезервовану памʼять для робочих навантажень контейнерів. Наприклад, якщо у вас є NUMA0 з 10Gi памʼяті, і reservedMemory було вказано для резервування 1Gi памʼяті на NUMA0, менеджер памʼяті передбачатиме, що лише 9Gi доступні для виділення. Ви можете вказати різну кількість вузлів NUMA та типів памʼяті. Ви можете взагалі опустити цей параметр, але повинні знати, що кількість зарезервованої памʼяті з усіх вузлів NUMA повинна бути рівною кількості памʼяті, вказаній у node allocatable. Якщо хоча б один параметр node allocatable має ненульове значення, вам потрібно буде вказати принаймні один вузол NUMA. Також уникайте вказування:

  1. Дублікати, той самий вузол NUMA і тип пам’яті, але з іншим значенням.
  2. нульові обмеження для будь-якого типу памʼяті.
  3. Ідентифікатори вузлів NUMAs, які не існують на машині.
  4. типи пам’яті, крім пам’яті та hugepages-

Стандартно: nil

enableProfilingHandler
bool

enableProfilingHandler дозволяє профілювання через веб-інтерфейс host:port/debug/pprof/. Стандартно: true

enableDebugFlagsHandler
bool

enableDebugFlagsHandler дозволяє доступ до прапорців через веб-інтерфейс host:port/debug/flags/v. Стандартно: true

seccompDefault
bool

SeccompDefault дозволяє використовувати RuntimeDefault як профіль seccomp стнадартно для всіх робочих навантажень. Стандартно: false

memoryThrottlingFactor
float64

MemoryThrottlingFactor визначає множник, який множиться на обмеження памʼяті або доступну памʼять вузла при встановленні значення cgroupv2 memory.high для забезпечення MemoryQoS. Зменшення цього коефіцієнта встановить нижчу високу межу для cgroups контейнера і створить більший тиск на відновлення памʼяті, тоді як збільшення зменшить тиск на відновлення. Детальніше дивіться за посиланням: KEP-2570. Стандартно: 0.9

registerWithTaints
[]core/v1.Taint

registerWithTaints — це масив "taints" (міток) для додавання до обʼєкта вузла під час реєстрації kubelet. Набирає чинності лише тоді, коли параметр registerNode встановлено в значення true і під час початкової реєстрації вузла. Стандартно: nil

registerNode
bool

registerNode дозволяє автоматичну реєстрацію з apiserver. Стандартно: true

tracing
TracingConfiguration

Tracing визначає версійовану конфігурацію для клієнтів трасування OpenTelemetry. Див. kep.k8s.io/2832 для отримання додаткової інформації. Стандартно: nil

localStorageCapacityIsolation
bool

LocalStorageCapacityIsolation дозволяє використовувати функцію ізоляції локального тимчасового зберігання. Стандартно: true. Ця функція дозволяє користувачам встановлювати запити/межі для тимчасового зберігання контейнерів та керувати ним так само, як процесорами та памʼяттю. Вона також дозволяє встановлювати sizeLimit для томів emptyDir, що призведе до видалення Podʼа, якщо використання диска з тома перевищить межу. Ця функція залежить від можливості правильної детекції використання кореневої файлової системи диска. Для деяких систем, таких як kind rootless, якщо ця можливість не підтримується, функцію LocalStorageCapacityIsolation слід вимкнути. Після вимкнення користувач не повинен встановлювати запити/межі для тимчасового зберігання контейнерів або sizeLimit для emptyDir. Стандартно: true

containerRuntimeEndpoint [Обовʼязково]
string

ContainerRuntimeEndpoint є точкою доступу середовища виконання контейнерів. В Linux підтримуються Unix Domain Sockets, а у Windows підтримуються точки npipe та tcp. Приклади: 'unix:///path/to/runtime.sock', 'npipe:////./pipe/runtime'

imageServiceEndpoint
string

ImageServiceEndpoint є точкою доступу сервісу контейнерних образів. Unix Domain Socket підтримуються в Linux, а npipe та tcp точки підтримуються у Windows. Приклади: 'unix:///path/to/runtime.sock', 'npipe:////./pipe/runtime'. Якщо не вказано, використовується значення з containerRuntimeEndpoint.

failCgroupV1
bool

FailCgroupV1 забороняє запуск kubelet на хостах, які використовують cgroup v1. Стандартно цей параметр має значення false, що означає, що kubelet дозволяється запускати на хостах cgroup v1, якщо цей параметр явно не ввімкнено. Стандартно: false

SerializedNodeConfigSource

SerializedNodeConfigSource дозволяє серіалізувати v1.NodeConfigSource. Цей тип використовується всередині Kubelet для відстеження збережених динамічних конфігурацій. Він існує в API групі kubeletconfig, оскільки класифікується як версійний вхідний параметр для Kubelet.

ПолеОпис
apiVersion
string		kubelet.config.k8s.io/v1beta1
kind
string		SerializedNodeConfigSource
source
core/v1.NodeConfigSource

source є джерелом, яке ми серіалізуємо.

CredentialProvider

Зʼявляється в:

CredentialProvider представляє втулок exec, який викликається kubelet. Втулок викликається тільки тоді, коли образ, що завантажується, відповідає образам, що обробляються втулком (див. matchImages).

ПолеОпис
name [Обовʼязково]
string

name є обовʼязковою назвою постачальника облікових даних. Має відповідати назві виконуваного файлу постачальника, яку бачить kubelet. Виконуваний файл повинен бути в теці bin kubelet (встановлений прапорцем --image-credential-provider-bin-dir).

matchImages [Обовʼязково]
[]string

matchImages є обовʼязковим списком рядків, які використовуються для порівняння з образами, щоб визначити, чи слід викликати цього постачальника. Якщо один із рядків відповідає запитаному образу від kubelet, втулок буде викликаний і отримає можливість надати облікові дані. Очікується, що образи міститимуть домен реєстрації та URL-адресу.

Кожен запис у matchImages є шаблоном, який може містити порт і шлях. Глоби можна використовувати в домені, але не в порту чи шляху. Глоби підтримуються як піддоменами, такими як '*.k8s.io' або 'k8s.*.io', а також топ-рівневими доменами, такими як 'k8s.*'. Часткові піддомени, такі як 'app*.k8s.io', також підтримуються. Кожен глоб може відповідати лише одному сегменту піддомену, тому '*.io' не відповідає '*.k8s.io'.

Відповідність існує між образом і matchImage, коли всі з нижченаведених умов виконані:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • URL шлях образу повинен бути префіксом цільового URL шляху образу.
  • Якщо matchImage містить порт, порт також повинен мати збіг в образі.

Приклади значень matchImages:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path
defaultCacheDuration [Обовʼязково]
meta/v1.Duration

defaultCacheDuration є стандартним періодом, протягом якого втулок буде кешувати облікові дані в памʼяті, якщо в відповіді втулка не вказано період кешування. Це поле є обовʼязковим.

apiVersion [Обовʼязково]
string

Обовʼязкова версія введення запиту CredentialProvider. Повернутий CredentialProviderResponse МУСИТЬ використовувати таку ж версію кодування, як і ввод. Поточні підтримувані значення:

  • credentialprovider.kubelet.k8s.io/v1beta1
args
[]string

Аргументи, які передаються команді при її виконанні.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища, які потрібно надати процесу. Вони обʼєднуються з середовищем хоста, а також змінними, які client-go використовує для передачі аргументів втулку.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для встановлення змінних середовища при виконанні втулку облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string

name визначає імʼя змінної середовища.

value [Обовʼязково]
string

value визначає значення змінної середовища.

KubeletAnonymousAuthentication

Зʼявляється в:

ПолеОпис
enabled
bool

enabled дозволяє анонімні запити до сервера kubelet. Запити, які не відхиляються іншим методом автентифікації, обробляються як анонімні запити. Анонімні запити мають імʼя користувача system:anonymous та групу system:unauthenticated.

KubeletAuthentication

Зʼявляється в:

ПолеОпис
x509
KubeletX509Authentication

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

webhook
KubeletWebhookAuthentication

webhook містить налаштування, що стосуються автентифікації за допомогою webhook токенів на предʼявника.

anonymous
KubeletAnonymousAuthentication

anonymous містить налаштування, що стосуються анонімної автентифікації.

KubeletAuthorization

Зʼявляється в:

ПолеОпис
mode
KubeletAuthorizationMode

mode визначає режим авторизації для запитів до сервера kubelet. Дійсні значення: AlwaysAllow і Webhook. Режим Webhook використовує API SubjectAccessReview для визначення авторизації.

webhook
KubeletWebhookAuthorization

webhook містить налаштування, що стосуються авторизації через Webhook.

KubeletAuthorizationMode

(Аліас до string)

Зʼявляється в:

KubeletWebhookAuthentication

Зʼявляється в:

ПолеОпис
enabled
bool

enabled дозволяє автентифікацію за допомогою токенів, підтримувану API tokenreviews.authentication.k8s.io.

cacheTTL
meta/v1.Duration

cacheTTL дозволяє кешування результатів автентифікації.

KubeletWebhookAuthorization

Зʼявляється в:

ПолеОпис
cacheAuthorizedTTL
meta/v1.Duration

cacheAuthorizedTTL — тривалість кешування відповідей 'authorized' від веб-хук авторизатора.

cacheUnauthorizedTTL
meta/v1.Duration

cacheUnauthorizedTTL — тривалість кешування відповідей 'unauthorized' від веб-хук авторизатора.

KubeletX509Authentication

Зʼявляється в:

ПолеОпис
clientCAFile
string

clientCAFile — шлях до файлу сертифікатів у форматі PEM. Якщо встановлено, будь-який запит, що надає клієнтський сертифікат, підписаний одним з органів сертифікації з цього пакету, автентифікується з іменем користувача, що відповідає CommonName, та групами, що відповідають організації у клієнтському сертифікаті.

MemoryReservation

Зʼявляється в:

MemoryReservation визначає різні типи резервування памʼяті для кожного взула NUMA.

ПолеОпис
numaNode [Обовʼязково]
int32		Номер NUMA вузла, для якого задається резервування памʼяті.
limits [Обовʼязково]
core/v1.ResourceList		Список ресурсів для резервування, які визначають обмеження памʼяті.

MemorySwapConfiguration

ЗустрЗʼявляється в:

ПолеОпис
swapBehavior
string

swapBehavior налаштовує використання swap-пам’яті для контейнерних навантажень. Може бути однією з таких опцій:

  • "" (порожнє).
  • "NoSwap": Навантаження не можуть використовувати swap. Стандартно
  • "LimitedSwap": Використання swap для навантажень обмежене. Ліміт swap пропорційний запиту пам’яті контейнера.

ResourceChangeDetectionStrategy

(Аліас string)

ЗустрЗʼявляється в:

ResourceChangeDetectionStrategy позначає режим, у якому внутрішні менеджери (секрети, configmap) виявляють зміни об’єктів.

ShutdownGracePeriodByPodPriority

ЗустрЗʼявляється в:

ShutdownGracePeriodByPodPriority визначає період належного завершення перед завершенням роботи для Podʼів на основі їхнього значення пріоритету.

ПолеОпис
priority [Обовʼязкове]
int32

priority — це значення пріоритету, яке повʼязане з періодом належного завершення перед завершенням роботи

shutdownGracePeriodSeconds [Обовʼязкове]
int64

shutdownGracePeriodSeconds — це період належного завершення перед завершенням роботи в секундах

14.19 - Kubelet CredentialProvider (v1)

Типи ресурсів

CredentialProviderRequest

CredentialProviderRequest включає образ, для якого kubelet вимагає автентифікацію. Kubelet передасть цей обʼєкт запиту втулку через stdin. Загалом втулки повинні відповідати тією ж версією API, яку вони отримали.

ПолеОпис
apiVersion
string		credentialprovider.kubelet.k8s.io/v1
kind
string		CredentialProviderRequest
image [Обовʼязкове]
string

image — це образ контейнеа, який завантажується в рамках запиту втулка для автентифікатора. Втулки можуть за бажанням розпарсити образ для отримання будь-якої інформації, необхідної для отримання облікових даних.

CredentialProviderResponse

CredentialProviderResponse містить облікові дані, які kubelet повинен використовувати для зазначеного образу, наданого в оригінальному запиті. Kubelet буде читати відповідь з втулка через stdout. Ця відповідь повинна бути встановлена на ту ж версію API, що й CredentialProviderRequest.

ПолеОпис
apiVersion
string		credentialprovider.kubelet.k8s.io/v1
kind
string		CredentialProviderResponse
cacheKeyType [Обовʼязкове]
PluginCacheKeyType

cacheKeyType вказує тип ключа кешування для використання на основі образу, наданого в запиті. Є три дійсні значення для типу ключа кешування: Image, Registry і Global. Якщо вказано недійсне значення, kubelet не буде використовувати відповідь.

cacheDuration
meta/v1.Duration

cacheDuration вказує тривалість, впродовж якої облікові дані повинні бути кешовані. Kubelet використовуватиме це поле для налаштування тривалості кешування в пам’яті для облікових даних в AuthConfig. Якщо null, kubelet використовуватиме defaultCacheDuration, надану в CredentialProviderConfig. Якщо встановлено 0, kubelet не буде кешувати наданий AuthConfig.

auth
map[string]AuthConfig

auth — це map, що містить інформацію для автентифікації, передану в kubelet. Кожен ключ є рядком для образу (детальніше про це нижче). Відповідний authConfig має бути дійсним для всіх образів, що відповідають цьому ключу. Втулок повинен встановити це поле в null, якщо не можна повернути дійсні облікові дані для запитаного образу.

Кожен ключ у map є шаблоном, який може містити порт і шлях. Глоби можна використовувати в домені, але не в порті або шляху. Глоби підтримуються як піддомени, такі як '*.k8s.io' або 'k8s.*.io', і домени верхнього рівня, такі як 'k8s.*'. Часткові піддомени, такі як 'app*.k8s.io', також підтримуються. Кожен глоб може відповідати лише одному сегменту піддомена, тому '*.io' не відповідає '*.k8s.io'.

Kubelet буде порівнювати образ з ключем, коли всі з наступного є істинними:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • URL шлях imageMatch має бути префіксом цільового URL шляху образу.
  • Якщо imageMatch містить порт, то порт також повинен збігатись в образі.

Коли повертається кілька ключів, kubelet проходитиме через усі ключі у зворотному порядку, щоб:

  • довші ключі з’являються перед коротшими ключами з тим самим префіксом
  • ключі з глобами з’являються перед ключами без глобів з тим самим префіксом.

Для будь-якого відповідного образу kubelet спробує завантажити образ з наданими обліковими даними, зупиняючись після першого успішно автентифікованого завантаження.

Приклади ключів:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path

AuthConfig

Зустрічається в:

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

ПолеОпис
username [Обовʼязкове]
string

username — це імʼя користувача, яке використовується для автентифікації в реєстрі контейнерів. Порожнє імʼя користувача є дійсним.

password [Обовʼязкове]
string

password — це пароль, який використовується для автентифікації в реєстрі контейнерів. Порожній пароль є дійсним.

PluginCacheKeyType

(Аліас string)

Зустрічається в:

14.20 - WebhookAdmission Configuration (v1)

Пакунок v1 є версією v1 API.

Типи ресурсів

WebhookAdmission

WebhookAdmission надає конфігурацію для контролера доступу на основі webhook.<

ПолеОпис
apiVersion
string		apiserver.config.k8s.io/v1
kind
string		WebhookAdmission
kubeConfigFile [Обовʼязкове]
string

KubeConfigFile — це шлях до файлу kubeconfig.

15 - Зовнішні API

15.1 - Kubernetes Custom Metrics (v1beta2)

Пакунок v1beta2 - це версія v1beta2 API custom_metrics.

Типи ресурсів

MetricListOptions

MetricListOptions використовується для вибору метрик за їх селекторами міток

ПолеОпис
apiVersion
string		custom.metrics.k8s.io/v1beta2
kind
string		MetricListOptions
labelSelector
string

Селектор для обмеження списку обʼєктів, що повертаються, за їхніми мітками. Стандартно — всі обʼєкти.

metricLabelSelector
string

Селектор для обмеження списку метрик, що повертаються, за їхніми мітками

MetricValue

Зʼявляється в:

MetricValue — це значення метрики для певного обʼєкта.

ПолеОпис
apiVersion
string		custom.metrics.k8s.io/v1beta2
kind
string		MetricValue
describedObject [Обовʼязково]
core/v1.ObjectReference

посилання на описуваний обʼєкт

metric [Обовʼязково]
MetricIdentifier		Опис відсутній.
timestamp [Обовʼязково]
meta/v1.Time

вказує час, коли були створені метрики

windowSeconds [Обовʼязково]
int64

вказує на вікно ([Timestamp-Window, Timestamp]), з якого були розраховані ці метрики, при поверненні показника метрики, розраховані з кумулятивних метрик (або нуль для нерозрахованих миттєвих метрик).

value [Обовʼязково]
k8s.io/apimachinery/pkg/api/resource.Quantity

значення метрики для цього обʼєкта

MetricValueList

MetricValueList — це список значень для даної метрики для певного набору обʼєктів

ПолеОпис
apiVersion
string		custom.metrics.k8s.io/v1beta2
kind
string		MetricValueList
metadata [Обовʼязково]
meta/v1.ListMeta		Опис відсутній.
items [Обовʼязково]
[]MetricValue

значення метрики для описаних обʼєктів

MetricIdentifier

Зʼявляється в:

MetricIdentifier ідентифікує метрику за назвою та, за потреби, селектором.

ПолеОпис
name [Обовʼязково]
string

name - це назва даної метрики

selector
meta/v1.LabelSelector

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

15.2 - Kubernetes External Metrics (v1beta1)

Пакет v1beta1 є версією v1beta1 зовнішнього API метрик.

Типи ресурсів

ExternalMetricValue

Зʼявляється в:

ExternalMetricValue — це значення метрики для зовнішньої метрики. Окрема метрика ідентифікується за назвою метрики та набором рядкових міток. Для однієї метрики може бути кілька значень з різними наборами міток.

ПолеОпис
apiVersion
string		external.metrics.k8s.io/v1beta1
kind
string		ExternalMetricValue
metricName [Обовʼязково]
string

назва метрики

metricLabels [Обовʼязково]
map[string]string

набір міток, які ідентифікують один часовий ряд для метрики

timestamp [Обовʼязково]
meta/v1.Time

вказує час, коли були створені метрики

window [Обовʼязково]
int64

вказує на вікно ([Timestamp-Window, Timestamp]), з якого були розраховані ці метрики, при поверненні показника метрики, розраховані з кумулятивних метрик (або нуль для нерозрахованих миттєвих метрик).

value [Обовʼязково]
k8s.io/apimachinery/pkg/api/resource.Quantity

значення метрики

ExternalMetricValueList

ExternalMetricValueList — це список значень для даної метрики для певного набору міток

ПолеОпис
apiVersion
string		external.metrics.k8s.io/v1beta1
kind
string		ExternalMetricValueList
metadata [Обовʼязково]
meta/v1.ListMeta		Опис відсутній.
items [Обовʼязково]
[]ExternalMetricValue

значення метрики для відповідного набору міток

15.3 - Kubernetes Metrics (v1beta1)

Пакет v1beta1 є версією v1beta1 API метрик.

Типи ресурсів

NodeMetrics

Зʼявляється в:

NodeMetrics встановлює метрики використання ресурсів вузла.

ПолеОпис
apiVersion
string		metrics.k8s.io/v1beta1
kind
string		NodeMetrics
metadata
meta/v1.ObjectMeta

Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

Звіряйтесь з документацією Kubernetes API для полів metadata.
timestamp [Обовʼязково]
meta/v1.Time

Наступні поля визначають інтервал часу, з якого метрики були зібрані, з інтервалу [Timestamp-Window, Timestamp].

window [Обовʼязково]
meta/v1.Duration		Опис відсутній.
usage [Обовʼязково]
core/v1.ResourceList

Використання памʼяті — це робочий набір памʼяті.

NodeMetricsList

NodeMetricsList — це список NodeMetrics.

ПолеОпис
apiVersion
string		metrics.k8s.io/v1beta1
kind
string		NodeMetricsList
metadata [Обовʼязково]
meta/v1.ListMeta

Стандартні метадані списку. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

items [Обовʼязково]
[]NodeMetrics

Список метрик вузла.

PodMetrics

Зʼявляється в:

PodMetrics встановлює метрики використання ресурсів Pod.

ПолеОпис
apiVersion
string		metrics.k8s.io/v1beta1
kind
string		PodMetrics
metadata
meta/v1.ObjectMeta

Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

Звіряйтесь з документацією Kubernetes API для полів metadata.
timestamp [Обовʼязково]
meta/v1.Time

Наступні поля визначають інтервал часу, з якого метрики були зібрані, з інтервалу [Timestamp-Window, Timestamp].

window [Обовʼязково]
meta/v1.Duration		Опис відсутній.
containers [Обовʼязково]
[]ContainerMetrics

Метрики для всіх контейнерів збираються в одному часовому інтервалі.

PodMetricsList

PodMetricsList — це список PodMetrics.

ПолеОпис
apiVersion
string		metrics.k8s.io/v1beta1
kind
string		PodMetricsList
metadata [Обовʼязково]
meta/v1.ListMeta

Стандартні метадані списку. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

items [Обовʼязково]
[]PodMetrics

Список метрик поду.

ContainerMetrics

Зʼявляється в:

ContainerMetrics встановлює метрики використання ресурсів контейнера.

ПолеОпис
name [Обовʼязково]
string

Назва контейнера відповідає тій, що з pod.spec.containers.

usage [Обовʼязково]
core/v1.ResourceList

Використання памʼяті — це робочий набір памʼяті.

16 - Планування

16.1 - Налаштування Планувальника

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Ви можете налаштувати поведінку kube-scheduler, написавши конфігураційний файл і передавши його шлях як аргумент командного рядка.

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

Ви можете вказати профілі планування, запустивши kube-scheduler --config <filename>, використовуючи структуру KubeSchedulerConfiguration v1.

Мінімальна конфігурація виглядає наступним чином:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig

Профілі

Профіль планування дозволяє налаштувати різні етапи планування в kube-scheduler. Кожен етап відображається в точці розширення. втулки забезпечують поведінку планування, реалізуючи одну або кілька таких точок розширення.

Ви можете налаштувати один екземпляр kube-scheduler для роботи з декількома профілями.

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

Планування відбувається в кілька етапів, які відображаються через такі точки розширення:

  1. queueSort: Ці втулки надають функцію впорядкування, яка використовується для сортування очікуваних Podʼів у черзі планування. Тільки один втулок сортування черги може бути ввімкнений одночасно.
  2. preFilter: Ці втулки використовуються для попередньої обробки або перевірки інформації про Pod або кластер перед фільтрацією. Вони можуть позначити Pod як непридатний для планування.
  3. filter: Ці втулки еквівалентні Предикатам у політиці планування і використовуються для відсівання вузлів, які не можуть запустити Pod. Фільтри викликаються в налаштованому порядку. Pod позначається як непридатний для планування, якщо жоден вузол не пройшов усі фільтри.
  4. postFilter: Ці втулки викликаються в налаштованому порядку, коли для Pod не знайдено відповідних вузлів. Якщо будь-який втулок postFilter позначає Pod як придатний для планування, решта втулків не викликаються.
  5. preScore: Це інформаційна точка розширення, яка може використовуватися для попередньої оцінки.
  6. score: Ці втулки надають оцінку кожному вузлу, який пройшов етап фільтрації. Планувальник обере вузол з найвищою сумою зважених оцінок.
  7. reserve: Це інформаційна точка розширення, яка повідомляє втулки, коли ресурси були зарезервовані для певного Podʼа. Втулки також реалізують виклик Unreserve, який викликається у випадку невдачі під час або після Reserve.
  8. permit: Ці втулки можуть запобігти або затримати привʼязку Podʼа.
  9. preBind: Ці втулки виконують будь-які роботи, необхідні перед привʼязкою Podʼа.
  10. bind: втулки привʼязують Pod до вузла. втулки bind викликаються в порядку, і як тільки один з них виконає привʼязку, решта втулків пропускаються. Принаймні один втулок привʼязки обовʼязковий.
  11. postBind: Це інформаційна точка розширення, яка викликається після привʼязки Podʼа.
  12. multiPoint: Це поле тільки для конфігурації, які дозволяють ввімкнути або вимкнути втулки для всіх їх застосовних точок розширення одночасно.

Для кожної точки розширення ви можете вимкнути конкретні стандартні втулки або ввімкнути власні. Наприклад:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: PodTopologySpread
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

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

Втулки планування

Наступні втулки, які стандартно увімкнені, реалізують одну або більше з цих точок розширення:

  • ImageLocality: Віддає перевагу вузлам, які вже мають образи контейнерів, що запускаються Podʼом. Точки розширення: score.
  • TaintToleration: Реалізує taints and tolerations. Реалізує точки розширення: filter, preScore, score.
  • NodeName: Перевіряє, чи відповідає імʼя вузла у специфікації Podʼа поточному вузлу. Точки розширення: filter.
  • NodePorts: Перевіряє, чи має вузол вільні порти для запитуваних портів Podʼа. Точки розширення: preFilter, filter.
  • NodeAffinity: Реалізує node selectors та node affinity. Точки розширення: filter, score.
  • PodTopologySpread: Реалізує обмеження поширення топології Podʼів. Точки розширення: preFilter, filter, preScore, score.
  • NodeUnschedulable: Відфільтровує вузли, які мають .spec.unschedulable встановлений на true. Точки розширення: filter.
  • NodeResourcesFit: Перевіряє, чи має вузол усі ресурси, які запитує Pod. Оцінка може використовувати одну з трьох стратегій: LeastAllocated (стандартно), MostAllocated та RequestedToCapacityRatio. Точки розширення: preFilter, filter, score.
  • NodeResourcesBalancedAllocation: Віддає перевагу вузлам, які отримають більш збалансоване використання ресурсів, якщо Pod буде заплановано на них. Точки розширення: score.
  • VolumeBinding: Перевіряє, чи має вузол або чи може звʼязати запитувані томи. Точки розширення: preFilter, filter, reserve, preBind, score.
  • VolumeRestrictions: Перевіряє, чи задовольняють томи, змонтовані на вузлі, обмеження, специфічні для постачальника томів. Точки розширення: filter.
  • VolumeZone: Перевіряє, чи задовольняють запитувані томи будь-які вимоги до зони, які вони можуть мати. Точки розширення: filter.
  • NodeVolumeLimits: Перевіряє, чи можуть бути задоволені ліміти томів CSI для вузла. Точки розширення: filter.
  • EBSLimits: Перевіряє, чи можуть бути задоволені ліміти томів AWS EBS для вузла. Точки розширення: filter.
  • GCEPDLimits: Перевіряє, чи можуть бути задоволені ліміти томів GCP-PD для вузла. Точки розширення: filter.
  • AzureDiskLimits: Перевіряє, чи можуть бути задоволені ліміти томів дисків Azure для вузла. Точки розширення: filter.
  • InterPodAffinity: Реалізує між-Podʼову спорідненість та антиспорідненість. Точки розширення: preFilter, filter, preScore, score.
  • PrioritySort: Забезпечує стандартне сортування за пріоритетами. Точки розширення: queueSort.
  • DefaultBinder: Забезпечує стандартний механізм привʼязки. Точки розширення: bind.
  • DefaultPreemption: Забезпечує стандартний механізм попередження. Точки розширення: postFilter.

Ви також можете ввімкнути наступні втулки через API конфігурації компонентів, які не увімкнені стандартно:

  • CinderLimits: Перевіряє, чи можуть бути задоволені ліміти томів OpenStack Cinder для вузла. Точки розширення: filter.

Декілька профілів

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

З наступною зразковою конфігурацією, планувальник буде працювати з двома профілями: один зі стандартними втулками і один з усіма вимкненими втулками скорінгу.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

Podʼи, які хочуть бути заплановані відповідно до певного профілю, можуть включати відповідне імʼя планувальника у своїй .spec.schedulerName.

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

Якщо Pod не вказує імʼя планувальника, kube-apiserver встановить його на default-scheduler. Таким чином, для планування цих Podʼів повинен існувати профіль з цим імʼям планувальника.

Втулки, які застосовуються до декількох точок розширення

Починаючи з kubescheduler.config.k8s.io/v1beta3, у конфігурації профілю є додаткове поле multiPoint, яке дозволяє легко увімкнути або вимкнути втулок для кількох точок розширення. Метою конфігурації multiPoint є спрощення конфігурації для користувачів і адміністраторів при використанні користувацьких профілів.

Розглянемо втулок MyPlugin, який реалізує точки розширення preScore, score, preFilter і filter. Щоб увімкнути MyPlugin для всіх доступних точок розширення, конфігурація профілю виглядає так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: MyPlugin

Це рівносильно ручному ввімкненню MyPlugin для всіх його точок розширення, як показано нижче:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      preScore:
        enabled:
        - name: MyPlugin
      score:
        enabled:
        - name: MyPlugin
      preFilter:
        enabled:
        - name: MyPlugin
      filter:
        enabled:
        - name: MyPlugin

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

Конкретні точки розширення можна виключити з розширення MultiPoint за допомогою поля disabled для цієї точки розширення. Це працює з відключенням стандартних втулків, нестандартних втулків або з підстановним знаком ('*') для відключення всіх втулків. Приклад цього, відключення Score і PreScore, виглядає так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'MyPlugin'
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

Починаючи з kubescheduler.config.k8s.io/v1beta3, усі стандартні втулки ввімкнені внутрішньо через MultiPoint. Однак окремі точки розширення все ще доступні, щоб забезпечити гнучке переналаштування стандартних значень (наприклад, порядок і ваги Score). Наприклад, розглянемо два втулки Score DefaultScore1 і DefaultScore2, кожен з вагою 1. Їх можна змінити місцями з різними вагами так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      score:
        enabled:
        - name: 'DefaultScore2'
          weight: 5

У цьому прикладі не потрібно явно вказувати втулки в MultiPoint, оскільки вони є стандартними втулками. І єдиний втулок, вказаний у Score, це DefaultScore2. Це тому, що втулки, встановлені через конкретні точки розширення, завжди матимуть пріоритет перед втулками MultiPoint. Таким чином, цей фрагмент по суті змінює порядок втулків без необхідності вказувати їх усіх.

Загальна ієрархія для пріоритету при налаштуванні втулків MultiPoint є наступною:

  1. Специфічні точки розширення працюють першими, і їх налаштування переважатимуть над налаштуваннями, встановленими деінде.
  2. Втулки, налаштовані вручну через MultiPoint, і їх налаштування.
  3. Стандартні втулки та їх стандартні налаштування.

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

ВтулокТочки розширення
DefaultQueueSortQueueSort
CustomQueueSortQueueSort
DefaultPlugin1Score, Filter
DefaultPlugin2Score
CustomPlugin1Score, Filter
CustomPlugin2Score, Filter

Дійсна конфігурація (для зразка) для цих втулків виглядає так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'CustomQueueSort'
        - name: 'CustomPlugin1'
          weight: 3
        - name: 'CustomPlugin2'
        disabled:
        - name: 'DefaultQueueSort'
      filter:
        disabled:
        - name: 'DefaultPlugin1'
      score:
        enabled:
        - name: 'DefaultPlugin2'

Зверніть увагу, що немає помилки при повторній декларації втулка MultiPoint у конкретній точці розширення. Повторна декларація ігнорується (і логується), оскільки конкретні точки розширення мають пріоритет.

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

  • Увімкнено спеціальний втулок queueSort і вимкнено стандартний
  • Увімкнено CustomPlugin1 і CustomPlugin2, які будуть виконуватися першими для всіх своїх точок розширення
  • Вимкнено DefaultPlugin1, але тільки для filter
  • Змінено порядок виконання DefaultPlugin2 для роботи першої в score (навіть перед власними втулками)

У версіях конфігурації до v1beta3, без multiPoint, наведений вище фрагмент рівнозначний цьому:

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:

      # Вимкнути стандартний втулок QueueSort
      queueSort:
        enabled:
        - name: 'CustomQueueSort'
        disabled:
        - name: 'DefaultQueueSort'

      # Увімкнути спеціальні втулки Filter
      filter:
        enabled:
        - name: 'CustomPlugin1'
        - name: 'CustomPlugin2'
        - name: 'DefaultPlugin2'
        disabled:
        - name: 'DefaultPlugin1'

      # Увімкнути та змінити порядок спеціальних втулків score
      score:
        enabled:
        - name: 'DefaultPlugin2'
          weight: 1
        - name: 'DefaultPlugin1'
          weight: 3

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

Міграції конфігурації планувальника

  • З версією конфігурації v1beta2 можна використовувати нове розширення для втулка NodeResourcesFit. Нове розширення поєднує функціонал втулків NodeResourcesLeastAllocated, NodeResourcesMostAllocated та RequestedToCapacityRatio. Наприклад, якщо ви раніше використовували втулок NodeResourcesMostAllocated, то тепер ви можете використовувати NodeResourcesFit (стандартно увімкнено) і додати pluginConfig зі scoreStrategy, яка виглядає наступним чином:

    apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
  - args:
      scoringStrategy:
        resources:
        - name: cpu
          weight: 1
        type: MostAllocated
    name: NodeResourcesFit

  • Втулок планувальника NodeLabel застарілий; натомість використовуйте втулок NodeAffinity (стандартно увімкнено), щоб досягти схожої поведінки.

  • Втулок планувальника ServiceAffinity застарілий; натомість використовуйте втулок InterPodAffinity (стандартно увімкнено), щоб досягти схожої поведінки.

  • Втулок планувальника NodePreferAvoidPods застарілий; натомість використовуйте node taints, щоб досягти схожої поведінки.

  • Втулок, увімкнений у конфігураційному файлі v1beta2, має пріоритет над стандартною конфігурацією для цього втулка.

  • Недійсні host або port, налаштовані для адреси привʼязки healthz і метрик планувальника, спричинять невдачу валідації.

  • Вага трьох стандартних втулків збільшена:

    • InterPodAffinity з 1 до 2
    • NodeAffinity з 1 до 2
    • TaintToleration з 1 до 3

  • Втулок планувальника SelectorSpread видалений; натомість використовуйте втулок PodTopologySpread (стандартно увімкнено), щоб досягти схожої поведінки.

Що далі

16.2 - Політики планування

У версіях Kubernetes до v1.23 політика планування могла використовуватися для вказівки процесу predicates та priorities. Наприклад, ви могли встановити політику планування, запустивши kube-scheduler --policy-config-file <filename> або kube-scheduler --policy-configmap <ConfigMap>.

Ця політика планування не підтримується з Kubernetes v1.23. Споріднені прапорці policy-config-file, policy-configmap, policy-configmap-namespace та use-legacy-policy-config також не підтримуються. Натомість використовуйте Конфігурацію планувальника, щоб досягти схожої поведінки.

Що далі

17 - Інші інструменти

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

crictl

crictl — це інтерфейс командного рядка для перегляду та відлагодження оточення виконання контейнерів, сумісних з CRI.

Dashboard

Dashboard, вебінтерфейс Kubernetes, дозволяє розгортати контейнерні застосунки в кластері Kubernetes, розвʼязувати проблеми з ними та управляти кластером та його ресурсами.

Helm

Helm — це інструмент для управління пакунками наперед сконфігурованих ресурсів Kubernetes. Ці пакунки відомі як Helm charts.

Використовуйте Helm для:

  • Пошуку та використання популярного програмного забезпечення, упакованого як Helm charts для Kubernetes
  • Поширення ваших застосунків у вигляді Helm charts
  • Створення відтворюваних збірок вашого застосунку Kubernetes
  • Управління файлами маніфестів Kubernetes
  • Управління випусками пакунків Helm

Kompose

Kompose — це інструмент для допомоги користувачам Docker Compose в переході до Kubernetes.

Використовуйте Kompose для:

  • Перетворення файлу Docker Compose в обʼєкти Kubernetes
  • Переходу від локальної розробки Docker до управління вашим застосунком через Kubernetes
  • Конвертації файлів Docker Compose yaml версій v1 або v2 або Distributed Application Bundles

Kui

Kui — це графічний інструмент, який обробляє ваші звичайні запити командного рядка kubectl та показує вивід в графічному вигляді.

Kui обробляє звичайні запити командного рядка kubectl та показує вивід в графічному вигляді. Замість ASCII-таблиць, Kui надає графічний рендеринг з таблицями, які можна сортувати.

Kui дозволяє вам:

  • Натискати на довгі, автоматично генеровані назви ресурсів, замість копіювання та вставляння
  • Вводити команди kubectl і бачити їх виконання, іноді навіть швидше, ніж в kubectl
  • Запитувати Job та бачити його виконання у вигляді діаграми водоспаду
  • Переходити за ресурсами в вашому кластері за допомогою графічного інтерфейсу користувача

Minikube

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

17.1 - Зіставлення dockercli з crictl