Spec містить інформацію, передану транспортом втулку.

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

Server — це адреса кластера Kubernetes (https://hostname:port).

TLSServerName передається серверу для SNI і використовується у клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, за яким здійснюється контакт з сервером.

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

CAData містить сертифікати органів сертифікації, закодовані у форматі PEM. Якщо порожнє, слід використовувати системні корені.

ProxyURL — це URL-адреса проксі-сервера, який буде використовуватися для всіх запитів до цього кластера.

DisableCompression дозволяє клієнту відмовитися від стиснення відповідей для всіх запитів до сервера. Це корисно для прискорення запитів (особливо списків), коли пропускна здатність мережі клієнт-сервер достатня, за рахунок економії часу на стиснення (на стороні сервера) і розпакування (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

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.

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація. Зверніть увагу, що Cluster є ненульовим тільки тоді, коли provideClusterInfo встановлено в true у конфігурації exec провайдера (тобто, ExecConfig.ProvideClusterInfo).

Interactive вказує, чи було передано stdin цьому exec втулку.

ExpirationTimestamp вказує час, коли надані облікові дані закінчуються.

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

PEM-кодовані клієнтські TLS сертифікати (включаючи проміжні, якщо є).

PEM-кодований приватний ключ для вищезгаданого сертифіката.

Spec містить інформацію, передану транспортом втулку.

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

Server — це адреса кластера Kubernetes (https://hostname:port).

TLSServerName передається серверу для SNI і використовується у клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, за яким здійснюється контакт з сервером.

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

CAData містить сертифікати органів сертифікації, закодовані у форматі PEM. Якщо порожнє, слід використовувати системні корені.

ProxyURL — це URL-адреса проксі-сервера, який буде використовуватися для всіх запитів до цього кластера.

DisableCompression дозволяє клієнту відмовитися від стиснення відповідей для всіх запитів до сервера. Це корисно для прискорення запитів (особливо списків), коли пропускна здатність мережі клієнт-сервер достатня, за рахунок економії часу на стиснення (на стороні сервера) і розпакування (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

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.

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація. Зверніть увагу, що Cluster є ненульовим тільки тоді, коли provideClusterInfo встановлено в true у конфігурації exec провайдера (тобто, ExecConfig.ProvideClusterInfo).

Interactive вказує, чи було передано stdin цьому exec втулку.

ExpirationTimestamp вказує час, коли надані облікові дані закінчуються.

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

PEM-кодовані клієнтські TLS сертифікати (включаючи проміжні, якщо є).

PEM-кодований приватний ключ для вищезгаданого сертифіката.

limits — це обмеження на запити подій, що надходять. Обмеження можуть бути встановлені на події, отримані на рівні сервера, на рівні простору імен, на рівні користувача та на рівні джерела+обʼєкта. Потрібно принаймні одне обмеження.

type — це тип обмеження, до якого застосовується ця конфігурація.

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

burst — це кількість запитів подій burst, дозволених для цього типу обмеження. Поля qps та burst використовуються разом, щоб визначити, чи приймається певний запит події. burst визначає максимальний розмір дозволу, наданого для певного відра. Наприклад, якщо burst дорівнює 10, а qps дорівнює 3, то контроль доступу прийме 10 запитів перед блокуванням будь-яких запитів. Кожну секунду буде дозволено ще 3 запити. Якщо деяка частина цього дозволу не використовується, то вона переноситься на наступну секунду, поки не буде досягнуто максимального дозволу у 10 запитів.

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

Стандартний розмір кешу становить 4096.

Якщо limitType — 'server', то cacheSize ігнорується.

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata. Зверніться до документації Kubernetes API для полів метаданих metadata.

Spec містить інформацію про под, що оцінюється.

Status заповнюється бекендом і вказує, чи слід дозволити Pod.

Це може бути у вигляді image:tag або image@SHA:012345679abcdef.

Containers — це список підмножини інформації в кожному контейнері пода, що створюється.

Annotations — це список ключ-значення, витягнутий з анотацій Podʼа. Він включає лише ключі, які відповідають шаблону *.image-policy.k8s.io/*. Відповідно до кожного веб-хука, щоб визначити, як інтерпретувати ці анотації, якщо взагалі.

Namespace — це простір імен, в якому створюється под.

Allowed вказує, що всі образи були дозволені до виконання.

Reason має бути порожнім, якщо Allowed є true, у протилежному випадку може містити короткий опис проблеми. Kubernetes може обрізати надто довгі помилки під час відображення користувачу.

AuditAnnotations буде додано до обʼєкта атрибутів запиту контролера доступу за допомогою 'AddAnnotation'. Ключі повинні бути без префіксів (тобто контролер доступу додасть відповідний префікс).

Request описує атрибути запиту на перегляд доступу.

Response описує атрибути відповіді на перегляд доступу.

UID — це ідентифікатор для індивідуального запиту/відповіді. Це дозволяє нам розрізняти випадки запитів, які є в іншому випадку ідентичними (паралельні запити, запити, коли попередні запити не змінили і т. д.). UID призначений для відстеження зворотного звʼязку (запит/відповідь) між KAS і WebHook, а не користувацьким запитом. Він підходить для співставлення записів журналу між вебхуком і apiserver для аудиту або налагодження.

Kind — це повністю кваліфікований тип обʼєкта, що подається (наприклад, v1.Pod або autoscaling.v1.Scale)

Resource — це повністю кваліфікований ресурс, що запитується (наприклад, v1.pods)

SubResource — це субресурс, що запитується, якщо такий є (наприклад, "status" або "scale")

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 — це повністю кваліфікований ресурс початкового 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 — це назва субресурсу початкового API-запиту, якщо такий є (наприклад, "status" або "scale"). Якщо це вказано і відрізняється від значення в "subResource", було виконано еквівалентне співставлення та перетворення. Дивіться документацію для поля "matchPolicy" у типі конфігурації вебхука.

Імʼя — це назва обʼєкта, як подано в запиті. У разі операції CREATE клієнт може не вказати імʼя та покластися на сервер для генерації імені. Якщо це так, це поле буде містити порожній рядок.

Namespace — це простір імен, повʼязаний із запитом (якщо є).

Operation — це операція, що виконується. Це може відрізнятися від операції, що запитується. Наприклад, патч може призвести до виконання операції CREATE або UPDATE.

UserInfo — це інформація про користувача, який виконує запит

Object — це обʼєкт з вхідного запиту.

OldObject — це існуючий обʼєкт. Заповнюється тільки для запитів TE і UPDATE. 

DryRun вказує, що зміни точно не ть збережені —ля цього запиту. Типово: false.

Options — це структура опцій операції, що виконується. наприклад, meta.k8s.io/v1.DeleteOptions або meta.k8s.io/v1.CreateOptions. Це може бути інше, ніж опції, надані викликачем. наприклад, для запиту патчу виконана операція може бути CREATE, у цьому випадку Options буде meta.k8s.io/v1.CreateOptions, навіть якщо викликач надав meta.k8s.io/v1.PatchOptions.

UID — це ідентифікатор для індивідуального запиту/відповіді. Це повинно бути скопійовано з відповідного AdmissionRequest.

Allowed вказує, чи було дозволено запит на перегляд доступу.

Result містить додаткові деталі щодо причин відхилення запиту на перегляд доступу. Це поле НЕ враховується, якщо "Allowed" є "true".

Тіло патчу. Наразі ми підтримуємо лише "JSONPatch", який реалізує RFC 6902.

Тип патчу. Наразі ми підтримуємо лише "JSONPatch".

AuditAnnotations — це неструктурована карта ключ-значення, встановлена віддаленим контролером перегляду доступу (наприклад, error=image-blacklisted). Контролери MutatingAdmissionWebhook і ValidatingAdmissionWebhook додадуть до ключів префікс з іменем вебхука (наприклад, imagepolicy.example.com/error=image-blacklisted). AuditAnnotations буде надано вебхуком для додавання додаткового контексту до логу аудиту для цього запиту.

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

Рівень аудиту, на якому була згенерована подія.

Унікальний ідентифікатор аудиту, згенерований для кожного запиту.

Стадія обробки запиту, коли був згенерований цей екземпляр події.

RequestURI — це URI запиту, який був надісланий клієнтом на сервер.

Verb — це дієслово Kubernetes, повʼязане із запитом. Для запитів без ресурсів це нижчий регістр HTTP-методу.

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

Інформація про користувача, який діє від імені іншого користувача.

IP-адреси джерела, звідки надійшов запит і проміжні проксі-сервери. IP-адреси джерела вказані у наступному порядку:

1. IP-адреси заголовку запиту X-Forwarded-For
2. Заголовок X-Real-Ip, якщо він не присутній у списку X-Forwarded-For
3. Віддалена адреса для зʼєднання, якщо вона не відповідає останній IP-адресі у списку до цього (X-Forwarded-For або X-Real-Ip). Примітка: Усі, крім останнього IP, можуть бути довільно встановлені клієнтом.

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

Обʼєктне посилання на цей запит. Не застосовується для запитів типу Список або запитів без ресурсів.

Статус відповіді, заповнений навіть коли ObjectReference не є типом Status. Для успішних відповідей це міститиме лише Code і StatusSuccess. Для не-статусних типів помилок відповідей це буде автоматично заповнено повідомленням про помилку.

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

Обʼєкт API, що повертається у відповіді, у форматі JSON. ResponseObject записується після перетворення на зовнішній тип і серіалізується як JSON. Опускається для запитів без ресурсів. Записується тільки на рівні Response.

Час, коли запит досяг сервера API.

Час, коли запит досяг поточної стадії аудиту.

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

Метадані списку, такі як інформація про пагінацію.

Перелік подій аудиту.

ObjectMeta включено для забезпечення сумісності з API-інфраструктурою.

Зверніться до документації Kubernetes API для полів поля metadata.

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

Запит може відповідати кільком правилам, у такому випадку буде використано ПЕРШЕ відповідне правило.

Типово рівень аудиту — None, але може бути переважений універсальним правилом в кінці списку.

PolicyRules мають строго визначений порядок.

OmitStages — це список етапів, для яких не створюються події. Зверніть увагу, що це також може бути вказано для кожного правила окремо, у такому випадку обʼєднання обох буде пропущено.

OmitManagedFields вказує, чи слід пропускати керовані поля запитів та відповідей у журналі аудиту API.

Це використовується як глобальний стандарт — значення 'true' призведе до пропуску керованих полів, в іншому випадку керовані поля будуть включені до логу аудиту API.

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

Група — це назва API групи, яка містить ресурси. Порожній рядок представляє основну API групу.

Ресурси — це список ресурсів, до яких застосовується це правило.

Наприклад:

• pods відповідає Podʼам.
• pods/log відповідає субресурсу log Podʼів.
• * відповідає всім ресурсам та їх субресурсам.
• pods/* відповідає всім субресурсам Podʼів.
• */scale відповідає всім субресурсам масштабу.

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

Порожній список означає, що застосовуються всі ресурси та субресурси в цій API групі.

resourceNames — це список імен екземплярів ресурсів, які відповідають політиці. Використання цього поля вимагає, щоб Ресурси були вказані. Порожній список означає, що кожен екземпляр ресурсу відповідає.

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

APIVersion — це версія API групи, яка містить обʼєкт, на який посилаються.

Рівень, на якому записуються запити, що відповідають цьому правилу.

Користувачі (за автентифікованим імʼям користувача), до яких застосовується це правило. Порожній список означає всіх користувачів.

Групи користувачів, до яких застосовується це правило. Користувач вважається відповідним, якщо він є членом будь-якої з UserGroups. Порожній список означає всі групи користувачів.

Дії, що відповідають цьому правилу. Порожній список означає всі дії.

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

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

NonResourceURLs — це набір шляхів URL, які повинні бути аудійовані. * дозволені, але тільки як повний, кінцевий крок у шляху. Приклади:

• /metrics — Записувати запити для метрик apiserver
• /healthz* — Записувати всі перевірки стану

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

OmitManagedFields вказує, чи слід виключати керовані поля з тіла запиту та відповіді з логу аудиту API.

• значення 'true' виключає керовані поля з логу аудиту API
• значення 'false' вказує, що керовані поля повинні бути включені в логу аудиту API. Зверніть увагу, що значення, якщо зазначене, у цьому правилі буде переважати над глобальним стандартним значенням. Якщо значення не зазначено, то діє глобальне стандартне значення, вказане в Policy.OmitManagedFields.

Plugins дозволяє вказувати конфігурацію для кожного втулка контролю допуску.

resources — це список, що містить ресурси та відповідні їм провайдери шифрування.

keys — це список ключів, які використовуються для створення AES-трансформера. Кожен ключ повинен бути 32 байти для AES-CBC та 16, 24 або 32 байти для AES-GCM.

Name — це назва контролера допуску. Вона повинна відповідати зареєстрованій назві втулка контролю допуску.

Path — це шлях до конфігураційного файлу, який містить конфігурацію втулка

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

apiVersion KeyManagementService

name — це назва втулка KMS,який буде використовуватися.

cachesize — це максимальна кількість секретів, які кешуються в памʼяті. Стандартне значення — 1000. Встановіть негативне значення, щоб вимкнути кешування. Це поле дозволено лише для провайдерів KMS v1.

endpoint — це адреса прослуховувння gRPC сервера, наприклад, "unix:///var/run/kms-provider.sock".

timeout для gRPC викликів до kms-втулка (наприклад, 5 секунд). Стандатне значення — 3 секунди.

name — це імʼя ключа, який буде використовуватися при збереженні даних на диск.

secret — це фактичний ключ, закодований в base64.

aesgcm — це конфігурація для трансформера AES-GCM.

aescbc — це конфігурація для трансформера AES-CBC.

secretbox — це конфігурація для трансформера на основі Secretbox.

identity — це (порожня) конфігурація для трансформера ідентичності.

kms містить назву, розмір кешу та шлях до конфігураційного файлу для трансформера конвертів на основі KMS.

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 — це список трансформерів, які використовуються для читання та запису ресурсів на диск. Наприклад: aesgcm, aescbc, secretbox, identity, kms.

keys — це список ключів, які використовуються для створення трансформера Secretbox. Кожен ключ повинен бути довжиною 32 байти.

Endpoint колектора, куди цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендується не вказувати, і використовувати стандартно otlp grpc localhost:4317.

SamplingRatePerMillion — це кількість зразків, які потрібно збирати на мільйон проміжків. Рекомендується не вказувати. Якщо не вказано, зразок буде відповідати ставці зразка батьківського проміжку, але інакше ніколи не буде зібраний.

Plugins дозволяє вказати конфігурацію для кожного втулка контролю допуску.

jwt — це список автентифікаторів для автентифікації користувачів Kubernetes за допомогою JWT-сумісних токенів. Автентифікатор спробує розпарсити ID токен, перевірити, чи він підписаний налаштованим постачальником. Публічний ключ для перевірки підпису знаходиться на публічній точці доступу постачальника, використовуючи OIDC discovery. Для вхідного токена кожен JWT-автентифікатор буде спробований у порядку, в якому він зазначений у цьому списку. Зверніть увагу, що інші автентифікатори можуть запускатися до або після JWT-автентифікаторів. Специфічне розташування JWT-автентифікаторів відносно інших автентифікаторів не визначено і не є стабільним у різних версіях. Оскільки кожен JWT-автентифікатор повинен мати унікальний URL постачальника, в більшості випадків лише один JWT-автентифікатор спробує криптографічно перевірити токен.

Мінімальне дійсне наповнення JWT повинно містити наступні вимоги:

{
"iss": "https://issuer.example.com",
"aud": ["audience"],
"exp": 1234567890,
"": "username"
}

Authorizers — це впорядкований список авторизаторів для авторизації запитів. Це схоже на прапорец --authorization-modes в kube-apiserver. Повинен бути принаймні один.

connectionServices містить список конфігурацій клієнтів вибору виходу.

Вбудувати структуру конфігурації трасування компонента.

Name — це імʼя контролера допуску. Воно повинно відповідати зареєстрованому імені втулка допуску.

Path — це шлях до конфігураційного файлу, що містить конфігурацію втулка.

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

Шлях для якого увімкнено анонімну автентифікацію.

Якщо встановлено, анонімна автентифікація дозволена, тільки якщо запит відповідає одній з умов.

Type визначає тип авторизатора. "Webhook" підтримується в загальному API-сервері. Інші API-сервери можуть підтримувати додаткові типи авторизаторів, такі як Node, RBAC, ABAC тощо.

Name використовується для опису вебхука. Це явно використовується в механізмах моніторингу для метрик. Примітка: Імена повинні бути у форматі DNS1123, такі як myauthorizername або піддомени, такі як myauthorizer.example.domain. Обовʼязково, без стандартного значення.

Webhook визначає конфігурацію для вебхук-авторизатора. Повинна бути визначена, коли Type=Webhook. Не повинна бути визначена, коли Type!=Webhook.

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 представляє опцію для атрибута груп. Значення заявки повинно бути рядком або масивом рядків. Якщо встановлено groups.claim, префікс повинен бути зазначений (і може бути пустим рядком). Якщо встановлено groups.expression, вираз повинен повертати рядок або масив рядків. "" (пустий рядок), [] (пустий масив) і null значення трактуються як відсутність зіставлення груп.

uid представляє опцію для атрибута uid. Заявка повинна бути єдиним рядком. Якщо встановлено uid.expression, вираз повинен повертати рядок.

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 відсутня, жоден додатковий атрибут не буде доданий

claim — це заявка JWT, яку потрібно використовувати. Або claim, або expression повинно бути встановлено. Взаємно виключаються в expression.

expression представляє вираз, який буде оцінений CEL.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінні CEL:

• 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємно виключаються в claim.

claim — це імʼя обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові ключі заявок. Взаємно виключається в expression і message.

requiredValue — це значення обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові значення заявок. Якщо claim встановлено, а requiredValue не встановлено, заявка повинна бути присутньою зі значенням, встановленим у порожній рядок. Взаємно виключається з expression і message.

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 налаштовує повернуте повідомлення про помилку, коли вираз повертає false. message є літеральним рядком. Взаємно виключається з claim і requiredValue.

proxyProtocol — це протокол, який використовується для підключення клієнта до сервера konnectivity.

transport визначає конфігурації транспорту, які ми використовуємо для зʼєднання з сервером konnectivity. Це потрібно, якщо ProxyProtocol — HTTPConnect або GRPC.

name — це назва egress selection. Підтримувані значення: "controlplane", "master", "etcd" та "cluster". "master" egress selector застарілий і замінений на "controlplane".

connection — це точна інформація, що використовується для налаштування egress selection.

key — це рядок, що використовується як ключ додаткового атрибуту. key повинен бути шляхом з префіксом домену (наприклад, example.org/foo). Усі символи перед першим "/" повинні бути дійсним піддоменом, як визначено у RFC 1123. Усі символи після першого "/" повинні бути дійсними символами шляху HTTP, як визначено у RFC 3986. key повинен бути у нижньому регістрі. Має бути унікальним.

valueExpression — це вираз CEL для вилучення значення додаткового атрибуту. valueExpression повинен виробляти рядкове або масив рядкових значень. "", [], і null значення трактуються як відсутність додаткового зіставлення. Порожні рядкові значення, що містяться в масиві рядків, відфільтровуються.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінній CEL:

• 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

url вказує на URL-адресу видавця у форматі https://url або https://url/path. Це повинно відповідати заявці "iss" у поданому JWT і видавцю, повернутому з виявлення. Те ж саме значення, що і прапорець --oidc-issuer-url. Інформація про виявлення отримується з "{url}/.well-known/openid-configuration", якщо не перевизначено за допомогою discoveryURL. Має бути унікальним для всіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору egress не використовується для цього мережевого зʼєднання.

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 містить PEM-кодовані сертифікати органу сертифікації, які використовуються для перевірки зʼєднання під час отримання інформації про виявлення. Якщо не встановлено, використовується системний перевіряючий. Те ж саме значення, що і вміст файлу, на який посилається прапорець --oidc-ca-file.

audiences — це набір прийнятних аудиторій, до яких повинен бути виданий JWT. Принаймні один з записів повинен відповідати заявці "aud" у поданих JWT. Те ж саме значення, що і прапорець --oidc-client-id (хоча це поле підтримує масив). Має бути непорожнім.

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"])' для вимоги точної відповідності.

issuer містить основні параметри підключення постачальника OIDC.

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

claimMappings вказує заявки токена, які будуть розглядатися як атрибути користувача.

userValidationRules - це правила, які застосовуються до кінцевого користувача перед завершенням автентифікації. Ці правила дозволяють застосовувати інваріанти до вхідних ідентичностей, такі як запобігання використанню префіксу system:, який зазвичай використовується компонентами Kubernetes. Правила перевірки поєднуються логічним AND і повинні всі повертати true для успішної перевірки.

claim — це заявка JWT для використання. Є взаємовиключою з expression.

prefix додається до значення заявки, щоб уникнути конфліктів з існуючими іменами. prefix повинен бути встановлений, якщо встановлена заявка, і може бути порожнім рядком. Взаємовиключається з expression.

expression представляє вираз, який буде оцінюватися CEL.

CEL вирази мають доступ до вмісту заявок токена, організованого в CEL змінну:

• 'claims' — це мапа імен заявок до їх значень. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою нотації крапок, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Є взаємовиключною з claim і prefix.

URL — це місцезнаходження сервера konnectivity, до якого потрібно підʼєднатися. Наприклад, це може бути https://127.0.0.1:8131"

TLSConfig — конфігурація, необхідна для використання TLS при підключенні до сервера konnectivity

caBundle — це розташування файлу з CA, який буде використовуватися для встановлення довіри з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Якщо відсутній, коли URL TCPTransport має префікс https://, стандартно використовуються системні корені довіри.

clientKey — це розташування файлу з ключем клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

clientCert — це розташування файлу з сертифікатом клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

TCP — це конфігурація TCP для звʼязку з konnectivity server через TCP. ProxyProtocol з GRPC наразі не підтримується з TCP транспортом. Потрібно налаштувати принаймні один з TCP або UDS.

UDS — це конфігурація UDS для звʼязку з konnectivity server через UDS. Потрібно налаштувати принаймні один з TCP або UDS.

UDSName — це назва unix domain socket для підключення до konnectivity server. Це не використовує префікс unix://. (Наприклад: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

expression представляє вираз, який буде оцінюватися CEL. Повинен повернути true, щоб перевірка пройшла успішно.

CEL вирази мають доступ до вмісту UserInfo, організованого в CEL змінну:

• 'user' - authentication.k8s.io/v1, Обʼєкт Kind=UserInfo Див. https://github.com/kubernetes/api/blob/release-1.28/authentication/v1/types.go#L105-L122 для визначення. API документація: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#userinfo-v1-authentication-k8s-io

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

message налаштовує повернуте повідомлення про помилку, коли правило повертає false. message є літеральним рядком.

Тривалість кешування відповідей "authorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-authorized-ttl Стандартно: 5m0s

Тривалість кешування відповідей "unauthorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-unauthorized-ttl Стандартно: 30s

Час очікування відповіді від вебхука Максимально дозволене значення — 30s. Обовʼязкове, стандартне значення відсутнє.

Версія API authorization.k8s.io SubjectAccessReview, яку потрібно відправити та очікувати від вебхука. Те ж саме, що й встановлення прапорця --authorization-webhook-version Дійсні значення: v1beta1, v1. Обовʼязкове, стандартне значення відсутнє

MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview, яку використовують для оцінки виразів CEL. Дійсні значення: v1. Обовʼязкове, стандартне значення відсутнє

Контролює рішення про авторизацію, коли запит вебхука не вдається завершити або повертає некоректну відповідь або помилки при оцінці matchConditions. Дійсні значення:

• NoOpinion: продовжити до наступних авторизаторів, щоб побачити, чи один з них дозволить запит
• Deny: відхилити запит без консультації з наступними авторизаторами. Обовʼязкове, стандартне значення відсутнє.

ConnectionInfo визначає, як ми спілкуємося з вебхуком

matchConditions — це список умов, які мають бути виконані, щоб запит було надіслано на цей вебхук. Порожній список matchConditions відповідає всім запитам. Максимально допустимо 64 умови відповідності.

Точна логіка відповідності (в порядку):

1. Якщо принаймні одна умова відповідності оцінюється як FALSE, то вебхук пропускається.
2. Якщо ВСІ умови відповідності оцінюються як TRUE, то вебхук викликається.
3. Якщо принаймні одна умова відповідності оцінюється як помилка (але жодна з них не є FALSE):
   • Якщо failurePolicy=Deny, то вебхук відхиляє запит
   • Якщо failurePolicy=NoOpinion, то помилка ігнорується, і вебхук пропускається

Контролює, як вебхук повинен спілкуватися з сервером. Дійсні значення:

• KubeConfigFile: використовувати файл, зазначений у kubeConfigFile, щоб знайти сервер.
• InClusterConfig: використовувати внутрішньокластерну конфігурацію для виклику SubjectAccessReview API, який розміщений kube-apiserver. Цей режим не дозволено для kube-apiserver.

Шлях до KubeConfigFile для інформації про підключення. Обовʼязково, якщо connectionInfo.Type є KubeConfig

expression представляє вираз, який буде оцінюватися за допомогою CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту SubjectAccessReview у версії v1. Якщо версія, вказана в subjectAccessReviewVersion у змінній запиту, є v1beta1, вміст буде перетворено на версію v1 перед оцінкою виразу CEL.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Точка доступу колектора, до якого цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендовано не встановлювати, стандартна точка доступу для otlp grpc — localhost:4317.

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

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-auth не повинен бути встановлений

Authorizers — це впорядкований список авторизаторів для авторизації запитів. Це схоже на прапорець — --authorization-modes kube-apiserver. Має бути принаймні один.

connectionServices містить список налаштувань клієнтів вибору egress.

Вбудуйте структуру конфігурації трасування компонента.

Шлях для якого увімкнено анонімну автентифікацію.

Якщо встановлено, анонімна автентифікація дозволена, тільки якщо запит відповідає одній з умов.

Тип відноситься до типу авторизатора "Webhook" підтримується у загальному API сервері Інші API сервери можуть підтримувати додаткові типи авторизаторів такі як Node, RBAC, ABAC і т.д.

Імʼя, яке використовується для опису webhook Це явно використовується в моніторинговій машинерії для метрик Примітка: Імена повинні бути мітками DNS1123, такими як myauthorizername або піддоменами, такими як myauthorizer.example.domain Обовʼязково, стандартного значення немає

Webhook визначає налаштування для Webhook авторизатора Має бути визначено, коли Type=Webhook Не повинно бути визначено, коли Type!=Webhook

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 представляє опцію для атрибуту groups. Значення claim має бути рядком або масивом рядків. Якщо groups.claim встановлено, префікс повинен бути вказаний (і може бути порожнім рядком). Якщо groups.expression встановлено, вираз повинен видавати значення рядка або масиву рядків. "", [], і null значення розглядаються як відсутність мапінгу групи.

uid представляє опцію для атрибуту uid. Claim повинен бути одним рядковим claim. Якщо uid.expression встановлено, вираз повинен видавати значення рядка.

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 атрибут не буде доданий

claim — це JWT claim для використання. Має бути встановлено або claim, або expression. Взаємовиключне з expression.

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.

claim — це імʼя необхідної заяви. Такий же, як прапорець --oidc-required-claim. Підтримуються тільки ключі заяв у форматі рядка. Взаємно виключає з expression та message.

requiredValue — це значення необхідної заяви. Такий же, як прапорець --oidc-required-claim. Підтримуються тільки значення заяв у форматі рядка. Якщо claim встановлено, а requiredValue не встановлено, заява повинна бути присутня з значенням, яке дорівнює порожньому рядку. Взаємновиключнє з expression та message.

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 налаштовує повідомлення про помилку, яке повертається, коли expression повертає false. message є літералним рядком. Взаємовиключне з claim та requiredValue.

Protocol — це протокол, який використовується для зʼєднання клієнта з konnectivity сервером.

Transport визначає транспортні конфігурації, які ми використовуємо для зʼєднання з konnectivity сервером. Це обовʼязково, якщо ProxyProtocol — це HTTPConnect або GRPC.

name — це назва вибору egress зʼєднання. На даний момент підтримуються значення "controlplane", "master", "etcd" та "cluster". Селекторо egress зʼєднання "master" застарілий і його рекомендується замінити на "controlplane".

connection — це точна інформація, яка використовується для налаштування вибору вихідного зʼєднання.

key — це рядок, який використовується як ключ додаткового атрибуту. key повинен бути шляхом з префіксом домену (наприклад, example.org/foo). Усі символи перед першим "/" повинні бути дійсним субдоменом, як це визначено RFC 1123. Усі символи, що йдуть після першого "/", повинні бути дійсними символами шляху HTTP, як це визначено RFC 3986. key повинен бути написаний малими літерами. Має бути унікальним.

valueExpression — це вираз CEL для отримання значення додаткового атрибуту. valueExpression повинен повертати значення рядка або масиву рядків. "", [], та null значення розглядаються як відсутність додаткового зіставлення. Порожні рядкові значення, що містяться у масиві рядків, відфільтровуються.

Вирази CEL мають доступ до вмісту токенів, організованих у змінну CEL:

• 'claims' — це зіставлення імен вимог до значень вимог. Наприклад, змінна з імʼям 'sub' може бути доступна як 'claims.sub'. Вкладені вимоги можуть бути доступні за допомогою крапкової нотації, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

url вказує на URL видавця у форматі https://url або https://url/path. Це повинно відповідати вимозі "iss" у наданому JWT і видавцю, який повертається discovery. Таке саме значення, як і прапорець --oidc-issuer-url. Інформація про discovery отримується з "{url}/.well-known/openid-configuration", якщо discoveryURL не перевизначений. Вимагається бути унікальним серед усіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору вихідного зʼєднання не використовується для цього мережевого зʼєднання.

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 містить сертифікати уповноважених органів, закодовані в PEM, які використовуються для перевірки зʼєднання під час отримання інформації про discovery. Якщо не встановлено, використовується системний перевіряльник. Таке саме значення, як і вміст файлу, на який посилається прапорець --oidc-ca-file.

audiences — це набір прийнятних аудиторій, для яких повинен бути виданий JWT. Щонайменше один з записів повинен відповідати вимозі "aud" у наданих JWT. Таке саме значення, як і прапорець --oidc-client-id (хоча це поле підтримує масив). Має бути непорожнім.

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"])', щоб вимагати точного співпадіння.

issuer містить основні параметри підключення постачальника OIDC.

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

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

userValidationRules — це правила, які застосовуються до кінцевого користувача перед завершенням автентифікації. Ці правила дозволяють застосовувати інваріанти до вхідних ідентичностей, наприклад, забороняти використання префіксу system:, який зазвичай використовується компонентами Kubernetes. Правила перевірки логічно повʼязані оператором AND і всі повинні повернути true, щоб перевірка пройшла.

claim — це JWT вимога для використання. Взаємовиключне з expression.

prefix додається до значення вимоги, щоб уникнути конфліктів з існуючими іменами. prefix необхідно встановити, якщо встановлено claim, і він може бути порожнім рядком. Взаємовиключне з expression.

expression представляє вираз, який буде оцінюватися за допомогою CEL.

CEL вирази мають доступ до вмісту вимог токену, організованого у змінну CEL:

• 'claims' є зіставленням імен вимог до значень вимог. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені вимоги можна отримати за допомогою нотації з крапкою, наприклад 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємовиключне з claim і prefix.

URL є місцем розташування konnectivity серверу для підключення. Як приклад, це може бути "https://127.0.0.1:8131"

TLSConfig є конфігурацією, необхідною для використання TLS при підключенні до konnectivity серверу

caBundle — це місцезнаходження файлу CA, який буде використовуватися для визначення довіри до konnectivity серверу. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Якщо відсутній, а TCPTransport.URL починається з https://, стандартно використовуються системні корені довіри.

clientKey — це місцезнаходження файлу клієнтського ключа, який буде використовуватися в mtls рукостисканнях з konnectivity сервером. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Має бути налаштований, якщо TCPTransport.URL починається з https://

clientCert — це місцезнаходження файлу клієнтського сертифіката, який буде використовуватися в mtls рукостисканнях з konnectivity сервером. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Має бути налаштований, якщо TCPTransport.URL починається з https://

TCP — це конфігурація TCP для звʼязку з konnectivity сервером через TCP. ProxyProtocol GRPC наразі не підтримується з TCP транспортом. Вимагає налаштування хоча б одного з TCP або UDS

UDS — це конфігурація UDS для звʼязку з konnectivity сервером ерез UDS. Вимагає налаштування хоча б одного з TCP або UDS

UDSName — це назва unix domain socket для підключення до konnectivity серверу. Не використовує префікс unix://. (Наприклад: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

expression представляє вираз, який буде оцінено за допомогою CEL. Має повернути true, щоб перевірка була успішною.

CEL вирази мають доступ до вмісту UserInfo, організованого в CEL змінну:

• 'user' — authentication.k8s.io/v1, обʼєкт Kind=UserInfo. верніться до https://github.com/kubernetes/api/blob/release-1.28/authentication/v1/types.go#L105-L122 для визначення. Документація API: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#userinfo-v1-authentication-k8s-io

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

message налаштовує повернуте повідомлення про помилку, коли правилоило повертає false. message є літеральним рядком.

Тривалість кешування відповідей 'authorized' від webhook авторизатора. Те ж саме, що і встановлення --authorization-webhook-cache-authorized-ttl прапорця. Стандартно: 5m0s

Тривалість кешування відповідей 'unauthorized' від webhook авторизатора. Те ж саме, що і встановлення --authorization-webhook-cache-unauthorized-ttl прапорця. Стандартно: 30s

Тайм-аут для запиту webhook. Максимальне допустиме значення - 30s. Обовʼязкове, стандартного значення немає.

Версія API authorization.k8s.io SubjectAccessReview, яка буде відправлена та очікувана від webhook. Те ж саме, що і встановлення --authorization-webhook-version прапорця. Допустимі значення: v1beta1, v1. Обовʼязкове, стандартного значення немає

MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview, для якої оцінюються CEL вирази. Допустимі значення: v1. Обовʼязкове, стандартного значення немає

Контролює рішення про авторизацію, коли запит webhook не вдається завершити або повертає некоректну відповідь або помилки при оцінці matchConditions. Допустимі значення:

• NoOpinion: продовжувати до наступних авторизаторів, щоб перевірити, чи дозволяє запит хоча б один з них
• Deny: відхилити запит без консультацій з наступними авторизаторами. Обовʼязкове, стандартного значення немає.

ConnectionInfo визначає, як ми спілкуємося з webhook

matchConditions — це список умов, які повинні бути виконані, щоб запит був відправлений на цей webhook. Порожній список matchConditions відповідає всім запитам. Максимум 64 умови відповідності дозволені.

Точна логіка відповідності (у порядку):

1. Якщо хоча б одна matchCondition оцінюється як FALSE, то webhook пропускається.
2. Якщо ВСІ matchConditions оцінюються як TRUE, то викликається webhook.
3. Якщо хоча б одна matchCondition оцінюється як помилка (але жодна не є FALSE):
   • Якщо failurePolicy=Deny, то webhook відхиляє запит
   • Якщо failurePolicy=NoOpinion, то помилка ігнорується, і webhook пропускається

Контролює, як webhook має спілкуватися з сервером. Допустимі значення:

• KubeConfigFile: використовувати файл, вказаний у kubeConfigFile, для знаходження сервера.
• InClusterConfig: використовувати конфігурацію у кластері для виклику SubjectAccessReview API, розміщеного kube-apiserver. Цей режим не дозволений для kube-apiserver.

Шлях до KubeConfigFile для інформації про зʼєднання. Обовʼязкове, якщо connectionInfo.Type — KubeConfig

expression представляє вираз, який буде оцінюватися CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту SubjectAccessReview у версії v1. Якщо версія, вказана у змінній запиту subjectAccessReviewVersion, є v1beta1, вміст буде конвертовано у версію v1 перед оцінкою виразу CEL.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

ConcurrentNodeSyncs — це кількість процесів, які одночасно синхронізують вузли

concurrentServiceSyncs — це кількість служб, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління службами, але більше навантаження на процесор (і мережу).

Generic містить конфігурацію для загального контролера-менеджера

KubeCloudSharedConfiguration містить конфігурацію для функцій, що використовуються як в cloud controller manager, так і в kube-controller manager.

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

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

NodeStatusUpdateFrequency — це частота, з якою контролер оновлює статус вузлів

Webhook — це конфігурація для вебхуків, розгорнутих в cloud-controller-manager

Name — це постачальник хмарних послуг.

cloudConfigFile — це шлях до файлу конфігурації постачальника хмарних послуг.

CloudProviderConfiguration містить конфігурацію для функцій, повʼязаних з CloudProvider.

externalCloudVolumePlugin вказує втулок, який використовувати, коли cloudProvider є "external". Наразі він використовується хмарними провайдерами з репо для керування вузлами та томами в KCM.

useServiceAccountCredentials вказує, чи повинні контролери працювати з окремими службовими обліковими даними.

дозволяє запуск з непозначеними теґами хмарними екземплярами

routeReconciliationPeriod — це період для узгодження маршрутів, створених для вузлів постачальником хмар.

nodeMonitorPeriod — це період для синхронізації NodeStatus в NodeController.

clusterName — це префікс екземпляра для кластеру.

clusterCIDR — це CIDR-діапазон для Pods у кластері.

AllocateNodeCIDRs дозволяє виділяти CIDR для Podʼів і, якщо ConfigureCloudRoutes є true, налаштовувати їх на постачальнику хмар.

CIDRAllocatorType визначає, який тип розподільника Pod CIDR буде використовуватися.

configureCloudRoutes дозволяє налаштовувати CIDR, виділені з allocateNodeCIDRs, на постачальнику хмар.

nodeSyncPeriod — це період для синхронізації вузлів з постачальником хмар. Довші періоди зменшать кількість викликів до постачальника хмар, але можуть затримати додавання нових вузлів в кластер.

Webhooks — це список вебхуків для активації або деактивації: '*' означає "всі стандартно активовані вебхуки" 'foo' означає "активувати 'foo'" '-foo' означає "деактивувати 'foo'" перший елемент для конкретного імені виграє

LeaderName — це назва ресурсу вибору лідера, який захищає міграцію, наприклад, 1-20-KCM-to-1-21-CCM

ResourceLock вказує на тип обʼєкта ресурсу, який буде використовуватися для блокування. Має бути "leases" або "endpoints"

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

Name — це назва контролера, що мігрує, наприклад, service-controller, route-controller, cloud-node-controller тощо

Component — це назва компонента, в якому контролер має працювати, наприклад, kube-controller-manager, cloud-controller-manager тощо. Або '*' означає, що контролер може працювати під будь-яким компонентом, який бере участь у міграції.

port — це порт, на якому працює HTTP-сервіс контролера-менеджера.

address — це IP-адреса для обслуговування (встановіть на 0.0.0.0 для всіх інтерфейсів).

minResyncPeriod — це період повторної синхронізації в рефлекторах; буде випадковим між minResyncPeriod і 2*minResyncPeriod.

ClientConnection визначає файл kubeconfig та налаштування зʼєднання клієнта для використання проксі-сервером при спілкуванні з apiserver.

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

leaderElection визначає конфігурацію клієнта вибору лідера.

Controllers — це список контролерів для активації або деактивації: '*' означає "всі контролери, що стандартно активовані" 'foo' означає "активувати 'foo'" '-foo' означає "деактивувати 'foo'" перший елемент для конкретного імені виграє

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

LeaderMigrationEnabled вказує, чи має бути увімкнена міграція лідера для контролер-менеджера.

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

Generic містить конфігурацію для загального контролера-менеджера

KubeCloudSharedConfiguration містить конфігурацію для спільних функцій як в cloud controller manager, так і в kube-controller manager.

AttachDetachControllerConfiguration містить конфігурацію для функцій, повʼязаних з AttachDetachController.

CSRSigningControllerConfiguration містить конфігурацію для функцій, повʼязаних з CSRSigningController.

DaemonSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з DaemonSetController.

DeploymentControllerConfiguration містить конфігурацію для функцій, повʼязаних з DeploymentController.

StatefulSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з StatefulSetController.

DeprecatedControllerConfiguration містить конфігурацію для деяких застарілих функцій.

EndpointControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointController.

EndpointSliceControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointSliceController.

EndpointSliceMirroringControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointSliceMirroringController.

EphemeralVolumeControllerConfiguration містить конфігурацію для функцій, повʼязаних з EphemeralVolumeController.

GarbageCollectorControllerConfiguration містить конфігурацію для функцій, повʼязаних з GarbageCollectorController.

HPAControllerConfiguration містить конфігурацію для функцій, повʼязаних з HPAController.

JobControllerConfiguration містить конфігурацію для функцій, повʼязаних з JobController.

CronJobControllerConfiguration містить конфігурацію для функцій, повʼязаних з CronJobController.

LegacySATokenCleanerConfiguration містить конфігурацію для функцій, повʼязаних з LegacySATokenCleaner.

NamespaceControllerConfiguration містить конфігурацію для функцій, повʼязаних з NamespaceController.

NodeIPAMControllerConfiguration містить конфігурацію для функцій, повʼязаних з NodeIPAMController.

NodeLifecycleControllerConfiguration містить конфігурацію для функцій, повʼязаних з NodeLifecycleController.

PersistentVolumeBinderControllerConfiguration містить конфігурацію для функцій, повʼязаних з PersistentVolumeBinderController.

PodGCControllerConfiguration містить конфігурацію для функцій, повʼязаних з PodGCController.

ReplicaSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з ReplicaSet.

ReplicationControllerConfiguration містить конфігурацію для функцій, повʼязаних з ReplicationController.

ResourceQuotaControllerConfiguration містить конфігурацію для функцій, повʼязаних з ResourceQuotaController.

SAControllerConfiguration містить конфігурацію для функцій, повʼязаних з ServiceAccountController.

ServiceControllerConfiguration містить конфігурацію для функцій, повʼязаних з ServiceController.

TTLAfterFinishedControllerConfiguration містить конфігурацію для функцій, повʼязаних з TTLAfterFinishedController.

ValidatingAdmissionPolicyStatusControllerConfiguration містить конфігурацію для функцій, повʼязаних з ValidatingAdmissionPolicyStatusController.

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

ReconcilerSyncLoopPeriod — це період часу, протягом якого цикл узгодження станів чекає між наступними виконаннями. Стандартне знаячення — 60 секунд.

DisableForceDetachOnTimeout вимикає примусове відкріплення, коли максимальний час розмонтування перевищено. Стандартне значення — false, отже, примусове відкріплення при відключенні увімкнено.

certFile — це імʼя файлу, що містить PEM-кодований сертифікат X509 CA, який використовується для видачі сертифікатів

keyFile — це імʼя файлу, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для видачі сертифікатів

clusterSigningCertFile — це імʼя файлу, що містить PEM-кодований сертифікат X509 CA, використовується для видачі сертифікатів з обмеженням на кластер

clusterSigningKeyFile — це імʼя файлу, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для видачі сертифікатів з обмеженням на кластер

kubeletServingSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kubelet-serving

kubeletClientSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kube-apiserver-client-kubelet

kubeAPIServerClientSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kube-apiserver-client

legacyUnknownSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/legacy-unknown

clusterSigningDuration — це максимальний період дії сертифікатів, які видаються. Окремі CSR можуть запитувати коротші сертифікати, встановлюючи spec.expirationSeconds.

concurrentCronJobSyncs — це кількість обʼєктів job, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція job, але більше навантаження на CPU (і мережу).

concurrentDaemonSetSyncs — це кількість обʼєктів daemonset, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція daemonset, але більше навантаження на CPU (і мережу).

concurrentDeploymentSyncs — це кількість обʼєктів deployment, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція deployments, але більше навантаження на CPU (і мережу).

concurrentEndpointSyncs — це кількість операцій синхронізації точок доступу, які будуть виконуватись одночасно. Більше число = швидше оновлення, але більше навантаження на CPU (і мережу).

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

concurrentServiceEndpointSyncs — це кількість операцій синхронізації точок доступу сервісу, які будуть виконуватись одночасно. Більше число = швидше оновлення EndpointSlice, але більше навантаження на CPU (і мережу).

maxEndpointsPerSlice — максимальна кількість точок доступу, які будуть додані до одного EndpointSlice. Більше точок доступу на один slice призведе до меншої кількості та більших за розміром endpoint slices, але більших ресурсів.

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

mirroringConcurrentServiceEndpointSyncs — це кількість операцій синхронізації точок доступу сервісу, які будуть виконуватись одночасно. Більше число = швидше оновлення EndpointSlice, але більше навантаження на CPU (і мережу).

mirroringMaxEndpointsPerSubset — максимальна кількість точок доступу, які будуть відображені в EndpointSlice для одного EndpointSubset.

mirroringEndpointUpdatesBatchPeriod можна використовувати для пакетного оновлення EndpointSlice. Усі оновлення, викликані змінами в EndpointSlice, будуть затримані до 'mirroringEndpointUpdatesBatchPeriod'. Якщо інші адреси в тому ж ресурсі Endpoints зміняться в цей період, вони будуть обʼєднані в одне оновлення EndpointSlice. Стандартне значення 0 означає, що кожне оновлення Endpoints викликає оновлення EndpointSlice.

ConcurrentEphemeralVolumeSyncs — це кількість операцій синхронізації ефемерних томів, які будуть виконуватись одночасно. Більше число = швидше оновлення ефемерних томів, але більше навантаження на CPU (і мережу).

Увімкнення загального збирача сміття. ПОВИННО бути синхронізовано з відповідним прапорцем kube-apiserver. УВАГА: загальний збирач сміття є альфа-функцією.

ConcurrentGCSyncs — це кількість процесів збирача сміття, які дозволяється синхронізувати одночасно.

gcIgnoredResources — це список GroupResources, які збирач сміття має ігнорувати.

Group — це частина групи ресурсу GroupResource.

Resource — це частина ресурсу ресурсу GroupResource.

ConcurrentHorizontalPodAutoscalerSyncs — кількість обʼєктів HPA, які дозволено синхронізувати одночасно. Більше число = більш чутка обробка HPA, але більше навантаження на CPU (та мережу).

HorizontalPodAutoscalerSyncPeriod — період для синхронізації кількості Podʼів в горизонтальному автомасштабувальнику Podʼів.

HorizontalPodAutoscalerDownscaleStabilizationWindow — період, протягом якого автомасштабувальник буде переглядати і не зменшувати кількість Podʼів нижче будь-яких рекомендацій, зроблених протягом цього періоду.

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

HorizontalPodAutoscalerCPUInitializationPeriod — період після запуску Podʼа, коли можуть бути пропущені проби CPU.

HorizontalPodAutoscalerInitialReadinessDelay — період після запуску Podʼа, протягом якого зміни готовності вважаються як готовність, що встановлюється вперше. Єдиний ефект цього — HPA буде ігнорувати проби CPU від неготових Podʼів, у яких остання зміна готовності відбулася під час цього періоду.

concurrentJobSyncs — кількість обʼєктів job, які дозволено синхронізувати одночасно. Більше число = більш чутка обробка job, але більше навантаження на CPU (та мережу).

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

namespaceSyncPeriod — період для синхронізації оновлень життєвого циклу простору імен.

concurrentNamespaceSyncs — кількість обʼєктів простору імен, які можуть синхронізуватися одночасно.

serviceCIDR — CIDR-діапазон для сервісів в кластері.

secondaryServiceCIDR — CIDR-діапазон для сервісів в кластері, що використовується в двостекових кластерах. SecondaryServiceCIDR має бути іншої IP-сімʼї, ніж ServiceCIDR.

NodeCIDRMaskSize — маска розміру для CIDR вузлів в кластері.

NodeCIDRMaskSizeIPv4 — маска розміру для CIDR вузлів в двостековому кластері.

NodeCIDRMaskSizeIPv6 — маска розміру для CIDR вузлів в двостековому кластері.

nodeEvictionRate — кількість вузлів за секунду, на яких видаляються контейнери у разі збоїв вузла, коли зона є справною.

secondaryNodeEvictionRate — кількість вузлів за секунду, на яких видаляються контейнери у разі збоїв вузла, коли зона є несправною.

nodeStartupGracePeriod — період часу, протягом якого дозволяється, щоб вузол не відгукувався, перш ніж позначити його як несправний.

nodeMonitorGracePeriod — період часу, протягом якого дозволяється вузлу не відгукуватись, перш ніж позначити його як несправний. Має бути N разів більше, ніж nodeStatusUpdateFrequency kubeletʼа, де N означає кількість спроб, дозволених для kubelet для надсилання статусу вузла.

podEvictionTimeout — період для належного видалення Podʼів на неактивних вузлах.

secondaryNodeEvictionRate явно перезаписується на 0 для кластерів, менших або рівних largeClusterSizeThreshold.

Зона вважається несправною в nodeEvictionRate та secondaryNodeEvictionRate, коли щонайменше unhealthyZoneThreshold (не менше 3) вузлів у зоні є NotReady.

pvClaimBinderSyncPeriod — період для синхронізації постійних томів та заявок на постійні томи.

volumeConfiguration містить конфігурацію для функцій, повʼязаних з томами.

maximumRetry — кількість спроб, які recycler PV виконає у разі невдачі при переробці PV.

minimumTimeoutNFS — мінімальний ActiveDeadlineSeconds для використання для Podʼа NFS Recycler.

podTemplateFilePathNFS — шлях до файлу з визначенням Podʼа, що використовується як шаблон для переробки постійного тому NFS.

incrementTimeoutNFS — приріст часу, який додається за кожен Gi до ActiveDeadlineSeconds для Podʼа NFS scrubber.

podTemplateFilePathHostPath — шлях до файлу з визначенням Podʼа, що використовується як шаблон для переробки постійного тому HostPath. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

minimumTimeoutHostPath — мінімальний ActiveDeadlineSeconds для використання для Podʼа HostPath Recycler. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

incrementTimeoutHostPath — приріст часу, який додається за кожен Gi до ActiveDeadlineSeconds для Podʼа HostPath scrubber. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

terminatedPodGCThreshold — кількість завершених Podʼів, які можуть існувати перед тим, як збирач сміття завершених почне видаляти завершені поди. Якщо <= 0, збирач сміття завершених Podʼів вимкнено.

concurrentRSSyncs — кількість replica set, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління репліками, але більше завантаження на процесор (і мережу).

concurrentRCSyncs — кількість контролерів реплікацій, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління репліками, але більше завантаження на процесор (і мережу).

resourceQuotaSyncPeriod — період для синхронізації статусу використання квоти в системі.

concurrentResourceQuotaSyncs — кількість ресурсних квот, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління квотами, але більше завантаження на процесор (і мережу).

serviceAccountKeyFile — імʼя файлу, що містить PEM-кодований приватний RSA-ключ, який використовується для підписання токенів службовиї облікових записів.

concurrentSATokenSyncs — кількість операцій синхронізації токенів службових облікових записів які будуть виконуватись одночасно.

rootCAFile — кореневий сертифікат центру сертифікації, який буде включено у секрет токена службових облікових записів. Це має бути дійсний PEM-кодований CA пакет.

concurrentStatefulSetSyncs — кількість обʼєктів StatefulSet, які дозволено синхронізувати одночасно. Більше число = більше чутливість statefulsets, але більше навантаження на ЦП (і мережу).

concurrentTTLSyncs — кількість колекторів TTL-after-finished, які дозволено синхронізувати одночасно.

ConcurrentPolicySyncs — кількість обʼєктів політики, які дозволено синхронізувати одночасно. Більша кількість = швидше перевірка типів, але більше навантаження на ЦП (і мережу). Стандартне значення — 5.

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

enableDynamicProvisioning дозволяє створення томів при запуску в середовищі, яке підтримує динамічне створення. Стандартне значення — true.

persistentVolumeRecyclerConfiguration містить конфігурацію для втулків persistent volume.

volumePluginDir — це повний шлях до теки, в якій втулок flex volume має шукати додаткові сторонні втулки томів.

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes визначає заголовок Accept, що надсилається клієнтами при підключенні до сервера, переважаючи стандартне значення 'application/json'. Це поле контролює всі підключення до сервера, що використовуються конкретним клієнтом.

contentType — це тип вмісту, що використовується при надсиланні даних на сервер з цього клієнта.

qps контролює кількість запитів на секунду, дозволених для цього зʼєднання.

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

enableProfiling дозволяє профілювання через веб-інтерфейс за адресою host:port/debug/pprof/

enableContentionProfiling дозволяє профілювання блокувань, якщо enableProfiling встановлено в true.

leaderElect дозволяє клієнту вибору лідера отримати лідерство перед виконанням основного циклу. Увімкніть це при запуску повторюваних компонентів для високої доступності.

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

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

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

resourceLock вказує тип обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceName вказує імʼя обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceNamespace вказує простір імен обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

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

clientConnection вказує файл kubeconfig і налаштування зʼєднання клієнта для використання проксі-сервером при спілкуванні з apiserver.

logging вказує параметри ведення логу. Дивіться Logs Options для додаткової інформації.

hostnameOverride, якщо не порожній, буде використовуватися як імʼя вузла, на якому працює kube-proxy. Якщо не задано, імʼя вузла вважається таким же, як і hostname вузла.

bindAddress може бути використано для переозначення IP-адреси вузла, яка є основною для kube-proxy. Зверніть увагу, що імʼя є історичним артефактом, і kube-proxy насправді не привʼязує жодні сокети до цього IP.

healthzBindAddress — це IP-адреса та порт для сервера перевірки стану, на якому він буде служити, стандартно "0.0.0.0:10256" (якщо bindAddress не встановлено або IPv4), або "[::]:10256" (якщо bindAddress є IPv6).

metricsBindAddress — це IP-адреса та порт для сервера метрик, на якому він буде служити, стандартно "127.0.0.1:10249" (якщо bindAddress не встановлено або IPv4), або "[::1]:10249" (якщо bindAddress є IPv6). (Встановіть на "0.0.0.0:10249" / "[::]:10249", щоб привʼязатися до всіх інтерфейсів.)

bindAddressHardFail, якщо true, вказує kube-proxy вважати помилку привʼязки до порту фатальною і вийти

enableProfiling дозволяє профілювання через веб-інтерфейс на обробнику /debug/pprof. Обробники профілювання будуть оброблені сервером метрик.

showHiddenMetricsForVersion — це версія, для якої ви хочете показати приховані метрики.

mode вказує, який режим проксі використовувати.

iptables містить параметри конфігурації, що стосуються iptables.

ipvs містить параметри конфігурації, що стосуються ipvs.

nftables містить параметри конфігурації, що стосуються nftables.

winkernel містить параметри конфігурації, що стосуються winkernel.

detectLocalMode визначає режим, який використовується для виявлення локального трафіку, стандартно — ClusterCIDR

detectLocal містить додаткові параметри конфігурації, що стосуються DetectLocalMode.

clusterCIDR — це діапазон CIDR для Podʼів у кластері. (Для кластерів з подвійними стеками це може бути пара діапазонів CIDR, розділених комою). Коли DetectLocalMode встановлено в ClusterCIDR, kube-proxy буде вважати трафік локальним, якщо його вихідний IP знаходиться в цьому діапазоні. (Інакше не використовується.)

nodePortAddresses — це список діапазонів CIDR, які містять допустимі IP-адреси вузлів, або, як варіант, єдиний рядок 'primary'. Якщо задано список CIDR, зʼєднання з сервісами NodePort будуть прийматися лише на IP-адресах вузлів в одному з вказаних діапазонів. Якщо встановлено значення 'primary', сервіси NodePort будуть прийматися лише на основну IPv4 та/або IPv6 адресу вузла згідно з обʼєктом Node. Якщо не встановлено, зʼєднання NodePort будуть прийматися на всіх локальних IP.

oomScoreAdj — це значення oom-score-adj для процесу kube-proxy. Значення повинні бути в межах [-1000, 1000]

conntrack містить параметри конфігурації, що стосуються conntrack.

configSyncPeriod — це інтервал часу, через який конфігурація з apiserver оновлюється. Має бути більше 0.

portRange раніше використовувався для конфігурації проксі користувача, але тепер не використовується.

windowsRunAsService, якщо значення true, вмикає інтеграцію API диспетчера керування сервісами Windows.

bridgeInterface — це імʼя інтерфейсу моста (bridge). Коли DetectLocalMode встановлено в LocalModeBridgeInterface, kube-proxy буде вважати трафік локальним, якщо він походить з цього моста.

interfaceNamePrefix — це префікс імені інтерфейсу. Коли DetectLocalMode встановлено в LocalModeInterfaceNamePrefix, kube-proxy буде вважати трафік локальним, якщо він походить з будь-якого інтерфейсу, чиє імʼя починається з цього префіксу.

maxPerCore — максимальна кількість NAT зʼєднань, які слід відстежувати на однt процесорнt ядро (0 для того, щоб залишити обмеження без змін і проігнорувати min).

min — мінімальне значення записів connect-tracking, які слід виділити, незалежно від maxPerCore (встановіть maxPerCore=0, щоб залишити обмеження без змін).

tcpEstablishedTimeout — як довго неактивне TCP зʼєднання буде зберігатися (наприклад, '2s'). Має бути більше 0 для встановлення.

tcpCloseWaitTimeout — як довго неактивний запис conntrack у стані CLOSE_WAIT залишиться в таблиці conntrack (наприклад, '60s'). Має бути більше 0 для встановлення.

tcpBeLiberal, якщо true, kube-proxy налаштує conntrack для роботи в ліберальному режимі для TCP зʼєднань, і пакети з послідовними номерами за межами вікна не будуть позначені як INVALID.

udpTimeout — як довго неактивний запис conntrack для UDP у стані UNREPLIED залишиться в таблиці conntrack (наприклад, '30s'). Має бути більше 0 для встановлення.

udpStreamTimeout — як довго неактивний запис conntrack для UDP у стані ASSURED залишиться в таблиці conntrack (наприклад, '300s'). Має бути більше 0 для встановлення.

masqueradeBit — біт iptables fwmark простору, який слід використовувати для SNAT, якщо використовується режим iptables або ipvs. Значення повинні бути в межах [0, 31].

masqueradeAll вказує kube-proxy виконувати SNAT для всього трафіку, надісланого на IP-адреси сервісів кластера, при використанні режиму iptables або ipvs. Це може бути необхідно для деяких плагінів CNI.

localhostNodePorts, якщо false, вказує kube-proxy вимкнути застарілу поведінку дозволу доступу до сервісів NodePort через localhost. (Застосовується лише для режиму iptables та IPv4; localhost NodePorts ніколи не дозволяються з іншими режимами проксі або з IPv6.)

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod — мінімальний період між повторними синхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації iptables.

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod — мінімальний період між повторними синхронізаціями правил IPVS (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації IPVS.

scheduler — IPVS планувальник, який слід використовувати

excludeCIDRs — список CIDR, які IPVS proxier не повинен торкатися при очищенні IPVS сервісів.

strictARP налаштовує arp_ignore та arp_announce, щоб уникнути відповіді на ARP запити з інтерфейсу kube-ipvs0

tcpTimeout — значення тайм-ауту для неактивних IPVS TCP сесій. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

tcpFinTimeout — значення тайм-ауту для IPVS TCP сесій після отримання FIN. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

udpTimeout — значення тайм-ауту для IPVS UDP пакетів. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

masqueradeBit — це біт простору iptables fwmark, який слід використовувати для SNAT при використанні режиму nftables. Значення повинні бути в межах [0, 31].

masqueradeAll вказує kube-proxy, щоб SNAT весь трафік, що надходить на IP-адреси кластерів Service, при використанні режиму nftables. Це може бути необхідним для деяких CNI втулків.

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod — мінімальний період між повторними синхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації iptables.

networkName — це імʼя мережі, яку kube-proxy використовуватиме для створення точок доступу і політик.

sourceVip — це IP-адреса джерела VIP точки доступу, яка використовується для NAT при балансуванні навантаження.

enableDSR вказує kube-proxy, чи слід створювати HNS політики з DSR.

rootHnsEndpointName — це імʼя hnsendpoint, яке прикріплене до l2bridge для кореневого простору мережі.

forwardHealthCheckVip пересилає VIP сервісу для порту перевірки справності у Windows.

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes визначає заголовок Accept, який надсилається клієнтами при підключенні до сервера, перевизначаючи стандатне значення 'application/json'. Це поле буде контролювати всі зʼєднання з сервером, що використовуються певним клієнтом.

contentType — тип вмісту, який використовується при надсиланні даних на сервер від цього клієнта.

qps контролює кількість запитів на секунду, дозволених для цього зʼєднання.

burst дозволяє накопичувати додаткові запити, коли клієнт перевищує свою норму.

enableProfiling увімкне профілювання через веб-інтерфейс host:port/debug/pprof/

enableContentionProfiling увімкне профілювання блокувань, якщо enableProfiling увімкнено.

leaderElect увімкне клієнта вибору лідера для отримання лідерства перед виконанням основного циклу. Увімкніть це при запуску реплікованих компонентів для високої доступності.

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

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

retryPeriod — це тривалість, яку клієнти повинні чекати між спробами отримання та оновлення лідерства. Це застосовно тільки тоді, коли вибір лідера увімкнено.

resourceLock вказує тип обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceName вказує на імʼя обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceNamespace вказує на простір імен обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

MinCandidateNodesPercentage — це мінімальна кількість кандидатів для відбору при тестуванні виселення як відсоток від кількості вузлів. Має бути в межах [0, 100]. Стандартно дорівнює 10% від розміру кластера, якщо не вказано.

MinCandidateNodesAbsolute — це абсолютна мінімальна кількість кандидатів для відбору. Ймовірна кількість кандидатів, які будуть перераховані для тестування виселення, розраховується за формулою:

numCandidates = max(numNodes * minCandidateNodesPercentage, minCandidateNodesAbsolute).

Ми говоримо "ймовірна", оскільки є й інші фактори, такі як порушення PDB, які впливають на кількість кандидатів для відбору. Має бути не менше 0 вузлів. Стандартно дорівнює 100 вузлам, якщо не вказано.

HardPodAffinityWeight — це вага оцінки для наявних Podʼів з відповідною жорсткою спорідненністю до вхідного Podʼа.

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

Parallelism визначає кількість паралелізму в алгоритмах для планування Podʼів. Має бути більше 0. Стандартно — 16

LeaderElection визначає конфігурацію клієнта виборів лідера.

ClientConnection визначає файл kubeconfig і налаштування підключення клієнта для використання проксі-сервером при спілкуванні з apiserver.

DebuggingConfiguration містить налаштування для функцій, повʼязаних із налагодженням. TODO: Ми можемо зробити це підструктурою як налагодження componentbaseconfigv1alpha1.DebuggingConfiguration

PercentageOfNodesToScore — це відсоток усіх вузлів, які, як тільки будуть визнані придатними для запуску Podʼа, планувальник припиняє пошук інших придатних вузлів у кластері. Це допомагає покращити продуктивність планувальника. Планувальник завжди намагається знайти принаймні "minFeasibleNodesToFind" придатних вузлів незалежно від значення цього прапорця. Приклад: якщо розмір кластера 500 вузлів і значення цього прапорця 30, то планувальник припиняє пошук далі придатних вузлів, як тільки знайде 150 придатних. Коли значення дорівнює 0, стандартно буде оцінено відсоток вузлів (5%—50% залежно від розміру кластера). Він перекривається рівнем профілю PercentageOfNodesToScore.

PodInitialBackoffSeconds — це початкова фора для непридатних для планування Podʼів. Якщо вказано, він повинен бути більше 0. Якщо це значення нульове, буде використано стандартне значення (1s).

PodMaxBackoffSeconds — це максимальна фора для непридатних для планування Podʼів. Якщо вказано, він повинен бути більше podInitialBackoffSeconds. Якщо це значення нульове, буде використано стандартне значення (10s).

Profiles — це профілі планування, які підтримує kube-scheduler. Podʼи можуть вибрати, щоб їх планували за певним профілем, встановивши відповідну назву планувальника. Podʼи, які не вказують жодної назви планувальника, плануються за допомогою профілю "default-scheduler", якщо він присутній тут.

Extenders — це список розширень планувальника, кожне з яких містить значення, як спілкуватися з розширенням. Ці розширення використовуються всіма профілями планувальника.

DelayCacheUntilActive визначає, коли починати кешування. Якщо це true і вибори лідера увімкнені, планувальник чекатиме, щоб заповнити кеші інформаторів, поки не стане лідером. Це призведе до повільнішого перемикання з резервного на основний вузол із перевагою нижчого використання пам’яті під час очікування стати лідером. Стандартно — false.

AddedAffinity застосовується до всіх Podʼів додатково до NodeAffinity, вказаного в PodSpec. Тобто вузли повинні відповідати AddedAffinity І .spec.NodeAffinity. AddedAffinity є станадртно порожнім (є збіг зі всіма вузлами). Коли використовується AddedAffinity, деякі Podʼи з вимогами щодо спорідненості, які збігаються з конкретним вузлом (наприклад, Podʼи Daemonset), можуть залишатися непридатними для планування.

Ресурси, якими потрібно керувати, стандартно: "cpu" та "memory", якщо не вказано інше.

IgnoredResources — список ресурсів, які фільтр NodeResources повинен ігнорувати. Це не застосовується до оцінювання.

IgnoredResourceGroups визначає список груп ресурсів, які фільтр NodeResources повинен ігнорувати. наприклад, якщо група - ["example.com"], вона ігноруватиме всі імена ресурсів, які починаються з "example.com", такі як "example.com/aaa" і "example.com/bbb". Імʼя групи ресурсів не може містити '/'. Це не застосовується до оцінювання.

ScoringStrategy вибирає стратегію оцінювання ресурсів вузлів. Стандартно використовується стратегія LeastAllocated з рівною вагою "cpu" та "memory".

DefaultConstraints визначає обмеження на розподіл топології, які будуть застосовані до Podʼів, що не мають визначених обмежень у pod.spec.topologySpreadConstraints. .defaultConstraints[*].labelSelectors повинні бути порожніми, оскільки вони виводяться з приналежності Podʼа до Services, ReplicationControllers, ReplicaSets або StatefulSets. Якщо не порожньо, .defaultingType має бути "List".

DefaultingType визначає, як виводяться .defaultConstraints. Може бути одним з "System" або "List".

• "System": Використовувати визначені kubernetes обмеження, які розподіляють Podʼи серед вузлів і зон.
• "List": Використовувати обмеження, визначені в .defaultConstraints.

Стандартно "System".

BindTimeoutSeconds — це тайм-аут в секундах у операції привʼязки томів. Значення повинно бути невідʼємним цілим числом. Значення нуль означає, що немає очікування. Якщо це значення не вказано, буде використано стандартне значення (600).

Shape вказує точки, що визначають форму функції оцінки, яка використовується для оцінки вузлів на основі використання статично наданих PV. Використання розраховується шляхом поділу загального запитаного обсягу сховища Podʼа на загальну ємність доступних PV на кожному вузлі. Кожна точка містить використання (у діапазоні від 0 до 100) та відповідну оцінку (у діапазоні від 0 до 10). Ви можете налаштувати пріоритет, вказуючи різні оцінки для різних рівнів використання. Стандартні точки Shape:

1. 0 для 0 використання
2. 10 для 100 використання. Всі точки повинні бути відсортовані у зростаючому порядку за використанням.

URLPrefix за яким доступний розширювач

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

Дієслово для виклику витіснення, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику витіснення розширювача.

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

Числовий множник для оцінок вузлів, які генерує виклик пріоритезації. Вага повинна бути додатним цілим числом

Дієслово для виклику привʼязки, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику привʼязки розширювача. Якщо цей метод реалізовано розширювачем, це відповідальність розширювача привʼязати Pod до apiserver. Тільки один розширювач може реалізовувати цю функцію.

EnableHTTPS вказує, чи слід використовувати https для звʼязку з розширювачем

TLSConfig вказує налаштування транспортного рівня безпеки

HTTPTimeout вказує тривалість тайм-ауту для виклику розширювача. Тайм-аут фільтрації призводить до невдалої спроби планування Podʼа. Тайм-аут пріоритезації ігнорується, пріоритети k8s/інших розширювачів використовуються для вибору вузла.

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

ManagedResources — це список розширених ресурсів, що керуються цим розширювачем.

• Pod буде надіслано до розширювача на етапах фільтрації, пріоритезації та привʼязки (якщо розширювач є звʼязувальним) тільки якщо Pod запитує принаймні один з розширених ресурсів у цьому списку. Якщо список порожній або не вказаний, всі Podʼи будуть надіслані до цього розширювача.
• Якщо IgnoredByScheduler встановлено в true для ресурсу, kube-scheduler буде пропускати перевірку ресурсу в предикатах.

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

Назва розширеного ресурсу.

IgnoredByScheduler вказує, чи слід kube-scheduler ігнорувати цей ресурс при застосуванні предикатів.

Сервер повинен бути доступний без перевірки сертифікату TLS. Тільки для тестування.

ServerName передається серверу для SNI та використовується в клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, яке використовується для звʼязку з сервером.

Сервер вимагає автентифікацію клієнтського сертифікату TLS

Сервер вимагає автентифікацію клієнтського сертифікату TLS

Довірені кореневі сертифікати для сервера

CertData містить PEM-кодовані байти (зазвичай зчитуються з файлу клієнтського сертифіката). CertData має пріоритет над CertFile

KeyData містить PEM-кодовані байти (зазвичай зчитуються з файлу ключа клієнтського сертифіката). KeyData має пріоритет над KeyFile

CAData містить PEM-кодовані байти (зазвичай зчитуються з файлу з кореневими сертифікатами). CAData має пріоритет над CAFile

SchedulerName є імʼям планувальника, асоційованого з цим профілем. Якщо SchedulerName відповідає значенню "spec.schedulerName" Podʼа, то Pod буде плануватися з цим профілем.

PercentageOfNodesToScore є відсотком усіх вузлів, після знаходження яких, планувальник припиняє пошук більш придатних вузлів у кластері для запуску Podʼа. Це допомагає покращити продуктивність планувальника. Планувальник завжди намагається знайти принаймні "minFeasibleNodesToFind" придатних вузлів незалежно від значення цього прапорця. Наприклад, якщо розмір кластера становить 500 вузлів і значення цього прапорця становить 30, то планувальник припиняє пошук далі, як тільки знаходить 150 придатних вузлів. Коли значення 0, стандартно буде оцінено відсоток (5%–50% в залежності від розміру кластера) вузлів. Це матиме перевагу перед глобальним PercentageOfNodesToScore. Якщо це пусто, буде використано глобальний PercentageOfNodesToScore.

Plugins визначають набір втулків, які мають бути увімкнені або вимкнені. Увімкнені втулки — це ті, які мають бути увімкнені додатково до стандартних втулків. Вимкнені втулки — це будь-які зі стандартних втулків, які мають бути вимкнені. Коли жоден увімкнений або вимкнений втулок не зазначений для точки розширення, будуть використані стандартні втулки для цієї точки розширення, якщо такі є. Якщо зазначено втулок QueueSort, то той самий втулок QueueSort та PluginConfig повинні бути зазначені для всіх профілів.

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

Name визначає імʼя втулка

Weight визначає вагу втулка, використовується лише для втулків типу Score.

Name визначає імʼя втулка, що конфігурується

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

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

Disabled визначає стандартні втулки, які повинні бути вимкнені. Коли всі стандартні втулки потрібно вимкнути, слід надати масив, що містить лише один символ "*".

PreEnqueue ` це список втулків, які повинні бути викликані перед додаванням Podʼів у чергу планування.

QueueSort — це список втулків, які повинні бути викликані під час сортування Podʼів у черзі планування.

PreFilter — це список втулків, які повинні бути викликані на точці розширення "PreFilter" фреймворку планування.

Filter — це список втулків, які повинні бути викликані при фільтрації вузлів, що не можуть запустити Pod.

PostFilter — це список втулків, які викликаються після фази фільтрації, але лише коли для Podʼа не були знайдені підходящі вузли.

PreScore — це список втулків, які викликаються перед оцінюванням.

Score — це список втулків, які повинні бути викликані при ранжуванні вузлів, які пройшли фазу фільтрації.

Reserve — це список втулків, які викликаються при резервуванні/анулюванні резервування ресурсів після того, як вузол призначений для запуску Podʼа.

Permit — це список втулків, які контролюють привʼязування Podʼа. Ці втулки можуть запобігти або затримати привʼязування Podʼа.

PreBind — це список втулків, які повинні бути викликані перед привʼязуванням Podʼа.

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

PostBind — це список втулків, які повинні бути викликані після успішного привʼязування Podʼа.

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

Що стосується пріоритету, конфігурація втулків дотримується цієї основної ієрархії

1. Специфічні точки розширення
2. Явно сконфігуровані втулки MultiPoint
3. Набір стандартних втулків, як втулки MultiPoint. Це означає, що втулок з вищим пріоритетом буде виконуватися першим і перезаписувати будь-які налаштування всередині MultiPoint. Явно сконфігуровані втулки користувача також мають вищий пріоритет над стандартними втулками. В межах цієї ієрархії, параметр Enabled має вищий пріоритет над Disabled. Наприклад, якщо втулок зазначено як в multiPoint.Enabled та multiPoint.Disabled, втулок буде активовано. Подібним чином, включення multiPoint.Disabled = '*' і multiPoint.Enabled = pluginA все ще зареєструє цей конкретний втулок через MultiPoint. Це слідує тій же поведінці, що й у всіх інших конфігураціях точок розширення.

Shape є списком точок, що визначають форму функції оцінки.

Назва ресурсу.

Вага ресурсу.

Тип обирає стратегію для виконання.

Ресурси, які слід враховувати при оцінюванні. Стандартний набір ресурсів включає "cpu" та "memory" з однаковою вагою. Дозволені ваги від 1 до 100. Стандартна вага дорівнює 1, якщо не вказана або явно встановлена в 0.

Аргументи, специфічні для стратегії RequestedToCapacityRatio.

Utilization (вісь x). Дійсні значення від 0 до 100. Повністю використаний вузол відповідає 100.

Оцінка, присвоєна даній утилізації (вісь y). Дійсні значення від 0 до 10.